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….

Go to Source of this post
Author Of this post: PJCoyle

By admin