Open source projects provide software development teams with well-built libraries and frameworks which they can freely use in their projects to improve the speed and efficiency of software development.
Despite the pros of open source projects, there are issues with security risks and code vulnerabilities when using components from such projects. The majority of commercial applications contain open source components, and one study reported a concerning finding that 78 percent of codebases contained at least one open source vulnerability.
This article informs you of some of the main open source security risks and vulnerabilities you should know about in 2019.
Slow Vulnerability Remediation
One of the biggest security risks that still continues to plague commercial software development teams is the issue of remediating vulnerabilities too slowly after a fix has already been released.
Anyone familiar with some of the major data breaches and cybersecurity incidents over the last couple of years will know that in many cases, those vulnerabilities were disclosed well in advance of the incidents happening. Furthermore, patches already existed to fix the vulnerabilities and prevent exploits.
A case in point on the danger of slow remediation is the Heartbleed software bug. Heartbleed is the name of a vulnerability in the OpenSSL cryptographic library. The vulnerability was discovered and patched in April 2014. However, it was reported in 2017 that the Heartbleed bug still persisted in over 200,000 servers worldwide, potentially exposing those servers to data breaches and information theft.
Apache Struts Vulnerabilities
The slew of vulnerabilities to hit the popular Apache Struts web application framework in recent years means it deserves a category all of its own when discussing open source security risks.
A high-profile 2017 Struts vulnerability led to the compromise of sensitive information on over 145 million of the credit reporting company Equifax’s U.S. customers. A further critical vulnerability was found just over a year later in the same framework.
The number of Struts vulnerabilities provides a compelling argument for seeking out an alternative web framework to Struts. Check out this Struts vulnerabilities article for some pros and cons when making a decision on whether to continue using this framework.
Publicly Available Exploits
A paradox of making open source vulnerabilities publicly available is that it is simultaneously both a help and a hindrance. The helpfulness of public disclosure is that it spreads information on vulnerabilities far and wide so many development teams can take rapid action to patch the affected component.
On the contrary, a public disclosure also increases the probability of attackers exploiting a given vulnerability. From the perspective of a hacker, manually going through millions of lines of code in various open source libraries and frameworks hoping to find a security flaw is incredibly inefficient.
The value of publicly available information is that it spares hackers much of their work. These hackers can trawl through sources like the National Vulnerability Database (NVD) and attempt to build exploits for the various vulnerabilities recently disclosed.
Developer Neglect
Popular development approaches and philosophies like Agile and DevOps place huge pressure on developers to improve the speed of development and the frequency at which they deliver software updates and new features.
The risk is that the pressure modern developers face can lead to neglect when it comes to security. When security takes a back seat, bad habits such as copying and pasting the code directly from open source projects are more likely to creep in.
Copying and pasting code reduces the ability to track all dependencies on open source components. Research from one security audit on 500,000 apps containing open source components found that 78 percent of the vulnerabilities were from indirect dependencies.
Furthermore, because many developers are so constrained by time pressures, they have little time to help out with quality control for the open source projects they enjoy using. The fewer people actively maintaining a project, the more likely vulnerabilities will emerge and remain unpatched.
Lack of Open Source Security Standards
There is no accepted standard for making open source projects secure and documenting that security. So, no matter how much of a tight ship a development team runs for its internal code checks, there is a risk of using vulnerable code from an open source project in which security hasn’t been prioritized or formally checked.
A 2019 open source survey found that just 30 percent of developers who maintain open source projects are highly confident in their security knowledge. While this figure has increased from the previous year, it still shows that a lack of security standards, knowledge, and prioritization exposes many companies to risks from using external code.
Closing Thoughts
The open source model is clearly beneficial to development teams. However, a greater appreciation of the security risks and vulnerabilities of open source projects is important. Some tips for mitigating the security risks in this article include:
- Apply patches, updates, or otherwise remediate affected components as soon as you find out about a vulnerability.
- Check vulnerability databases often for new disclosures and act rapidly to remediate any affected components your development teams use.
- Make informed decisions on whether to continue using projects like Apache Struts that are affected by frequent severe vulnerabilities.
- Consider using a tool that can automatically track all your open source components.
