Eric S, Raymond famously stated in his seminal work on open source software The Cathedral and the Bazaar that “Given enough eyeballs, all bugs are shallow.”
It is doubtful that at the time he said his now oft-repeated line that Raymond had any idea that we would see such a significant jump in the number of software vulnerabilities in such a short period of time.
With the exception of a small spike in 2014 — the year that the Heartbleed vulnerability was discovered and everyone started turning over logs to find other bugs — vulnerabilities in the CVE database were rising steadily but moderately.
Then in 2017, we saw it more than double from 6,447 in 2016 to 14,714, knocking everyone off balance.
So far no one has offered a satisfactory answer as to why we are seeing this increase. With 2018 closing with 16,555 CVEs listed for 2018, this trend shows no sign of slowing down for 2019.
There are however a number of probable factors that we need to consider.
Mo’ code, mo’ problems
To start off, there is more code being written by more people, and not all of them have the experience to write high quality and secure code. Even as the software revolution had been going strong in the years leading up to the 2017 spike, one of the biggest shifts we have seen in the industry is the rise of IoT and more services becoming available online through applications.
These devices and services have come in the form of wearables, smart home devices, and applications for basically everything from the electric company to ordering lunch. Part of the issue is that you have a lot of businesses which have never made software products turning to third-party software houses that can build their apps. The problem is that these are very much off-the-shelf kind of apps and lack the support and dedication that an in-house product would have received. Because the speed of delivery is a higher priority for these software-producing vendors that sell to their client businesses, quality and security can suffer if the right precautions are not taken.
We can rebuild it, we have the technology
Many of these mistakes, as well as those which come in software products produced by more reputable firms like Microsoft, Cisco, and others, might have lain dormant if it wasn’t for the steady forward march of
Security tools are getting a lot better at not just catching problems in the software that we are writing now, but also in our older projects that have already been deployed. As organisations are going through their software to search for vulnerabilities that might be hidden away in the foundations of their software, they are uncovering many of these security flaws which have gone unnoticed.
A RAND Corporation study on zero days from 2017 found that while 25 per cent of vulnerabilities are discovered within a year and a half, another 25 per cent can last upwards of nine and a half years. As technology for vulnerability tracking and remediation tools gets better, embracing automation to sift through the lines of code, chances are that more of these vulnerabilities will turn up and be reported. By who and why is a question that we can address a little later when we think about incentive models.
Attacks like the Equifax breach where a known vulnerability in a popular version of the open source Apache Struts project was used to break into their database have proved to organisations that vulnerabilities can be buried in the most stable and trusted versions of their software.
Open source is eating the world
These days, open source components are playing a bigger role in software development than in the past by providing important features for developers to help them push their products out faster, saving them the time and effort of having to write much of the software on their own.
While many large organisations are just starting to admit and even embrace their use of open source components in recent years, it is only really since the discovery of the Heartbleed vulnerability in 2014 that the corporate community has taken notice of how a vulnerability in an open source project that they are using can hurt such a wide range of products.
By some estimates, open source components comprise 60-80 per cent of the code base in modern applications. The problem is that for many years, the use of open source was not well regulated within organisations, leading to many open source components with known vulnerabilities being added to software products, putting them at risk.
This creates a situation where we have two separate paradigms of relationships. On the one hand, many thousands of organisations could be making use of a single open source project, so a vulnerability in one project can threaten many. At the same time, with a wider base of contributors from both the community as well as enterprises such as Microsoft, Google, Intel, and others adding their open source projects to the pool, we come back to the issue of more code leading to more vulnerabilities.
Working to a more secure future
Thankfully, we are seeing all of the actors here stepping up and taking an increasingly active role in promoting the discovery of new vulnerabilities in our software.
Programs like bug bounties have brought about a shift in how companies relate to security researchers who find and report vulnerabilities. Whereas they used to (we should note that some still do) threaten researchers with legal action, White Hats can now get paid for reporting responsibly which is good for everyone involved.
While these efforts to uncover software vulnerabilities are welcome and important, it is still up to the community of developers to take their findings to heart and patch when necessary. If we are being honest, then we know that we still have a ways to go on this front, but like we learned from G.I. Joe, knowing is half the battle.
Rami Sass, CEO and Co-Founder, WhiteSource
Image source: Shutterstock/TechnoVectors