Analysis of over 1,200 codebases reveals trends in open source use, security, and license compliance that affect your development, security, and legal teams.
It’s a fact. If you create software today, you’re using open source components.
The latest estimates are that 99% of all but the smallest applications include open source components. What are the chances that your applications are among that other 1%? Less than the chances that you’re among the top 1% on the personal net worth scale.
And while it’s likely you’re using open source, research in the 2019 Open Source Security and Risk Analysis (OSSRA), an annual report published this week by the Synopsys Cybersecurity Research Center (CyRC) that examines trends in open source, suggests that it’s also likely there are gaps in the way you track and manage open source. Ignoring these gaps can leave you exposed to both security and legal risks. The OSSRA highlights these risks and suggests some actions you can take to help.
The 2019 Open Source Security and Risk Assessment (OSSRA) is the latest publication from CyRC, the Cybersecurity Research Center, an initiative that leverages Synopsys’ expertise, technology, initiatives, and resources to conduct high-quality primary and secondary software security research. CyRC publishes its findings for the benefit of the broader security, developer, and DevSecOps communities.
Let’s examine some of the open source trends unearthed in the 2019 OSSRA.
Open source more ubiquitous than ever
This year’s report, based on Black Duck audits of more than 1,200 software applications and libraries spanning 17 industries. It finds, to nobody’s surprise, that open source is more ubiquitous than ever: The average audited codebase contained 298 open source components, up 16% from 2017.
Eight of the 17 industries covered by the audits were using more open source than proprietary code, with the average ranging from 58% to 78%. In politics, that’s in supermajority territory.
There are good reasons for the popularity of open source. No inventor produces new raw materials for every product they make. Instead, they focus on combining those raw materials in different ways for different purposes. Open source software offers abundant “free” raw material for software development—a foundation that fuels innovation, making development faster, more efficient, and cheaper.
Two main categories of risk
So while there are ample upsides driving open source adoption, there are some potential downsides that many teams fail to address. The first is you might be using open source unsecurely. Open source software comes with the same security risks that plague all software—bugs that hackers can exploit.
Second, you might be using open source illegally. Open source components are available for use at no cost. But they all have license requirements, and these are sometimes complex. Fail to comply, even out of ignorance, and you could be in legal trouble.
As shown in the OSSRA report, even though open source use has become ubiquitous, many teams still aren’t taking adequate measures to address these potential downsides.
Security, vulnerabilities, and patching
Let’s be clear. Open source software itself is no riskier than proprietary or commercial off-the-shelf (COTS) packages. The real risk comes from the way organizations track and manage it—or don’t.
One key difference is in the way security patches are distributed. Most commercial software vendors automatically push patches out to users. But with open source distribution varies, and while some components have support similar to commercial software, most require users to track and download patches themselves. It’s a “pull” model, not a “push” model.
Open source vulnerabilities are disclosed through a wide variety of sources, like the National Vulnerability Database (NVD), US-CERT notifications, mailing lists, and project sites. The NVD listed more than 16,500 new vulnerabilities in 2018. Of those, 7,393 were in open source products. And more than 40% of those vulnerabilities were labeled high-risk. That’s a lot to keep track of, and it’s the user’s responsibility to monitor both vulnerabilities and fixes and to make sure they’re installed.
This assumes that an organization is reliably tracking all the open source components they use. However, as the OSSRA report indicates, many don’t. In fact, more than 95% of audits found open source that the target didn’t know was there. Even organizations with sophisticated development processes often don’t have the capability to track components, versions, and their vulnerabilities manually.
Equifax is perhaps the most high-profile, stark example of this. The catastrophic breach of the credit reporting giant in 2017 was the result of a failure to patch a vulnerability in the open source web application framework Apache Struts. Did they see the security alerts? They did, but they didn’t patch their applications, because they weren’t tracking the fact that they were using Apache Struts in them.
Am I using open source securely?
The way to avoid that kind of risk is through an automated solution to track and manage the open source components you use. It may sound like a cliché (though it’s true), but you can’t patch it if you don’t know you’re using it.
Are there unpatched open source vulnerabilities in your code? Probably, but data in the OSSRA report suggests you aren’t alone. Of the applications audited in 2018, 60% had vulnerabilities—and while that’s concerning, it’s a marked improvement from 78% in 2017. Perhaps more concerning, 43% of those applications had vulnerabilities that were more than 10 years old. One, CVE-2000-0388, a high-risk vulnerability in FreeBSD, was first disclosed in 1990—and is now 28 years old. That’s probably older than many of the developers on your team!
License rights, obligations, and compliance
Open source software may be free, but that doesn’t mean “free of any obligation.” As shown in the report, there are over 2,500 unique open source licenses today, each defining a set of usage terms and obligations users must agree to in exchange for that free access. At a minimum, these terms mean (1) the source code is available for inspection and modification and (2) anyone can use it, as long as they comply with the license.
An open source license allows users to use, modify, or share the source code. But—and here is where it can get sticky—those allowances come with defined terms and conditions. Open source doesn’t mean “free to use however you like.” It means “free to use if you play by the rules.”
Am I using open source legally?
While there are a lot of open source licenses in the wild, most components are using a much smaller set. As shown in the report, the 20 most popular licenses cover about 98% of the open source in use.
What about the over 2,480 other licenses? While they may not be as common, the real question is, What are their obligations, and how do you ensure you’re complying with them? Confirming this becomes a daunting task if you don’t have a tool that allows your legal teams to define up front the terms you can comply with so you can identify and address problematic components during development.
The 2018 audits found open source license conflicts trending downward from 2017 in most of the industries audited. While that’s an encouraging sign, the license conflict rates ranged from 52% to 79%.
Finally, the report notes that even if open source components have no identifiable license terms, you’re not off the potential litigation hook. Black Duck Audits found that 75% of companies had codebases with unknown licenses. In general, the absence of a license means no one can use, modify, or share the software without the explicit permission of its creators. This is because creative work (which includes code) is under exclusive copyright by default.
How to mitigate your open source security and license risks
Obviously, it’s not enough simply to be aware of open source trends. Knowing what other organizations are doing is a step in the right direction. But to minimize your own risks, you have to change what you’re doing. The way to realize the benefits of open source and avoid the downsides is to track it—all of it—so you can mitigate both security and legal risks.
You can’t do this manually. But you can do it with a software composition analysis (SCA) solution like Black Duck, which allows you to automate open source discovery, vulnerability detection, and license compliance as part of your SDLC.
*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Synopsys Editorial Team. Read the original post at: https://www.synopsys.com/blogs/software-security/open-source-trends-ossra/