The first complete SBOM tool!

 

I’ve noted a number of times that there is no “complete” open source SBOM consumption tool available, that provides an organization a constantly updated list of exploitable vulnerabilities in software products that they operate. Specifically, I mean a tool that:

1.      Ingests SBOMs and retrieves the identifiers of all components;

2.      Looks up each of those components in the National Vulnerability Database (NVD) or the OSS Index database (or another vulnerability database), and identifies any open CVEs that apply to them;

3.      Stores each of these CVEs and temporarily assigns them a status of “exploitable”. Note the CVEs are stored by product and version number, but not by the component they apply to (since that information isn’t needed, once the vulnerability has been identified);

4.      Ingests VEX documents as they come in and removes from the list any CVE that is shown to have a status of “not affected” – meaning it isn’t exploitable in the product itself, usually because of how the component was installed (or wasn’t installed);[i]

5.      Repeats steps 2-4 regularly (ideally, multiple times a day); and

6.      Provides the user an almost continuously updated list of exploitable vulnerabilities in software products and versions that they operate.

Why is it so important that the final product of the tool be a list of exploitable vulnerabilities in software products, not all vulnerabilities identified from components in an SBOM? Because there are so few of the former, compared to the latter. I’ve always used the estimate that 90-95% of component vulnerabilities are not exploitable in the product that includes the component, but that was always based just on guesses I’d heard. However, just this morning, I read a Dark Reading article that quotes a researcher to the effect that 97% of open source component vulnerabilities aren’t exploitable in the product itself. I’ll also point out that about 90% of components are open source, so including commercial components probably won’t change this percentage very much.

And why is it important that the tool provide just a list of exploitable vulnerabilities? Because, if this isn’t done, end users are going to waste a lot of time trying to track down vulnerabilities that aren’t exploitable in the first place. Suppliers’ help desks will be overwhelmed with calls and emails that ask when the supplier will patch CVE-2022-XXXXX, yet more than 19 of every 20 calls will be about non-exploitable vulnerabilities – damaging morale on the help desk and wasting lots of professional time.

Until very recently, there was no tool – whether open source or commercial – that performed all the above steps and output a list of exploitable vulnerabilities. For a long time, there have been commercial tools that perform steps 1-3, especially software composition analysis (SCA) tools. And there has been one open source tool, Dependency-Track (an OWASP project), that also performs steps 1-3. In fact, this tool is currently used by software developers about 200 million times a month to identify vulnerabilities in components of products they’re developing, allowing them to remediate the vulnerabilities or replace the components before they ship the product. But no open source tool performed steps 4-6.

However, I’m pleased to report that Dependency-Track can now ingest VEX documents and flag non-exploitable vulnerabilities, so that the list provided to the user will only include the 3% of component vulnerabilities that are exploitable in the product, but not the 97% that aren’t[ii]. This means that Steve Springett, who developed Dependency-Track ten years ago (about five years before the term SBOM even came into use) – and who also is co-leader of the CycloneDX OWASP project – is the winner of the coveted Alrich Prize, for the developer of the first complete SBOM consumption tool (either open source or commercial).

Now, you may wonder what huge award comes to the winner of the Alrich Prize. Here it is: lunch with Tom Alrich! This might be pretty expensive if Steve lived in London or in Australia, where Patrick Dwyer, Steve’s co-leader of the CycloneDX project, lives. However, it just happens that Steve lives about eight miles from where I do, in suburban Chicago (and note that I waited until now to announce the prize. I wasn’t going to take the chance that Patrick or someone else in a far-flung region would win it!). I’ll let Steve choose the McDonald’s where he’ll receive his award 😊.

But there’s one other important piece of news on the SBOM Tools front. I haven’t mentioned that Dependency-Track ingests only CycloneDX, not SPDX, SBOMs. Up until last week, there wasn’t an open source tool that could perform any of the above steps with SPDX SBOMs. However, at the Linux Foundation Open Source Summit in Austin last week, Jennings Aske, CISO of New York Presbyterian Hospital, announced that they have made their Daggerboard SBOM consumption tool available as an open source project, through the Linux Foundation; other NYP people demonstrated the tool.

Daggerboard ingests both SPDX and CycloneDX SBOMs and outputs lists of component vulnerabilities, meaning it performs steps 1-3 above. Since this is the first open source tool that ingests SPDX SBOMs, that’s good. However, I’ve had to notify Jennings that he didn’t win the prize because a) I can’t afford to fly to New York to buy him lunch, and b) Daggerboard doesn’t ingest VEXes, so it doesn’t output exploitable vulnerabilities.

Of course, Jennings was devastated when he heard this news, so I did promise that, once Daggerboard is modified to ingest VEXes (which is definitely on NYP’s feature list for version 2), I’ll let him know the next time I’m in town visiting my sister, and we can have lunch then. After all, it’s the least I can do (it’s also the most I can do).

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.

---

[i] Actually, the non-exploitable CVEs shouldn’t be removed from the list for the product, but they should be flagged as not exploitable. They need to be retained because a) some users require their suppliers to patch all vulnerabilities, even non-exploitable ones; and b) sometimes, if a CVE isn’t exploitable because of other code in the product that prevents an attacker from accessing the vulnerability, there’s a possibility that a future code revision may inadvertently undue that protection and make the CVE exploitable after all. 

[ii] Of course, this assumes that suppliers will provide VEX documents, as well as SBOMs. Fortunately, I think that’s likely to happen, since suppliers are anxious to avoid the mass help desk resignations that may occur if customers start calling about all component vulnerabilities, not just the non-exploitable ones. In fact, two of the largest software organizations in the world were the main drivers behind development of the VEX format under the NTIA – and the continuation of that work under CISA.