Reader Comment – Software Bill of Materials

Yesterday, Jake Brodsky, a long-time reader and significant control system commentator in his own right, left a comment on my blog post about detecting third-party vulnerabilities. He suggests that a possible solution to the problem could be found in requiring vendors to prepare/publish a software bill of materials (SBOM) for control system products. The comment should be read by all with an interest in control system security.

SBOM is not a new idea. It is based upon the ‘bill of materials’ concept used in manufacturing where a manufacturer maintains a list of components (and their supplier) used to assemble a product. It allows the vendor to trace back faults reported by customers and identify appropriate corrective actions. Similarly, a software vendor could use a SBOM to track third-party components in its own products and the vulnerabilities reported in those components. This would allow the vendor to update their product with appropriate security fixes. There is an interesting blog post over on Synopsys.com outlining the importance of this use of a SBOM.

What Jake is suggesting, however, is to make the SBOM available to the end user. Legislation (HR 5793) was actually introduced in the closing days of the 113^th Congress to require SBOM submissions to federal agencies for any item purchased that contained software or firmware, but no action was taken. It was not subsequently introduced in the next session. I did not review the text because it was published after the session was ended. It is a short bill and worth reading even with the convoluted legislative-speak used by Rep Royce’s staff.

There are a couple of major problems, however, with providing an SBOM to owner/operators. First, there is the problem of tracking vulnerability reporting across the wide spectrum of libraries and software components. The National Institute of Standards NVD database is searchable and it is probably the most comprehensive database, but it does have its limitations. The most notable limitation is described on its search page: “Linux kernel vulnerabilities are categorized separately from vulnerabilities in specific Linux distributions.” The second problem is that there is no reporting capability in the NVD database, you have to physically do a search for each component listed in the SBOM each time that you want to verify that there have been no changes to the vulnerability status of the components. Are you going to do that search once a week, once a month, once a year?

To be fair to Jake, the suggestion that I made in the original blog post for researchers to establish test procedures that would identify the vulnerability they reported has essentially the same problem. How would a manufacturer know when that particular researcher published a new tool that may or may not apply to the equipment they own/operate?

We are starting to see SBOM products for developers (see the Revenera web site for example). These tools help developers track the components they employ in their software. Some even provide the developer with “Actionable alerts for newly discovered vulnerabilities in current and shipped products.” For SBOM to be a useful security management tool for owner/operators similar tracking software would be needed.