The number of vulnerabilities in open source projects surged almost 50 per cent in 2019, according to security biz WhiteSource, which can be seen as good news in the sense that you don't find what you're not looking for.

In its annual vulnerability report, the biz attributes the growing vulnerability count with increased awareness of open source security. That's a consequence of widespread adoption of open source components and the overall growth of the community in recent years, not to mention media attention of data exposure.

In other words, the bugs were always there but they're more visible because we're paying closer attention.

Over 6,000 open source vulnerabilities were reported last year, up from just over 4,000.

"No code is perfect and there are always vulnerabilities that can be found," said Rami Sass, CEO and co-founder of WhiteSource, in an email to The Register.

"The problem with open source vulnerabilities is that, like everything in the open source community, once something is reported all the information is public and every beginner hacker can learn the vulnerability and it’s exploitation and then execute it on a large number of applications."

On the plus side, 85 per cent of these vulnerabilities get disclosed with a fix, a good sign for responsible disclosure.

But community awareness of vulnerabilities has not translated into effective communication about them. Only 84 per cent of known open source vulnerabilities eventually show up on the National Vulnerability Database (NVD), and often after some delays.

And when vulnerabilities get reported outside the NVD, only 29 per cent eventually get published there, according to WhiteSource's figures. That means vulnerability information may not be easy to find and fewer flaws are likely to get fixed in a timely manner.

Nonetheless, WhiteSource credits community-focused initiatives like GitHub's Security Lab with helping security researchers, project maintainers, and software users report issues and centralize information more easily.

The survey also looked at the number of open source project vulnerabilities by programming language and how those numbers have changed over time.

Language 2009-2018 2019 C 47% 30% C# 6% 9% Java 11% 15% JavaScript 10% 10% PHP 15% 27% Python 6% 5% Ruby 5% 4%

WhiteSource says C still has the highest percentage of vulnerabilities because it's the most popular language in terms of lines of code, but has trended downward as other languages have become more popular.

The report notes, however, that "PHP’s relative number of vulnerabilities has risen significantly, while there’s no indication of the same rise in popularity. "

Python meanwhile has managed to have a low percentage of vulnerabilities with high popularity. "Hopefully, this is a result of secure coding practices and not lax security research for Python projects," the report says.

The most common Common Weakness Enumerations (CWEs) for 2019 were:

CWE-79 Cross-Site Scripting CWE-20 Improper Input Validation CWE-119 Buffer Errors CWE-125 Out-of-bound Read CWE-200 Information Exposure

When analyzed by programming language, the top three for all but C were:

CWE-79 Cross-Site Scripting CWE-200 Information Exposure CWE-20 Improper Input Validation

WhiteSource attributes the commonality of these flaws across languages to the use of automated scanning tools that know how to find these specific issues. Also, the firm notes, that Information Exposure is just a general issue across languages.

"CWE-79 (cross site scripting) is one of the easiest vulnerabilities to exploit for attackers, since there are many automated tools which make it approachable even for a 'rookie' hacker," said Sass, noting that CWE represents a category rather than a specific flaw.

HTTP/2, Brute! Then fall, server. Admin! Ops! The server is dead READ MORE

"Following the huge usage growth in the open source community, attackers are starting to see the potential in exploiting open source vulnerabilities. CWE-79 vulnerabilities are the go-to vulnerability for an easy and effortless hack. Taking this in mind, it’s quite logical that this massive increase occurred."

With a rising number of vulnerability reports, development teams benefit from being able to prioritize the fixing of critical bugs before looking at less severe ones. That has become more complicated, thanks to changes in the way the Common Vulnerability Scoring System (CVSS) rates the severity of flaws.

CVSSv2 debuted in June 2007 and CVSSv3 appeared in June 2015, with CVSSv3.1 showing up in June 2019. Each offers a slightly different definition of what constitutes a high severity vulnerability.

According to WhiteSource, the biggest change came with the shift from v2 to v3, which redefined a 7.6 severity bug (out of 10) under v2 as a 9.8 bug under v3.

Under v3.1, the severity distribution is not a normal distribution, WhiteSource contends, with 17 per cent of vulnerabilities being critical and only 2 per cent rated low.

That means more than half of rated bugs are either critical or high-severity, which makes it difficult to prioritize when pretty much everything should be fixed right away.

"As the number of reported vulnerabilities increases, the urgency to patch those vulnerabilities rises," said Sass. "However, development teams are struggling to keep up with the pace." ®