For reasons I don’t understand, two of my recent posts, along with one that’s a year old, have suddenly become huge favorites and are getting many more pageviews than normal. This has happened before with other posts; I’ve usually blamed AI training for that. However, even if that’s the case with these three posts, I’m beginning to think that somebody or something is trying to send me a message about what I should be focusing on in my blog posts. Here’s why I say that:
The first
post is dated April 11, 2024 and is titled “It’s time to figure out this
whole vulnerability database problem.” It starts by discussing the problems
with the National Vulnerability Database that started February 12, 2024. As you
probably know if you’ve been reading this blog for a while, on that date the NVD
drastically slowed their performance of their most important job: creating “CPE
names” to add to new CVE Records that have been downloaded from CVE.org (which
is where a new CVE Record first appears after a CVE Numbering Authority – or CNA
- creates it). CPE is a machine-readable software identifier. It is currently
the only software identifier supported by the NVD and the CVE Program.
Briefly, the reason this created a problem is that CVE
Records describe a vulnerability and provide a textual description of the
software product in which the vulnerability was found (e.g., “Product ABC version
4.5”). While a textual description of the vulnerable product is adequate for
many purposes, it will not show up in an automated search using the CPE for the
product (e.g., a CPE name that is created using the product name, version
number and vendor name included in the textual description of the
vulnerability). Of course, since there are now close to 300,000 CVEs, the only
searches that are worth doing are automated ones – reading the text of 300,000
CVE Records isn’t anybody’s idea of fun.
This is a big problem, since it means that a user searching
for vulnerabilities in product ABC version 4.5 using the proper CPE name is
unlikely to see any vulnerabilities that were identified since February 2024. Even
worse, the user won’t be notified of this problem, meaning they are likely to interpret
absence of evidence (no vulnerabilities identified when they search for a
product and version that they use) as evidence of absence (i.e., evidence that
the product is vulnerability-free, even though it might contain many
vulnerabilities identified after February 2024 that don’t appear due to the
lack of a CPE name). Of course, when I wrote the post, I didn’t know that a
year later, the problem would be worse not better, or that the backlog of “unenriched”
CVE Records would have grown to the point that it’s clear it will never be eliminated.
Given this background, I called for a group to start meeting
under the auspices of the OWASP SBOM Forum to discuss alternative vulnerability
database options. After all, the NVD isn’t the only vulnerability database in
the world; there are other good options available, especially when it comes to learning
about vulnerabilities identified in open source software. However, there is no complete
replacement for the NVD, which covers open source and commercial software products,
as well as intelligent devices. In fact, for commercial software and
intelligent devices there is no replacement for the NVD at all. Even though
there have always been a lot of problems with the NVD’s coverage of both of those
product types, at least the NVD provided something. Now, the NVD can be
trusted[i]
only for historical data before 2024.
That group started meeting and continues to do so; we meet
on Zoom on Tuesdays at 11AM Eastern Time. We have some great discussions and
have identified actions that need to be taken (such as helping plan and execute
the introduction of purl identifiers into the CVE ecosystem along with CPE), once
funding becomes available for them. If you would like to join this group, let
me know (we are having similar discussions, including discussions regarding the
CVE situation, in the SBOM Forum meetings, which are on Fridays at 1PM ET. You
are welcome to join those meetings as well).
At the end of the first post, I suggested that spending a
lot of time and effort trying to fix the NVD’s problems was a fool’s errand;
nothing that has occurred since then makes me want to change that judgment. Instead,
I suggested there should be an internationally financed vulnerability database,
perhaps under the sponsorship of IANA. IANA administers IP addresses and runs
the DNS program. It is supported by governments and private organizations
worldwide.
Moreover, I suggested that such a “database” would be (with
some paraphrasing):
…a federation of existing vulnerability databases, linked by
an intelligent “switching hub”. That hub would route user inquiries to the
appropriate database or databases and return the results to the user. Using
this approach would of course eliminate the substantial costs required to
integrate multiple databases into one, as well as to maintain that structure
going forward. It would also probably eliminate any need to “choose” between
different vulnerability identifiers (e.g., CVE vs. OSV vs. GHSA, etc.) or
different software identifiers (CPE vs. purl). All major identifiers could be included
in searches.
The second
post that is getting so many pageviews lately was created on April 15, the
day MITRE’s letter to CVE.org Board of Directors members was revealed; that
letter stated that their current contract to run the CVE Program would expire
the next day, if not renewed. Fortunately, CISA did renew the contract the next
day and the program – which meets with almost universal good will – will continue
as is through next March. It is unlikely that CISA, even if it still exists in
its current form (which is itself unlikely), will renew the contract in March.
Fortunately, members of the CVE.org Board have formed a new
nonprofit organization called the CVE
Foundation. This group has already received substantial funding commitments
that will allow it to continue (and improve) the current programs of CVE.org if
and when the contract is not renewed. Therefore, I believe we don’t need to
worry about whether the CVE Program will continue to operate; it will continue,
and it will improve on what was already considered (including by me) to be a
good operation.
However, note that the NVD is a separate organization (part
of NIST, which is part of the Department of Commerce) from CVE.org (which is operated
by MITRE under contract with CISA, which is part of DHS). Thus, the fact that CVE
is on good long-term footing doesn’t mean that the NVD’s problems have been
solved or are even on the way to being solved. As you may have guessed, I think
it’s time to cut the tether and let the NVD drift downstream while we replace
it with something much better.
That “something” is described in the third
post that is getting a lot of attention nowadays; I wrote it five days
after the second post. I’ll let you read what I said, but I’ll summarize it by
saying
1.
The Global Vulnerability Database doesn’t have
to be directly tied to the CVE Program or the CVE Foundation, any more than the
NVD is tied to the CVE Program now. In fact, since the CVE Foundation’s funders
are probably not anticipating having to create a new vulnerability database along
with extending the existing CVE Program, it shouldn’t be assumed they will automatically
be on board with the idea of creating the GVD – which, of course, will require
much more effort than extending and enhancing the CVE Program.
2.
I also don’t think the GVD should be tied to any
existing vulnerability database, whether it’s the NVD, the new EUVD, or any
other. The GVD should be a true federation of existing databases. It shouldn’t
in itself be a new database, although there might be a need to develop one or
more databases to address particular needs. For example, now that the NVD is
crippled, I know of no vulnerability database that addresses intelligent
devices. It would be a good idea to create such a database (perhaps based on
the GTIN/GMN identifiers used today in global trade, as suggested at the end of
the SBOM Forum’s 2024 white
paper on software naming problems in the NVD). This database would then “join
the federation” of databases included in the GVD.
3.
The GVD will not attempt to “harmonize” the
identifiers for either software products or vulnerabilities. This is because different
identifiers inherently identify different things and should not be expected to “map”
to each other well. For example, purl identifies open source software packages;
if an open source library like log4j includes multiple modules[ii],
they might each have their own purl. However, CPE can only identify the library
itself, not its individual modules. Therefore, there will be no CPE that is equivalent
to a purl that identifies a module.
4.
As much as possible, queries to the GVD should
not require the user to understand anything about the databases that contribute
to it. The user should be able to enter a text string like “Adobe Acrobat
Professional” and be shown all machine-readable software identifiers that
contain that string in some fashion. These identifiers might be CPE names, but
they might also be purl or other identifiers. Similarly, the search may reveal
vulnerabilities identified with CVE numbers, OSV identifiers, or GitHub
Security Advisories (GHSA).
5.
Moreover, those identifiers might be found in
different vulnerability databases, meaning that a single search might be
directed toward multiple databases. For example, a search for an open source
product might be directed both to the NVD and the OSS Index open source software database.
If both searches are successful, both results will be returned to the user.
6.
If the user receives two answers to one search, which
one is “correct”? If they both return the same vulnerability identifier (e.g.,
CVE-2024-12345), the user would be well advised to apply the patch for it as soon
as possible. If they return two identifiers (for example, a CVE number and a
GHSA advisory) that might point to the same vulnerability, the user might just apply
one of the two patches. And if they return what are clearly two different
vulnerabilities, the user should probably apply both patches.
As you can see, using the Global
Vulnerability Database will provide a much richer experience than using the NVD.
In fact, it will be the equivalent of launching simultaneous queries for the
same product in multiple major vulnerability databases worldwide. The query for
each database will be tailored for that database, meaning it won’t include
software or vulnerability identifiers that aren’t “native” to that database. And
the response returned by each database will include everything that is normally
included in such a response. For example, if the database usually returns a
CVSS score for each vulnerability, that will continue for queries that come
through the GVD.
To produce this blog, I rely on
support from people like you. If you appreciate my posts, please make that
known by donating here. Any amount is welcome, but I consider anyone who donates $25
or more in one year to be a subscriber. Thanks!
Of course, I’m sure there are
some users of the NVD – especially those that use it just for compliance purposes
– that won’t be interested in receiving a much richer experience by using the
GVD. If they have always learned about vulnerabilities by searching using a CPE
identifier, they may not be interested in results obtained using a purl
identifier. Such people will always be able to utilize the results they are
used to and discard the results they aren’t used to.
However, other users will be
pleased to be able to compare results obtained by submitting their original
query to multiple vulnerability databases, each in the “language” spoken by
that database. They will be even more pleased to receive the results produced
by different databases, each one “enriched” as the database normally does.
Rereading the above two
paragraphs may give you an idea of the powerful “front end” that will receive GVD
queries and reword them as appropriate for the individual vulnerability
databases that are part of the GVD federation, as well as standardize the format
of the responses from different databases.[iii]
This will be the key to making the GVD work as planned. While this will be as “intelligent”
an application as possible, it will need to follow pre-determined, auditable
rules.
If you are interested in being
part of the planning process for the GVD, please let me know. I am willing to
start a separate workgroup for this; I’ll set the meeting time (probably bi-weekly)
to fit the schedules of the interested parties. Also, if your organization
would be able to donate $1,000 or more to this effort, you can make a donation
to the OWASP Foundation, which will be “restricted” to the SBOM Forum’s GVD
workgroup (OWASP is a 501(c)(3) nonprofit organization).
I’m looking forward to starting
this effort! To be sure, it will be a long one – but when we’re finished, it
will be something we will all be proud to have contributed to.
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] There
have always been problems with the CPE identifier, especially when it comes to
open source packages and intelligent devices. For a discussion of the problems
with product identification in the NVD as well as suggestions for addressing
those problems, see the OWASP SBOM Forum’s 2022 white
paper.
[ii]
Such as the log4core module, in which the log4shell vulnerability was found.
[iii] For
a vulnerability database to be part of the GVD, it will not be required to make
substantial changes that it otherwise would not have made. Each database will maintain
its autonomy; if there is a disagreement between the database and the GVD that
cannot be resolved by negotiation, the database will always be free to leave
the GVD.
No comments:
Post a Comment