When we scanned 1,250 applications, it quickly becomes clear how ubiquitous open-source components are in application development. None of the scanned applications—that's zero percent—consisted of only bespoke code. Every application had at least one open-source component, and 84% of applications consisted of more than half open-source code, as we reported in the 2019 Application Security Risk Report.
In 2016, I wrote about the issue of open-source components and, while vulnerable open-source issues were a concern back then, the situation has only grown more serious.
Today, almost every application uses open-source components as part of an application framework, to speed development, or to use a technical feature such as SOAP or two-factor authentication.
Open-source components make sense because developers can adopt a standard framework at zero cost with public code that they can pick apart, if they want. Yet, the use of these components can expose companies to attack, adding another step to vulnerability management and opening up downstream applications to implanted malware and possible backdoors.
Since developers will use open-source coding frameworks despite the hazards, they need to account for the potential risks and trade-offs that they are assuming by relying on these frameworks. If the project maintainer does not focus on security and if developers don't regularly patch their components and push those updates to production, your applications are at risk.
Unfortunately, this problem does not have an easy solution. Abandoning open source is a non-starter: Public projects are too important and foundational to cast aside. Companies need to have their own configuration management, and a record of which open-source components are in use, and where those components are included. And of course, you need to be tracking the right metrics with regard to open source and security.
Here are two ways to use open source safely.
Figure out your model
In most cases, development teams need to adopt one of two models: Either provide only approved software components for developers to use, or give them the tools to create their own lists of safe libraries and other bits to use.
If you have the capacity to create amd maintain a repository of approved software from which developers can pull, that's the way to go. It's the best method for keeping insecure components out of your code. And this applies to other infrastructure components—most notably, containers—as well.
Yet this puts the repository manager on the hook for being responsive to requests. It's a big burden. Two-thirds of companies use open-source software to speed development, and more than half use open-source infrastructure components in production, according to the 2016 Future of Open Source study. That number is on the rise. If a developer wants to try a new component, and the repository manager can't turn it around quickly, then the developer will find ways to circumvent the repository.
To implement this successfully, make sure that developers can make a decision quickly and that there is a process, and people to support that process. That takes commitment, and not everyone can pull it off. In 2016, for example, half of all companies had no formal policy for the use of open source code in their environments.
Letting developers roll their own
The converse of this approach is to give software developers the tools and the responsibility to maintain their own list of components. Products such as Sonatype's accomplish this, and their results can be combined with static application security testing (SAST) tools to give insight into what components are being used.
One key factor to consider: If a common application component is discovered to have a vulnerability, can your company quickly determine all the applications that also have that component and take action to update them or otherwise secure them?
However, the effectiveness of this approach from a security point of view is still a significant question.
Update early and often
Whichever method you use, developers need to recognize that they now have a two-stage development pipeline. First, they must watch for changes and vulnerability reports in the components they integrate into their software.
This is important because the number of serious vulnerabilities reported in open-source components is climbing. The number of critical vulnerabilities jumped in 2018 to 55% of all security issues, up from 27% in 2017. Many of these issues have been in the code for years and have only recently been reported and fixed.
The second stage is for developers to push out the updated application in their own code. Using reliable, quickly updated components makes no difference if developers are not compiling the updates into their own code and pushing the changes out to their customers.
All eyes on malicious inserts
Finally, developers need to not just plug in software for needed functionality without thinking about potential malicious code inserted into the components. Online attackers have started looking at the supply chain.
In November 2018, for example, the project managers for the Node Package Manager (NPM) project issued an alert that cyber criminals had inserted code into the EventStream component used by as many as 6 million developers. The ultimate goal: Compromise the small percentage of users that had an account on a particular bitcoin exchange and steal the coin.
In its 2019 State of the Software Supply Chain Report, Sonatype found that one in 10 Java components had a security vulnerability and documented more than a dozen cases in the past two years of attackers directly injecting vulnerabilities into foundational open-source components with the goal of later exploitation.
The threat landscape is continuing to shift and, if you don't watch your apps, they will use your open-source components against you.
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.
