Open source code has become an essential part of applications used across industries. The latest Open Source Security and Risk Analysis report found open source code in over 96% of the more than 1,200 codebases audited for the study. Moreover, 60% of all the code contained in those codebases was open source.
These are just some of the open source security metrics that matter, according to the study, conducted by the Synopsys Cybersecurity Research Center. It also found an average of 298 open-source components in each codebase in 2018, a 16% increase over 2017's tally.
Among the reasons for the reliance on open source: "Developers need to push things out as quickly as possible to maintain their competitive advantage," said Ken Prole, chief technology officer for Code Dx, maker of a software vulnerability management and security analytics tool.
"To build software from scratch today would be kind of silly. Developers and product managers want to focus on the business value that they're providing rather than the plumbing of an application."
—Ken Prole
While there are many benefits to using open source code, there are risks you should measure, too. Chris Morales, head of security analytics for Vectra Networks, a provider of automated threat management tools, said the risk was inherent.
"[Leveraging existing code comes with] the greater risk of adopting existing and known vulnerabilities. Attackers scan networks looking for these vulnerabilities that allow exploitation of devices."
— Chris Morales
But there are ways to reduce the risks associated with open source code. Here are four must-do action items for application security teams.
1. Patch open-source components ASAP
Unpatched software vulnerabilities are one of the biggest cyberthreats organizations face, and unpatched open-source components in software add to the security risk, Synopsys noted in its report:
"The open-source community does an exemplary job of issuing patches, often at a much faster pace than their proprietary counterparts. But whether companies are using proprietary or open-source software, an alarming number of them don't apply patches, opening themselves to risk."
Tardy patching is a problem across organizations, but the open-source "pull" model, where users need to seek fixes instead of waiting for them to arrive automatically, can be more than many organizations can handle.
Most organizations are accustomed to working with a software vendor that services its software, with the vendor pushing updates to the organization, said Tim Mackey, a principal security strategist at Synopsys.
"In the land of open source, that relationship doesn't exist unless the consumer actively pursues it. That can lead to a situation where patches aren't applied in a timely fashion and could even be years out of date."
—Tim Mackey
News about fixes is distributed through RSS feeds, emails, or GitHub issue lists. "If you're an IT person in a large company and you're not looking in those types of places, you're not going to be aware of the fixes," Mackey said.
How automation and containers can help
Automation is essential for most organizations serious about keeping their open-source components secure.
"It can be very tedious to patch components manually. A lot of applications have hundreds of components that they're leveraging. Trying to keep track of all that is nearly impossible."
—Ken Prole
Automation is important, not only to keep tabs on which components need security patches, but also to ensure that patching is done quickly, said Jeff Williams, CTO and co-founder of Contrast Security, a maker of self-protecting software.
"Organizations must be able to respond to new OSS vulnerabilities within a day, as attacks begin almost immediately after new flaws are disclosed."
—Jeff Williams
Containers can help lighten the load of discovering and mitigating vulnerabilities in open source code. "A container image packages up application code along with all its dependencies, giving you a self-contained unit that you can check for vulnerabilities," said Liz Rice, technology evangelist at Aqua Security Software, maker of a container security platform.
"You can find container image-scanning solutions that will check all dependencies in your container images and alert you to any security vulnerabilities, and even provide remediation information."
—Liz Rice
2. Perform a full inventory
Even organizations with the best intentions toward timely patching are waging an uphill battle if they don't maintain an accurate, comprehensive, and up-to-date inventory of the open-source components contained in their applications, finds the Synopsis report:
"Even if you have an ongoing initiative to develop a comprehensive inventory of your IT systems, including all the software components for each system, your inventory might not be complete or current at any given time. An incomplete inventory makes it extremely difficult to maintain adequate software asset management procedures."
Nowhere was that more evident than at Equifax, which in September 2017 had a data breach that compromised the sensitive information of 145.5 million Americans. Citing an internal audit by Equifax, the US Senate Permanent Subcommittee on Investigations noted in a report on the breach:
"Equifax lacked a comprehensive IT asset inventory, meaning it lacked a complete understanding of the assets it owned. This made it difficult, if not impossible, for Equifax to know if vulnerabilities existed on its networks. If a vulnerability cannot be found, it cannot be patched."
When organizations use open-source components as building blocks they ultimately take responsibility for code they did not write, explained Steve Springett, project leader for OWASP Dependency-Track, an open-source software composition analysis tool.
It's critically important for organizations to document which third-party and open-source components are in applications, to evaluate whether they have any known vulnerabilities, whether customers have the latest versions, and whether users have any licensing or other risks, he said.
Springett added that organizations should inventory open-source components in their own software and in the commercial software they buy.
"Organizations should acquire a software bill of materials from their vendors. That way I know what third-party components are in that application, and I can proactively monitor those components for any known vulnerabilities."
—Steve Springett
3. Beware of licensing conflicts in your code
Open-source software may be free software, but it's not unlicensed software. Those licensing arrangements can be a source of risk for an organization using open-source components.
There are multiple types of open-source licenses, from very open, such as the MIT license, to much more controlled, such as the GNU General Public License version 3, explained Lamar Bailey, director of security research and development at Tripwire, a cybersecurity threat detection and prevention company.
"It is very important to verify the license and adhere to the terms. Some licenses require very little, where others require you to contribute any changes back to the community."
—Lamar Bailey
In its report, Synopsys found that 68% of the codebases studied contained licensing conflicts.
Those conflicts create risks for open-source users. The biggest risk is that "the source code for their intellectual property might need to be disclosed," Synopsys' Mackey said.
For example, an organization may want to keep tight wraps on the code of an application, but it may use an open-source component with a reciprocity clause in its license. This clause says that if the component is used in an app, then the app must be open source and its code exposed to the public.
"The desire to keep everything in trade-secret land could go out the window because of the license of a single component."
—Timm Mackey
Prole added that it can be daunting to keep tabs on all the licensing requirements in all the open-source components in an application. Indeed, the Black Duck KnowledgeBase lists more than 2,500 licenses associated with software whose source is freely available on the Internet. However, much of that software does not meet the strict definition of "open source" established by organizations such as the Open Source Initiative or the Software Package Data Exchange.
Black Duck, which is owned by Synopsys, also found that 98% of all open source code now in use is covered by 20 of the most popular licensing agreements.
"You also have a problem with dependency chains. You might have a component you want to use, it has a license you can live with, but you're trusting that it's not using any components in violation of licensing."
—Ken Prole
Aqua's Rice said that many organizations are naive about their responsibilities when it comes to license compliance. "The situation is not helped by it being a challenge to figure out what licenses are in play across a complex matrix of dependencies," she said.
There are initiatives to help reduce that challenge, she continued, such as the Software Package Data Exchange (SPDX) and FOSSology. Both are under the rubric of the Linux Foundation, which supplies standards for sharing and querying license information.
4. Watch your codebase for obsolete components
Open-source components can also pose operational risks to an organization when they've been abandoned. Synopsys found that 85% of the codebases it studied contained open-source components that were more than four years out of date or had no development activity in the last two years.
"The use of components that aren't actively maintained must be avoided," said Fausto Oliveira, principal security architect at Acceptto, a provider of cognitive continuous authentication. "There might be vulnerabilities and defects lurking in those projects and, by using those components, the organization is incurring additional risks."
"Without an active community, those components are simply too risky to use in production. Unless the organization is willing to maintain the code project, it must avoid using 'fossil' code."
—Fausto Oliveira
It's best to select a component that has a healthy environment, Prole agreed. "You want a lot of maintainers and maybe a company behind it, versus something that might be one person."
"[They may be] passionate about it for three to six months, then they go on to do other things, and anyone depending on that project is stuck. Developers have to be aware of that when they're selecting components."
—Ken Prole
Be fully aware of the risks
In its report, Synopsys said that organizations using open-source components often overlook the security and licensing risks associated with them.
While the efficiencies and cost savings of code reuse are clear, "organizations rarely review the incoming code regularly for potential security and legal issues," the report said.
Too few companies manage their developers' use of open source, and too few can produce an accurate inventory of open-source components, licenses, versions, and patch status, it said. "Thus, they remain uninformed about their open source risks and obligations."
The report added that proper management of open-source software isn't only about security—it's also about license management:
"Whether a license is one of the most popular OSI-approved licenses or a one-off variant, unless organizations are aware of the rights, obligations, and restrictions of using a specific open-source component, they can't be sure whether they comply with those obligations. Noncompliant organizations could theoretically lose rights to their proprietary code or call into question the ownership of their IP."
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
