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 113th 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
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
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.
Go to Source of this post
Author Of this post: PJCoyle