From Tom Alrich: Boris is Chief Architect of Cybellum, the
Israeli company that is one of the leading service providers in the SBOM world;
he is a member of the OWASP SBOM Forum. He wrote me in response to the white
paper that Tony Turner and I, who are co-leaders (with Jeff
Williams) of the SBOM Forum, recently developed, titled “purl needs to identify
proprietary software”. The paper describes the project we are proposing to
expand the scope of the “purl” software identifier to address proprietary
software as well as closed source software. We hope to be able to start that project
soon.
To summarize why this project is important, the software
security “industry” is plagued by the problem that software products all have
different names in different contexts. In order to learn about vulnerabilities
(usually designated with a “CVE number” like CVE-2021-44228) that affect a
software product they rely on, an end user organization needs to locate the
product in a vulnerability database. To do that, they need to learn (or be able
to construct from information they already have) the identifier for the product
in the database.
The most widely used vulnerability database in the world,
the US National Vulnerability Database (NVD), utilizes exclusively the “CPE”
identifier, which stands for “Common Platform Enumeration”. CPE has been in
use, in multiple versions, for around twenty years. Unfortunately it is an
unreliable identifier, as the SBOM Forum described on pages 4-6 of this
2022 white paper. Even more unfortunately, serious problems in the NVD since
February 2024 have resulted in over two thirds of the vulnerabilities reported
this year being totally
invisible to a search using a CPE name. Clearly, an alternative software
identifier is needed.
Below, I have posted each paragraph from Boris’ letter in
bold roman type, with my response in italics.
Hi Tom,
Thanks for sharing your thoughts on using SWID to generate PURLs for
proprietary software. We've considered this approach, but we have some
reservations about its feasibility at this time. Here's our reasoning:
- Decentralized
Ecosystem: Proprietary software exists in a decentralized ecosystem with
no central authority to enforce naming standards or manage a unified
repository. This increases the risk of duplicate or conflicting PURLs,
even when generated through SWID.
I agree that proprietary software exists in a
decentralized ecosystem. However, I think you’ll agree that the same can be
said for open source software. Despite that fact, not only is purl by far the leading
software identifier used in open source vulnerability databases today, it is
almost the only one. I am sure there have been duplicate purls for OSS, mainly
due to somebody making a mistake. But I don’t know of any case where a purl was
correctly generated, yet still exactly duplicated a purl for a different
product. I also don’t know of any case where two different purls were created
for the same product (this happens often with CPEs). Do you know of any such
cases?
·
Limited SWID Adoption: While SWID offers a
potential solution, its adoption has been limited. In our experience, many
organizations are unfamiliar with SWID or its implementation. Relying on SWID
for proprietary software identification might face similar obstacles as CPE,
hindering widespread adoption and effectiveness.
I agree that SWID has had limited adoption. You probably
know that NIST developed the SWID specification (and got it approved as ISO/IEC
19770-2) to be a replacement for the CPE identifier in the NVD. For a few
years, it enjoyed modest success; for example, Microsoft included a SWID tag in
the binaries for all their new products or versions for at least a couple of
years. However, SWID never reached the point where NIST felt comfortable
dropping CPE altogether and only using SWID in the NVD. They have more recently
acknowledged they will never make that change.
However, you need to understand the reason why we’re
proposing that SWID tags be used to create purls for proprietary software that isn’t
distributed through app stores: The supplier needs to decide the name and
version string for every product they release. This information needs to be
made publicly available in a single document.
We could have defined our own format for the document,
but since SWID includes the fields needed for the purl (as well as many more
that aren’t needed and don’t need to be filled in) and since it is already an ISO
standard, we decided to use SWID. In fact, Steve Springett has created a SWID tag
generator, which a software supplier (or a third party, if the
supplier has not done this already) can use to create a SWID tag for one of their
current or legacy products (note that the majority of the fields in Steve’s
tool are optional in the purl). The suppliers won’t need to know anything about
SWID to create a SWID tag.
·
PURL and CVE.org: The lack of CVE.org's full
embrace of PURL as a primary identifier raises concerns about its long-term
viability as the sole solution for vulnerability management.
The CVE 5.1 specification (which allows purls in a CVE report
but doesn’t say anything about how they will be created or entered in the report)
was only adopted by CVE.org this past spring (the SBOM Forum submitted the pull
request to add purl to the CVE spec in 2022); very few CNAs are using v5.1 yet.
This is mostly because including a purl in a CVE report won’t do any good now, because
the NVD is at least several years away from being able to handle purl (Sonatype’s
OSS Index vulnerability database
supports both CVE and purl today, so it might be able to utilize purls included
in CVE v5.1 records with little or no change required. We would like to test
this in our proof of concept).
Given these challenges, we believe that a more
comprehensive approach is needed to address the complexities of identifying
proprietary software. This might involve:
- Collaboration
with CVE.org: Working closely with CVE.org to establish clear guidelines
and standards for both PURL and CPE, ensuring they complement each other
and address the limitations of each system.
I agree this is important. In fact, it is already one of
the “deliverables” of our project (which are described on pages 6-9 of the preliminary
project plan that I made available last week). We plan to work with CVE.org
and the CNAs (which report to CVE.org) to develop whatever rules are required for
them to correctly create a purl for a product described in a CVE report, and to
include the purl in the report.
Regarding CPE, the reason we’re doing this project is
that, while purl is clearly a much better identifier than CPE for open source software
and components – and should be adopted by the NVD for OSS as soon as possible –
it doesn’t identify proprietary software products, unless they are delivered
through a package manager like PyPI or Maven Central (which rarely happens). Currently,
CPE is the only identifier for proprietary software, but it’s subject to the
problems listed on pages 4-6 of the OWASP SBOM Forum’s 2022 white paper linked
earlier.
When our project is finished and after our
recommendations are implemented, we believe that purl will prove to be superior
to CPE as an identifier for proprietary software, as it is now for open source
software (see our 2022 white paper for why purl is in general superior to CPE).
However, the 240-250,000 CVE records that now include CPE can’t simply be
thrown away. That means the NVD, and the other vulnerability databases based on
the NVD, will need to support both identifiers, perhaps for a very long time.
However, given that the NVD currently has a backlog of
more than 19,000 CVE records that don’t include a CPE or purl – and that
backlog is growing all the time – integrating purl into the NVD isn’t likely to
happen anytime soon. Fortunately, there are multiple open source vulnerability
databases that support purl, although I don’t think there are any that also support
CPE.
·
Hybrid Model: Exploring a hybrid approach
that leverages PURL's strengths for open-source components while incorporating
alternative mechanisms, potentially drawing inspiration from SWID or other
identification schemes, for proprietary software.
Essentially, this is what we’re proposing. Purl is currently
used in almost all vulnerability databases for open source software (except the
NVD and other databases based on it), but it doesn’t address proprietary
software currently. SWID by itself was intended originally to be an identifier
for both OSS and proprietary software products, but I don’t know any
vulnerability database that supports SWID as a software identifier now, nor do
I know of any other identifiers for proprietary software, other than the very
flawed CPE.
We’re not saying that anybody who is happy with using CPE
to identify software products needs to give it up. But we are saying that, once
our recommendations are implemented, we believe purl will prove to be a
superior identifier for both open source and proprietary software.
·
Industry-Wide Standards: Promoting the
development of industry-wide standards for software identification to ensure
interoperability and consistency across different ecosystems.
That’s what we want to do! Once purl and CPE are both able
to handle open source and proprietary software, the software community will “decide”
(through their choices in the marketplace) whether they want to use one or the
other identifier, or both. As mentioned earlier, both will continue to be in use
for many years.
We appreciate your insights and the work you're doing in
the OWASP SBOM Forum. While we don't see SWID -> PURL as a viable solution
for proprietary software at this point, we're open to further discussions and
exploring alternative approaches.
SWID -> PURL is certainly not a viable solution for
proprietary software at this point, but we want to make it one as soon as
possible! However, I want to point out that the idea of using SWID tags to
generate purls for proprietary software isn’t set in stone; if anyone has a
better idea for expanding purl to cover proprietary software not distributed
through app stores (purls for software in app stores can be easily created without using
SWID tags, as described in our new white
paper), please bring it up to us. We hope to start the project soon, at
which point the participants will be able to determine its direction in both
synchronous and asynchronous online discussions.
We welcome anyone who wants to participate and/or to
contribute to the effort through directed donations to the SBOM Forum through
OWASP (a 501(c)(3) nonprofit organization).
No comments:
Post a Comment