Despite increased awareness of the security vulnerabilities in the open source code, those responsible for fixing the vulnerabilities are either taking longer than ever to do this, or are not fixing them at all.
That is just one of the startling findings contained in the 2018 Open Source Security and Risk Analysis (OSSRA) report compiled and published recently by the Synopsys Centre for Open Source Research and Innovation.
This year's OSSRA report examined data from more than 1 100 commercial codebases audited in 2017 by Black Duck's On-Demand audit services department.
The findings regarding the lack of urgency with which known vulnerabilities are being treated is particularly concerning, given that the adoption rate of open source continues to accelerate.
According to Forrester Research analyst Amy de Martine, only 10% to 20% of all new code in applications can be considered proprietary. The rest is open source. Writing in The Forrester Wave Software Composition Analysis Q1, 2017, she pointed out that not only is open source becoming increasingly ubiquitous, but one of every 16 open source download requests is for a component with a known vulnerability.
The Black Duck On-Demand audits found a similar proliferation of open source code. Of the codebases that were analysed for the 2018 OSSRA, the researchers found that between 2016 and 2017, the average percentage codebase that was open source increased from 36% to 57%. In addition, open source components were evident in 96% of the applications scanned, with an average 257 components per application.
Worryingly, not only did nearly 80% of the codebases examined contain at least one vulnerability, with an average of 64 vulnerabilities per codebase, the Black Duck researchers also found that the average age of the vulnerabilities was increasing.
On average, vulnerabilities identified in the audits had been disclosed nearly six years ago, compared to the four years reported in the 2017 audit. This suggests that those responsible for applying vulnerability fixes are either taking longer to do so, or not doing anything about it at all, thus allowing a growing number of vulnerabilities to accumulate in codebases.
So, for example, despite the enormous publicity surrounding the vulnerabilities in Apache Struts following the Equifax data breach, the researchers found that 8% of the audited codebases contained Apache Struts and, of those, 33% still contained the Struts vulnerability.
In addition, 4% of the codebases examined also still contain Heartbleed with its critical security flaw that can expose secure communications, four years after its disclosure.
According to the report, it's often the very openness of open source that can contribute to its vulnerability. Open source is not inherently more vulnerable than custom code.
The onus for keeping track of and fixing vulnerabilities in open source code rests with the users. However, many don't, either because they don't know how or don't think the risk is worth the effort of applying the fix. Increasingly, the problem arises because they actually don't know exactly which open source code they are using.
And so, known vulnerabilities in Apache Struts, Heartbleed and the like, as well as lesser known vulnerabilities, continue to be perpetuated.
Share