Open source bugs have soared in the past year

Open source bugs have skyrocketed in the last year, according to a report from open source licence management and security software vendor WhiteSource.
The number of open source bugs sat steady at just over 4,000 in 2017 and 2018, the report said, having more than doubled the number of bugs from pre-2017 figures that had never before broken the 2,000 mark.
Then, 2019’s numbers soared again, topping 6,000 for the first time, said WhiteSource, representing a rise of almost 50%.
By far the most common weakness enumeration (CWE – a broad classifier of different bug types) in the open source world is cross-site scripting (XSS). This kind of flaw accounted for almost one in four bugs and was the top for all languages except C. This was followed by improper input validation, buffer errors, out-of-bound reads, and information exposure. Use after free, another memory flaw, came in last with well under 5% of errors.
WhiteSource had some harsh words for the national vulnerability database (NVD), which it said only contains 84% of the open source vulnerabilities that exist. It adds that many of these vulnerabilities are reported in other places first and only make it into the NVD much later.

[…] how can we expect teams to prioritize vulnerabilities efficiently when over 55% are high-severity or critical?

FIRST, which organises CVSS, didn’t reply to our request for comment but we will update this article if they do.
Expect to see the number of bugs rise over time, predicted the report. It pointed to GitHub’s recently announced Security Lab as a key development in open source bug reporting. GitHub, which hosts many open source products, has an embedded disclosure process that will encourage project maintainers to report vulnerabilities, it said.
The 2017 bug spike isn’t specific to open source, which happens to be WhiteSource’s focus here. We saw a corresponding spike in general bugs as reported in the CVE database in 2017. However, the number of overall bugs reported as CVEs actually dipped below 2017 levels last year.

Update 17 March

With the introduction of CVSSv3, many new concepts, previously unavailable in earlier versions of the CVSS specification, were introduced.  These included: Scope, Attack Complexity, User Interaction, and Privileges Required.  Additionally, detailed analysis was performed by over 20 active CVSS SIG members.  To produce the CVSS v3.0 formula, the SIG framed the lookup table by assigning v3.0 metric values to real vulnerabilities, and a severity group (low, medium, high, critical). Having defined the acceptable numeric ranges for each severity level, the SIG then collaborated with Deloitte & Touche LLP to adjust formula parameters in order to align v3.0 metric combinations to the SIG’s proposed severity ratings.
The resultant scoring curve represents, in the representative members’ opinions, a more applicable and apt scoring of vulnerabilities, compared to previous versions of CVSS.  A quick review of the CVSS Scoring Examples for v3.0 and v3.1 show how this realignment has helped provide better alignment of the severity ratings with heuristic expectations for various types of vulnerabilities.  For example, CVE-2014-3566 (POODLE) changed from a CVSSv2 score of 4.3 to a CVSSv3.0 score of 3.1, while CVE-2012-1342, an access control list bypass, was raised slightly from 5.0 (v2) to 5.8 (v3).  Famously, cross-site scripting vulnerabilities were woefully under-scored in CVSSv2 (e.g. CVE-2013-1937) and brought more in line with real-world impact (4.3 → 6.1).

Finally, it’s not unreasonable to assume that there may be some instances of “vendor disclosure bias” where a CVE ID or external advisory is not pursued for vulnerabilities on the lower end of the CVSS spectrum.  This could give the impression that most [public] vulnerabilities have relatively high scores along the intended CVSS normal curve.

Latest Naked Security podcast