Reader Comments – More on SBOM – 2-28-21

My blog post on software bill of materials (SBOM) sparked a small Twitversation this week. It is always nice to be part of an exchange of ideas. That is, of course, the whole point of writing a blog. So, lets look at what new information surfaced.

Software Component Transparency

SBOM did not rise, phoenix like, from the ashes of my mind. There have been conversations on the topic for sometime now. One extended conversation has been taking place under the auspices of the Department of Commerce’s (DOC) National Telecommunications and Information Administration (NTIA). They, in fact, have a web page dedicated to “NTIA Software Component Transparency” and hold periodic public discussions about aspects of the issue.

Their web page provides a wealth of information on the topic. More importantly, they are actively soliciting participation in various working groups. Those working groups include:

• Framing Working Group,

• Awareness and Adoption,

• Formats and Tooling, and

• Healthcare Proof of Concept

It’s Not There

Ron Brash emphasized a point that I tried to make in my post. Just because a vulnerable software component is present in a product does not mean that the product is thus vulnerable. Ron makes the point about Linux kernels; being an open-source product, a developer can take what they want and leave the rest. This is why some sort of vulnerability testing is still necessary.

But, even where vulnerable code does actually exist in the end product, it may not be exploitable in the end product. A lot depends on how the developers access the component and use it in their software/firmware.

Wish List

What would be really nice is if someone could come up with a relatively simple to use Third-Party Vulnerability Tool (TPVT) that could pull data from a database of known vulnerabilities to test and see if vulnerabilities in the known components (from a SBOM) of a product are present in the tested product.

Okay. That means two things on the wish list. First is the TPVT. That will be an interesting development effort. Probably take a 1,000 software engineers. Actually, the database would have to come first, and that, in and of itself, is going to be a monster of a job. I know what a job it is just to keep up with the summaries I do of vulnerability reporting in the ICS field. But a database of all of the versions of all of the potential components (kernels and libraries, oh my) with the associated vulnerabilities, PoC and exploits, that is going to be monumental.

Come to think about it, we may never see this tool. But the NSA might really want one….