3 Tips for Securing Open Source Software

Open source code is a part of roughly 99% of commercial codebases, according to research from Synopsys. Most developers prefer using open source software because of its flexibility and the pace of innovation within open source communities. However, the same study shows that 75% of audited codebases contain open source components with at least one known vulnerability. A primary culprit: The use of out-of-date software that's no longer maintained by the open source community. 

Many proprietary software companies still try to spread fear around increased open source risks, when, if properly managed, the opposite is true. A Purdue University study showed that open source communities have more eyes on security vulnerabilities and risks, and issue patches faster than proprietary software. Bug bounties are also becoming more prevalent in open source; for example, the European Commission offered funding in 2019 for 14 open source bug bounty programs.

Even so, the onus is often on users to install the most up-to-date security patches provided by open source communities. This can make security a challenge. Many engineering teams are spread too thinly to think about maintaining the myriad open source components within their technology stack. So how do organizations address open source security issues and continue to innovate at the same time?  

Here are three tips to get started.

Embrace Secure Software Development
Within many organizations, security and engineering teams share responsibility for security. That can make the issue of who "owns" open source security murky. More advanced teams embrace a secure software development lifecycle (SSDLC), where security becomes an integral part of every stage in the development process. This approach requires that engineers are trained in secure coding best-practices. Red teams pressure-test the systems engineers build to ensure that nothing slips through the cracks.

Regardless of who finds a vulnerability -- whether it's a software engineer, internal pentester, a white hat hacker, or otherwise -- it's a moral imperative to fix these bugs quickly and share fixes publicly with everyone in the open source community. The more eyes on open source software, the better everyone is protected against potential security threats.

Dedicate Time to Managing Risk 
The same open source security study cited above showed that 91% of codebases contained components that either were more than four years out of date or had seen no development activity in the last two years. Most active open source communities update software and regularly issue patches for known vulnerabilities. When major open source projects or their dependencies (the external code a project depends on) become outdated, communities sunset the software (also known as end-of-life) and offer a new version.

However, if no one internally updates the software, that's where the issues arise. The now- infamous Equifax breach is a prime example. In 2017, Equifax confirmed that hackers exploited a vulnerability in open-source Apache Struts. A patch for the vulnerability was issued in March, and hackers exploited the bug to break into Equifax servers two months later. 

To avoid these types of issues, organizations should dedicate 20% of engineering time to managing open source risks. This includes consistent patch and vulnerability management, as well as staying on top of end-of-life deadlines. With time and practice, this 20% may decrease, depending on internal risk assessments.

Embrace Automation Wherever Possible
Managed open source can help resource-constrained teams stay on top of open source security. Most commercial open source software vendors offer automation and/or services that can help customers maintain their open source components, alleviating the pressure on internal teams to manage everything themselves.

Many code repositories also offer ways to automate security checks for open source components. For example, GitHub's dependencies graph lets developers see all of the packages their software depends on, as well as any vulnerabilities detected within these dependencies. As of recently, developers can automate these patches.

Some leading-edge open source communities are taking the responsibility of security into their own hands by offering automatic security updates. For example, auto updates are a major initiative recently announced by the Drupal community.

To sum up, open source security thrives in an environment of radical transparency. Teams shouldn't wait for SecDevOps to become mainstream; instead they should embrace a SSDLC and actively work with red teams to identify and fix vulnerabilities. If companies are transparent about the bugs they find and fix them in the open, the entire community wins.

Related Content: