The image below is what you saw if you search the National Vulnerability Database (NVD) on February 16. As you can see, vulnerabilities are being added on a daily basis. The far right column, however, is blank. None of the vulnerabilities are being scored using NIST’s Common Vulnerability Scoring System (CVSS).
It’s not just today’s vulnerabilities, however. One has to scroll to the 41st page of listings to find the first scored vulnerability, dating back to February 2!
What’s happening? It appears to be simple backlog. Since February 2, 910 vulnerabilities have been published in NVD without CVSS scores, far more than usual during such a short period of time. NIST appears to be following a plan that favors providing partial information in earlier disclosure.
That’s a decent trade-off for consumers of NVD, assuming you have sufficient security resources to investigate these vulnerabilities internally. Unfortunately, that’s not usually the case. Security teams are almost always stretched thin. The first filter from any vulnerability feed are going to be: a) are my products affected; and b) how severe is the vulnerability. The missing CVSS scores eliminates the ability to apply the latter item, without a considerable amount of work calculating scores.
Application defenders are already in a race with adversaries to patch reported vulnerabilities. Without this basic information, users of NVD will not be able to triage vulnerabilities efficiently.
This is why Black Duck Hub tracks vulnerabilities from multiple sources, and scores them independently of NVD. Our enhanced vulnerability data includes roughly 30% more vulnerabilities for open source components (compared to NVD) and reports them 15 days earlier. Coupled with a complete accounting of all open source components (a software bill of materials), Hub users can quickly determine which applications may be vulnerable to new issues, and prioritize them based on CVSS score.
There are, of course, additional activities for determining your course of action. However, knowing which components contain vulnerabilities, which applications use those components, and having a base level security severity score is a necessary first step.