Dale Peterson made me miss dinner again

Just a few hours ago, I got an email letting me know that Dale Peterson had mentioned me in a comment on LinkedIn. Since I always find Dale’s comments on my posts – both positive and negative – to be a great learning experience, I went to see what he had said. And when I saw he was commenting on a topic that I was planning to write about today anyway (but was thinking of putting off ‘til tomorrow), that was it – I had to write it now. Once I have this post up, I’ll find something to eat for dinner.

Dale had posted a video of a presentation by Lindsey Cerkovnik of CISA that mentioned the naming problem – something I’ve written about a few times and will write about much more in the near future. In his post, Dale said that one of the biggest challenges to SBOMs is “naming (well, actual identity) of software and software components. Then Lindsey talks about three possible solutions, CPE, SWID Tags, and Purls, and the challenges using each of these. Where is the global identifier solution?” I couldn’t agree more with Dale’s statement about naming being one of the biggest challenges to SBOMs. In fact, I’d rank it the second most serious of the three showstopper problems. Of course, there are other problems that aren’t showstoppers, but are still serious).

As always happens with Dale’s LinkedIn posts, there were a number of comments. He added one himself, which read:

I believe Tom Alrich wrote recently that NIST claimed to not have the funding or project for this mission….I keep hearing that identity is the big technical issue that isn't solved. Was hoping to get a solution in Lindsey's session. Maybe I will get some great ideas in and on stage at S4x24.

I’ll say it right off: the global identifier solution is purl. This is evidenced by the fact that, as of today, it’s hard to find a single vulnerability database (or other type of software “database” like Google GUAC) that is not based on purl. The big exception to this? The NVD, which is based on CPE, an identifier that was developed by NIST sometime in the 00’s (long before purl appeared, of course). The big difference between CPE and purl is that the former requires a centralized database and requires CPE names to be assigned by trained staff.

Purl, on the other hand, doesn’t require any centralized database at all and doesn’t require any trained staff. In fact, there aren’t any purl “staff” that I know of. Purl is an OWASP open source project, like CycloneDX. In fact, Steve Springett, the leader of the CDX project, is a maintainer of purl. It’s funny how Steve seems to have his hand in some of the most important developments in software supply chain security – for example, the fact that he developed Dependency-Track, to read software BOMs and look up vulnerabilities for components, a little more than ten years ago. This was at least 3-4 years before the term “SBOM” started to be used.

Of course, CDX can be used to produce many types of BOMs, the latest being MLBOM (machine learning BOM), which debuted as part of CycloneDX 1.5 today (literally!). And Dependency-Track is going stronger than ever, being used over ten million times a day to look up a component from an SBOM in a vulnerability database.

I don’t doubt that in 2011, CPE was the state of the art for software naming. And the main challenge to CPE - open source repositories that would proliferate like rabbits in the coming decade or two - was still barely on the horizon. However, CPE hasn’t worn well in recent years, given the open source challenge. So, when Philippe Ombredanne conceived of purl, its advantages quickly became obvious. Rather than try to repeat them here, you can read the post on purl I referenced just above.

You can also read the paper that the SBOM Forum wrote on the naming problem in the NVD last September (the NVD is just one source of the naming problem, but given that it’s now the most widely used vulnerability database in the world and that it uses a very problematic identifier – see pages 4-6 of our paper – makes it by far the biggest locus of the problem).

And that paper leads me to the real topic of this post (I usually get around to the topic at some point in the post): the fact that the SBOM Forum held our second meeting with the NIST NVD team last Friday. In our first meeting, the idea of a public-private partnership to enhance and update the NVD came up. This new meeting was to discuss what the NVD team has learned internally in NIST about PPPs, and their ideas of how such a partnership will be structured.

The NIST team is going to release a video about this within a couple of weeks (Note from Tom 7/23: It seems they're late releasing the video, and the SBOM Forum is now guessing the video won't be out until early August. In other words, the whole NVD Consortium effort - which is the proposed name of the public/private partnership that NIST has in mind for the NVD - has already been set back by a month. I'll let you know when there are more developments in this story), so I won’t try to steal their thunder. But I will say they’re very much interested in working with private industry partners from all over to fix problems in the NVD and make it a much more robust database. The video will outline their general ideas for the program and ask for any comments or questions (purely informal). They will then mull over the comments they get and post concrete plans in the Federal Register at the end of the summer. And knowing that things in the federal government take time (I was astounded to hear this, of course. I’ve always thought of the federal government as a nimble, agile dancer, able to pivot on a dime and go in a completely different direction 😊), they say they’ll be happy if the program is running by the end of the year.

So, look for the video. When it comes out, I’ll of course post a link and write about what they say in this blog. I will point out, though, that they have been reading our paper, which I referenced above. They have decided they will implement purl in the NVD, although there are several other important moving parts that have to be put in place as well. Fortunately, the biggest of those – the CVE 5.1 JSON spec – is underway now, I believe (CVE is operated by CVE.org, an independent board funded by CISA, which is of course part of DHS. The NVD is part of NIST, which is in the Dept. of Commerce. All of the NVD’s current funding comes from DoC, through NIST. Like most people, I always thought CVE was part of NVD, but that’s far from being the case).

So if you’re in private industry (say, a software developer or tool vendor) and you’ve been complaining about the NVD for a long time, you’ll now have a chance to contribute to the solution – or at least the mitigation – of the NVD’s problems. But you also need to keep in mind that there’s a much bigger goal that needs to be kept in mind, even though it’s not attainable at all in the near future.

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.