Today, Patrick Garrity of VulnCheck
sent me this link to
a blog post they just put up. Here’s a very high-level summary:
1.
VulnCheck, which
operates a vulnerability database that’s based on data from the National
Vulnerability Database (NVD), is announcing that their NVD++ database, which
they started offering for free after the NVD’s near-collapse early this year, has
generated CPE names for 76% of new CVE records added to the NVD since February.[i] This compares with the NVD,
which has only created CPEs for about 41% of new CVEs.
2.
If that were all that
VulnCheck did, I wouldn’t be very impressed. The biggest problem with CPE is
that there’s no way to ensure that two people working with the same information
about a software product will produce identical CPE names for the product (see this
post
for more information on that). Since creating CPEs is technically NIST/NVD’s
sole responsibility, when and if the NVD finally gets back up to full speed,
there’s no assurance they will accept CPE names created by any third party
besides CISA, whose Vulnrichment program has a special status. This means that
users of NVD++ who are using VulnCheck’s CPE names in their internal
vulnerability management process face the real prospect of having to replace
all of those with whatever CPE names the NVD comes up with.
3.
However, VulnCheck has
addressed this potential problem by basing all their new CPEs on CPEs that have
already been created by the NVD (these are found in the mis-named “NVD
Dictionary”, which is just a list of every CPE that the NVD has created). Thus,
it is likely that VulnCheck’s CPEs will be accepted by the NVD when it is
running properly again, and VulnCheck’s users will not have to replace them in the
future.
Does this mean I have changed my longtime
opinion that purl is a far superior identifier to CPE, and vulnerability identification
using purl is much more accurate than it is using CPE? Not at all. Currently, for
open source software, purl is much better than CPE.
However, the same cannot be said
for commercial software, since purl currently does not have a way of
identifying it. This is why the OWASP SBOM Forum is proposing
to develop new purl “types” that will make it possible for purl to identify
commercial software products[ii]. This, coupled with the
fact that purls can now be included in CVE records (previously, only CPEs could
be used), means that in a few years there will be vulnerability databases
(perhaps including the NVD) in which it will be possible to search for
vulnerabilities in both open source and commercial software products using purl
– although CPEs will continue to be created and used for many years and may
never be totally abandoned.
I’ll be honest that it will be
probably 4-5 years before purl becomes widely used to identify commercial
software, although it may never be as dominant there as it is now for open
source software (where it’s very hard
to say there’s even a “number two” identifier. This despite the fact that less
than ten years ago, purl was literally nowhere).
I have been thinking that, given the
NVD’s current problems, there’s literally no fully automated way to identify vulnerabilities
in commercial software; it’s quite sad to think that this situation could
continue for the next 4-5 years. If VulnCheck can come close to taking the place
of the NVD during that time (and maybe afterwards as well), the whole software
world will be much better off.
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.
No comments:
Post a Comment