Note from Tom: I’ve started a new blog on Substack
called “Tom Alrich’s blog, too”. From now on, all my new posts will appear
there; they will only occasionally appear in this blog. A subscription to the
Substack blog costs $30 per year (or $5 per month); anyone who can’t pay that should
email me. There is also a Founders subscription plan at $100 for the first
year. I hope you’ll consider signing up for that, if you have benefited from my
posts in the past.
I will put up all new posts for free in this blog until August
11. However, if you wish to continue to see my posts after August 11 – which I
hope you will! – please sign up for a paid subscription in Substack at the link
above.
My previous post discussed
a new white paper called “Ensuring the Longevity of the CVE
Program” by the Center for Cybersecurity Policy and Law. To say that I wasn’t
overwhelmed by the insights provided by the authors is an understatement. However,
the biggest problem with the paper is the fact that it left out the biggest
threat to the future of the CVE Program. That threat lies with a different US
government agency that has recently been having big problems, although of a
quite different kind. First, I’ll provide some background information on the
problems, and why they affect the CVE Program.
The CVE Program is run by the non-profit MITRE Corporation,
which is contracted by the Department of Homeland Security. It is paid for - at
least through next March - by the Cybersecurity and Infrastructure Information
Agency (CISA), which is also part of DHS.
The other US government agency is NIST, the National Institute
of Standards and Technology. NIST is part of the US Department of Commerce.
One of NIST’s many projects is the National Vulnerability Database (NVD), which
started in 2005. A vulnerability database links software products with
vulnerabilities that have been identified in those products. The NVD is
currently by far the most widely used vulnerability database in the world; many
private (VulnDB, VulDB, VulnCheck, Vulners, etc.) and public (Japan Vulnerability Notes, EU Vulnerability Database, etc.) vulnerability
databases draw heavily from the NVD.
The NVD identifies vulnerabilities using CVE numbers (e.g.,
CVE-2025-12345); each vulnerability is described in a “CVE record”. Many people
(including me, a few years ago) assume that, because the NVD uses CVE numbers
to identify vulnerabilities, it must be the source of CVE records. In fact, CVE
records originate with the CVE Program in DHS. They are created by CVE Numbering Authorities
(CNAs), of which there are currently more than 450. The largest CNAs are
software developers, including Microsoft, Oracle, Red Hat, HPE, and Schneider
Electric.
When a CNA creates a new CVE record, they submit it to the CVE.org vulnerability database, which is run by
the CVE Program (this is sometimes referred to as the “CVE list”, although it’s
much more than a simple list). The NVD (and other vulnerability databases that
are based on CVE) downloads new CVE records shortly after they appear in
CVE.org.
When a CNA creates a new CVE record, they have the option of
including various information in the record. Some fields are officially optional
and others are mandatory, but, to be honest, there are only a few fields that
are really mandatory, in the sense that the record will definitely be rejected
if they’re not present (this includes the CVE number and the product name). The
CVE Program maintains the CVE Record Format (formerly, the “CVE JSON Record
Format”), which is now on version 5.1.1. The full spec for 5.1.1 is here,
but this
older version is more readable and reasonably up to date.
For our present purposes, the most important fields in the
CVE record are:
1.
The CVE number that the CNA has assigned to this
vulnerability, as well as a description of the vulnerability.
2.
The name(s) of the product(s) affected by the
vulnerability. While the CNA must list at least one affected product, they can also
list many of them, including separate versions of the same product. Of course,
every product listed needs to be affected by the vulnerability described in the
record.
3.
The vendor(s) of the product(s) affected by the
vulnerability.
4.
The version or versions[i]
affected by the vulnerability.
5.
The CPE name for each affected product.
The last item needs explanation. CPE stands for Common Platform
Enumeration, although the name doesn’t carry much meaning today. What’s
important is that CPE is a complicated machine-readable naming scheme for software and
hardware products; the CPE name includes fields 2-4 above. If a CVE record
doesn’t include a CPE name, it isn’t easily searchable in the NVD, since there is
no way to know for certain that the product described in the text of a CVE
record is the same product that is the basis for a similar CPE name.
For example, suppose items 2-4 above appear as “Product A”, “XYZ”,
and “Version 2.74” respectively in the text of a CVE record. Furthermore,
suppose that a user of Product A v2.74 wants to learn about vulnerabilities identified
in that product. They find the CPE name for a similar product that includes the
same values of fields 2 and 4, but it includes “XYZ, Inc.” instead of “XYZ” for
the vendor name.
Are these in fact the same product? That depends on the application.
If the vulnerable product were a throwaway product used in the insurance
industry, the match might be considered perfect. On the other hand, if the
vulnerable product was an electronic relay that could, if compromised, open a
circuit breaker and black out a large section of Manhattan, this might not be
considered a match at all.
In other words, due to the arbitrary nature of the fields
included in CPE names, such as “vendor” and “product name” (both of which can
vary substantially, even when the same product is being described), there will always
be uncertainty in creating a CPE name. This means that two people could follow
the CPE specification exactly, yet create different valid CPE names for a
single software product. The NVD has reserved the right for their staff members
to create CPE names for vulnerable products described in the text of new CVE
records and add them to the records (a process called “enrichment”); however, there
is simply no way to know for certain what values the staff member used for the
fields in a CPE name they created.
This arbitrariness, along with other serious problems[ii],
makes it close to impossible to fully automate the process of looking up software
vulnerabilities in the NVD. In other words, someone searching the NVD for vulnerabilities
that affect a particular product must guess the values for the fields used by
the NVD staff member when they created the CPE name for that product. There is
no way to be 100% certain that a product in the real world corresponds to a
product described in a CVE record, unless they have identical CPE names.
But that isn’t the worst problem with CPE. The biggest is
that, since February 2024, the NVD has drastically neglected their responsibility
to create CPE names and add them to new CVE records. This has resulted
in more than 50% of CVE records created since that date not including a CPE
name(s) for the affected product(s) listed in the record.[iii]
The problem with this is straightforward: a CVE record that
doesn’t include a CVE name for the vulnerable product isn’t visible to an automated
search, since CPE is currently the only machine-readable software identifier
supported by the CVE program and the NVD.[iv]
Without a CPE name, the user will have to search through the text in over
300,000 CVE records, although even then there is no such thing as a certain
identification (remember “XYZ” vs. “XYZ, Inc.”?).
This is compounded by the fact that the NVD will provide the
same message, “There are 0 matching records” when a product truly has no reported
vulnerabilities, as when the product has a lot of reported vulnerabilities, but
they don’t have CPE names included in them. Of course, human nature dictates
that most people seeing that message will assume the former interpretation is
correct, when it might well be the latter.
You may wonder why I’m pointing out the above as a serious
problem for the CVE Program, when this is mostly the NVD’s fault (and they’re
in a different department of the federal government). The problem is that,
given the over 300,000 CVE records today - and the fact that new records are
being added at an increasing rate (last year, 40,000 were added, vs. 28,800 in
2023) – it is impossible to perform truly automated vulnerability management. I
define that as a single process that goes through an organization’s software
inventory, looks up all those products in the NVD or another vulnerability
database, and identifies all open vulnerabilities for those products (the next
action would be remediation, or at least bugging the supplier to patch the
vulnerabilities. This can’t be fully automated).
A vulnerability record without a machine-readable software
identifier isn’t complete; it’s like giving somebody a car without a steering wheel.
Until the CVE Program can ensure that every CVE record has a reliable
identifier for any affected product described in the text of the record, they
will receive an “Incomplete” record from me.
If you would like to comment on what you have read here, I would love to hear from you. Please comment below or email me at tom@tomalrich.com.
[i] While
it would certainly be better to specify a version range in a CVE record than
just enumerate affected versions, in fact version ranges are a very difficult
problem, as I discussed in this post. It
is fairly easy to specify a version range in a CVE record, but, unless the end
user has a way of utilizing that range as part of an automated vulnerability
management process in their environment, it’s useless to include it in the record
in the first place.
[ii] Some
of CPE’s problems are described in detail on pages 4-6 of this
2022 white paper on the software identification problem. It was written by the
OWAS SBOM Forum, a group that I lead.
[iii] The
NVD has somewhat improved their record for enrichment, but it seems a lot of
their recent effort isn’t being well
directed.
No comments:
Post a Comment