A recent post from Utility Dive shared an update on pilot project working across different government and NGO agencies to derive a SBOM – Software Bill of Materials. This is a good thing, but begs the question … hasn’t this already been done, and if not, how are we allowing a live / business critical infrastructure element (electricity) be that vulnerable.
In my experience SBOM can do two key things. A) make sure necessary and sufficient capabilities are included to protect / operate said infrastructure, and even more importantly, B) understand ALL elements of the software (3rd party, open source, in house, etc … it all must be named, understood and evaluated for quality, security and functionality risk).
Wow … think back 12 months and how many s^%t on the fan situations would have been avoided, if such SBOM were used and analyzed with discipline?
Or, if you think this is nonsense, quote: “As software has become more complex, the problem of component vulnerabilities has grown. “Most estimates are that the average software product contains at least a hundred components, and sometimes many more than that, into the thousands,” said Tom Alrich, a security consultant who has been working with the software transparency initiative since last August and is helping to organize the energy sector POC. “The problem is each of those components can have vulnerabilities, as well as pose other risks.” SBOMs indicate what components are in a piece of software, allowing end users to track and patch vulnerabilities.”