80 percent!

In my last post, I described how a group of friends and I are meeting weekly to discuss roadblocks that are currently preventing widespread distribution and use of SBOMS (SBOMs are already produced in huge quantities by suppliers, but they’re not distributing them to customers. They’re using them to improve the security of their own products).

In that post, I pointed out that we had decided to do what we could to remove what might be the most difficult of the roadblocks, which is usually called the “naming problem” in the SBOM community. I also pointed out that we had already made progress on identifying the cause of the problem and identifying at least a partial solution.

I’m pleased to report that this week we agreed on what looks like it could be a real solution – and even better, it probably won’t be technically hard to implement. It will be politically hard (which we always believed would be the case), but we think that, given that this problem is holding up widespread rollout of SBOMS (federal agencies are required to start asking them from their software suppliers in August, because of Executive Order 14028), this may be the time when the walls finally come tumbling down.

The background of the problem is this: The primary use of SBOMs, when it comes to cybersecurity risk management, is providing a list of components in a software product (or in an intelligent device). The end user – or a third party acting on their behalf – can look up the components in the National Vulnerability Database (NVD), to find out which if any current vulnerabilities (CVEs) apply to them. They can then “coordinate with” (i.e., bug) their supplier to patch those vulnerabilities quickly.

Looking up a component in the NVD requires knowing the CPE name for the product, which is a long character string like “cpe:2.3:a:adobe:acrobat_reader:11.0.5:-:*:*:*:windows:*:*”. The problem is that, for a large percentage of components, there is no CPE name to be found – for one of a host of reasons.

Of course, the NVD has a search function that might yield results, but SBOMs need to be fully machine-readable. Given that many software products have thousands of components, having to search on even one of those will slow down processing of the SBOM. Searching for 100 CPE names would be a lot of work, and searching for say 4,000 CPEs would be a monumental task.

At the meeting this past week, I pointed out that I’d never heard an estimate of what percentage of components in an average SBOM don’t have CPE names (or at least, constructing a CPE name according to the MITRE specification and using that to search doesn’t produce a hit. There are many CPE names that aren’t constructed correctly, but to which CVEs may be attached. Unfortunately, the NVD doesn’t provide “close matches”. It must be exact). I wondered if anybody had an idea about that.

The Director of Product Security of a very large software supplier, who actively participates in this group, said that his company also wondered about this. They studied the issue, and decided they were normally only able to find CPE names for about 20 percent of the components in the average SBOM for one of their products. In other words, it’s likely that around 80% of CPE names for software components can’t be found in the NVD, and therefore require a fair amount of “manual” effort to discover. And that’s assuming they can be discovered at all, since many software products and devices don’t have a CPE name at all, even though they may be loaded with vulnerabilities, as discussed in this post).

Of course, currently that problem just affects the supplier, not their customers - since they and almost all of their peers aren’t currently providing SBOMs to their customers. But because they do a lot of business with the federal government, in August they’ll have to start providing SBOMs to federal agencies. Given that so many of the component CPE names are unresolved, what will the agencies do? Will they have to throw the SBOMs away?

No. Remember, getting one SBOM with say 100 components, and therefore only 20 verified CPE names, is still better than getting zero SBOMs with zero components and zero verified CPE names. The agency can still find out about vulnerabilities in those 20 components and contact the supplier about any of those vulnerabilities that are shown to be serious. And if there are 5,000 components in the SBOM (and there are many products with thousands, or even tens of thousands, of components), they’ll still have verified CPE names for 1,000 of those.

But my friends and I are determined to do better. The solution isn’t to make CPE better, since the opportunities to improve CPE are quite limited. I mentioned in my last post that the solution will probably lie at least partially with the purl (package URL) identifier. While that isn’t the whole solution, it does seem to be a good part of it. I used to think this was a problem that would take ten years to solve, but now I’d say it will be substantially solved in 1-2 years, and perhaps even less than that.

Any opinions expressed in this blog post are strictly mine, and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.