The Open Source Risk and How to Mitigate It

Open source software is ever growing, in number of projects and in adoption. The last decade has presented a massive and consistent growth in the use of open source products and libraries throughout the software development lifecycle. According to Delloite, the cumulative number of open source projects had a compound annual growth rate of 79% between 2008 and 2018. Furthermore, the Open Source Security and Risk Analysis Report 2021 (OSSRA) by Synopsis shows that out of 1546 codebases audited for the report, 75% of all codebases were composed of open source. This growth of open source brings a significant risk with it, many times going unnoticed. In this article we will explain why open source dependencies are one of the biggest risk factors of your application and how you can manage that risk and mitigate it.

The Risk of Open Source dependencies

More often than not, software development teams use open source dependencies. There are so many reasons why. First and foremost, it speeds up software development by order of magnitude. It allows development teams to focus on the core business logic of the application, and let others take care of the rest. It reuses code and eliminates the need to rewrite the same code over and over again. And finally, it provides a widely used, widely tested, state of the art software libraries that do one thing but do it very well.

According to the OSSRA, 84% of the codebases audited for the report had at least 1 vulnerability, with an average of 158 vulnerabilities per codebase, coming from those open source dependencies. The average age of these vulnerabilities was 2 years old.
Another recent report by the cyber security company Imperva, “Lesson Learned from Analyzing 100 Data Breaches” shows that 24.1% of these data breaches were initiated by vulnerability exploitation. To complete the picture, Cyber Security report 2021 by Check Point shows that 75% of attacks in 2020 exploited vulnerabilities that are at least 2 years old.

Even OWASP started ranking ‘using components with known vulnerabilities’ in their OWASP top 10 most critical web application security risks since 2013, taking the 9th place in 2017 and going up to 6th place in 2021.

These data points depict a truly worrisome picture of the state of application security - vulnerabilities are taking a significant part in facilitating attacks, serving as their starting point. Nonetheless, many known vulnerabilities are staying unpatched for years, making it only a matter of time until these vulnerabilities are exploited to facilitate a data breach.

Dependency Scanning

The risk of open source dependencies must be contained. Vulnerabilities should be discovered, assessed, and prioritized for remediation. And this should be done as soon as possible in the software development lifecycle.
Dependency scanning tools can help with the process of assessing and remediating open source software vulnerabilities. A Dependency scanning tool, similar to SAST tools, scans the code dependencies files or package managers to find vulnerable dependencies in the application. It builds a dependency tree, including transitive dependencies, which are typically overseen since they’re not explicitly used by the application code but rather by other dependencies that are used by the code. Then it iterates over that tree, checking each dependency for publicly known CVEs (Common Vulnerability Exposure) and other known vulnerabilities published in various vulnerability databases such as NVD and the like. The check is simple - each vulnerability affects a certain version of an open source library, and if that version matches the version used in the application, then the application is vulnerable. The tool presents the list of vulnerabilities discovered in the scan, specifying the details and severity of each vulnerability, as well as remediation steps, which typically just indicate to what version the open source library should be updated. Some tools go even further, allowing for automatic patching of vulnerable dependencies, which makes it automated and ready to integrate seamlessly into the CI/CD pipeline.

A Real World Example

There’s nothing like a good and simple example to see how simple and great a Dependency Scanning tool can be for your software development lifecycle and for the security posture of your applications in general.
Apache Tomcat is a widely used open source Application Container for Java web applications. Let’s try and add a dependency to it in a Java application, by adding it as a dependency in the pom.xml:

Despite its popularity, or perhaps due to it, Tomcat has had quite a few critical vulnerabilities over the years. Integrating a Dependency Scanning tool into our IDE can provide visibility into the risk of using Apache Tomcat as the application container of our application, and advise on which version is the safest for us to use.
Below is a screenshot taken from the Snyk IntelliJ plugin for dependency scanning:

On the left-hand side we can see a long list of known vulnerabilities found in version 7.0.0 of Apache Tomcat which we chose to use in our application. On the right side we see the details of a Remote Code Execution vulnerability, including the risk score (CVSS), an overview of the vulnerability and some other related information. It also lists the Tomcat versions in which this vulnerability was fixed. All neds to be done is to update the version used in the pom.xml to the above said version, and the vulnerability is gone. It really is that simple.
The above example emphasizes the need to run the dependency scanning tool as early as possible in the SDLC - changing the version just as the dependency is added is dead simple, just a one line change with a few numbers. Changing it late in the SDLC, after a lot of code was developed is costly as it might require a lot of code changes to adapt to the new version.

Integrating a Dependency Scanning Into the SDLC

Open source dependencies can be scanned for vulnerabilities in production or on the codebase as a scheduled task. But as seen in the example above, that would be too late, since the discovered vulnerabilities are already running in production, imposing a significant risk on the production workload. On top of that, the cost of fixing vulnerabilities at that stage is fairly high.
Instead, dependency scanning tools can and should be integrated early in the software development life cycle (SDLC). With the Shift Left approach in mind, it can integrate at the leftmost part of the SDLC - the Integrated Development Environment (IDE) allowing for a short feedback loop, providing results just as dependencies are added to the code, and making the fix simpler and the cost minimal. To close the loop, it also integrates with Continuous Integration and Continuous Deployment (CI/CD) pipelines to make sure the codebase stays clean of vulnerabilities further down in the SDLC, serving as the last gate before the deployment to production. This combination allows us to assess and remediate vulnerabilities just as they’re introduced in the code, and move the responsibility and ownership of the codebase security to the software development team.

If you automate dependency scanning within your CI/CD pipelines, setting thresholds for allowed risk scores and allowing automatic patching, you are actually practicing Security as Code (SaC) that can dramatically improve your security posture and reduce your security costs.