We have a winner!

In our last OWASP SBOM Forum meeting before Thanksgiving, we started by discussing CISA’s new Request for Comments  on their recent document (written with DHS) on software naming, which I – ahem! – reviewed in this post. Since I didn’t have anything to add to that post but several people wanted to develop our own response, I encouraged the group to submit one and set up a Google Doc for it. However, nobody has even started to write a response, so I’m assuming our group won’t do that.

It turns out that is for the best. During the meeting, we discussed how the CISA document concludes: It lays out three “candidates” (my word) for a universal software identifier. They are CPE (used in the NVD and databases derived from it), purl (which we wrote about extensively in the document on the naming problem that the SBOM Forum published in 2022), and OmniBOR. Like all good academic documents, it calls for more study to determine which of those is most deserving of the title of Universal Software Identifier.

When I originally read this I smiled, since I don’t think a universal software identifier is needed at all. A universal identifier might have been important in 1970, when there was no way to build a database with multiple identifiers for the primary field. But the last time I checked it was 2023, and we can build a database that uses multiple identifiers for software as easily as we can build one that has multiple identifiers for people (legal name, nickname, name on Facebook, etc.).

However, it struck me initially that the three candidates for universal software identifier hardly have the same standing with respect to the use case that concerns most people in the SBOM community: vulnerability management.

1.      CPE is heavily used now because it is the only identifier supported by the NVD. However, I regard CPE as the problem, not the solution, to the question of software identification. On pages 4-6 of the SBOM Forum document linked above, we described in great detail the problems with CPE. There is no good way to fix those problems going forward, although because there is so much vulnerability information linked to CPE names – I’m referring to the entire CVE.org database – CPE will not go away anytime soon. But as much as possible, new vulnerability information needs to be linked with a better software identifier than CPE.

2.      OmniBOR is a really cool idea. I was quite impressed with the idea when its predecessor idea, GitBom, was discussed by its developer at one of the NTIA SBOM meetings in 2021. However, implementing it universally will (I’m told) require all compiler vendors to implement the necessary changes in their products, and then for all new software products to be developed using these revised compilers. I’m interested in changes that have a chance of being in place during the next 5-10 years, which OmniBOR isn’t. However, I hope the people working on that will continue their efforts.

Does this mean purl is the Universal Software Identifier? The fact that it’s without much doubt taken over the open source world seems to indicate that, but before I could award the USI title to purl, I needed to know if there are any alternatives. In the meeting, I asked if anyone knew of a single major vulnerability database that used any identifier other than CPE or purl. This was a question I’m always wondered about, but had never thought to ask when I was meeting with people with enough knowledge to answer it.

Nobody in the meeting knew of any alternative to CPE and purl that is being used by a major vulnerability database. In fact, one of the participants in the meeting was Philippe Ombredanne, the developer of purl, who has spent a lot of time looking at software identifiers. He didn’t know of any current alternative to CPE or purl.

Therefore, there is no question in my mind that purl is the best candidate for a Universal Software Identifier. However, there is still one problem: It’s not currently universal. It currently only works for identifying software that is available for download from a specific internet location – e.g., a package manager. The majority of open source software products (but certainly not all) meet this description, but most proprietary software does not.

Steve Springett, leader of the OWASP CycloneDX project and a purl maintainer, pointed out that proprietary software that is available in online “stores” like the Apple Store and Google Play could probably be incorporated into purl (as long as an appropriate purl “type” is created). However, most proprietary software isn’t available in stores.

In our naming paper, we included an idea of Steve’s for incorporating proprietary software into purl: Have manufacturers create SWID tags and add a new type to purl, so that a user who knows the contents of the SWID tag for a product they use can create a purl that will allow them to search for vulnerabilities in that software.

What we didn’t do in the paper was specify a way that the contents of SWID tags could be made accessible to users, especially for legacy software. I can think of at least one or two ways that might be done (and I’m sure there are others), but they haven’t been discussed yet (and of course, there might be other ways to do this that don’t involve SWID). Once a scheme is decided on and there has been an education campaign for it (since it will presumably require software suppliers to participate in some way, like putting purls for their products at a particular location on their website), purl really will be the universal software identifier!

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 lead the OWASP SBOM Forum. If you would like to learn more about what that group does or contribute to our group, please go here.