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
Threaded  |  Newest First  |  Oldest First
Where Are the 'Great Exits' in the Data Security Market?
Dave Cole, Cofounder and CEO, Open Raven,  10/13/2020
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
US Counterintelligence Director & Fmr. Europol Leader Talk Election Security
Kelly Sheridan, Staff Editor, Dark Reading,  10/16/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-10-20
IBM Sterling B2B Integrator Standard Edition through and IBM Sterling File Gateway through are vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially lea...
PUBLISHED: 2020-10-20
IBM Spectrum Scale 5.0.0 through is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 188517.
PUBLISHED: 2020-10-20
IBM Spectrum Scale 5.0.0 through does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link ...
PUBLISHED: 2020-10-20
IBM Spectrum Scale 5.0.0 through is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 188595.
PUBLISHED: 2020-10-20
IBM Spectrum Scale V4.2.0.0 through V4.2.3.23 and V5.0.0.0 through V5.0.5.2 as well as IBM Elastic Storage System 6.0.0 through could allow a local attacker to invoke a subset of ioctls on the device with invalid arguments that could crash the keneral and cause a denial of service. IBM X-For...