Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

02:00 PM
Robert Former
Robert Former
Connect Directly
E-Mail vvv

3 Tips for Securing Open Source Software

Maintaining myriad open source components can be tough. Here's how teams can begin to address open source security and continue to innovate.

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:


As chief information security officer and vice president of security, Robert Former leads the governance, risk, compliance and security practices at Acquia. Robert has most recently held roles at Pegasystems as senior director of compliance and at HP/HPE/Micro Focus as senior ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Attackers Leave Stolen Credentials Searchable on Google
Kelly Sheridan, Staff Editor, Dark Reading,  1/21/2021
How to Better Secure Your Microsoft 365 Environment
Kelly Sheridan, Staff Editor, Dark Reading,  1/25/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: I can't find the back door.
Current Issue
2020: The Year in Security
Download this Tech Digest for a look at the biggest security stories that - so far - have shaped a very strange and stressful year.
Flash Poll
Assessing Cybersecurity Risk in Today's Enterprises
Assessing Cybersecurity Risk in Today's Enterprises
COVID-19 has created a new IT paradigm in the enterprise -- and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-01-25
The MediaWiki "Report" extension has a Cross-Site Request Forgery (CSRF) vulnerability. Before fixed version, there was no protection against CSRF checks on Special:Report, so requests to report a revision could be forged. The problem has been fixed in commit f828dc6 by making use of Medi...
PUBLISHED: 2021-01-25
ORAS is open source software which enables a way to push OCI Artifacts to OCI Conformant registries. ORAS is both a CLI for initial testing and a Go Module. In ORAS from version 0.4.0 and before version 0.9.0, there is a "zip-slip" vulnerability. The directory support feature allows the ...
PUBLISHED: 2021-01-25
An XML external entity (XXE) injection vulnerability was discovered in the Nutch DmozParser and is known to affect Nutch versions < 1.18. XML external entity injection (also known as XXE) is a web security vulnerability that allows an attacker to interfere with an application's processing of XML ...
PUBLISHED: 2021-01-25
When handler-router component is enabled in servicecomb-java-chassis, authenticated user may inject some data and cause arbitrary code execution. The problem happens in versions between 2.0.0 ~ 2.1.3 and fixed in Apache ServiceComb-Java-Chassis 2.1.5
PUBLISHED: 2021-01-22
Pepperl+Fuchs Comtrol IO-Link Master in Version 1.5.48 and below is prone to an authenticated reflected POST Cross-Site Scripting