Did you know that up to 90 percent of an application typically consists of third-party components, mostly open source? And did you know that more than 50 percent of the Global 500 use vulnerable open-source components?
In today's software development environment, an enormous amount of work is crowdsourced to a large community of open-source developers and communities with very little understanding of the security problems that this creates, let alone ways to manage this risk. We all know that we can't stop using open source, and we know that no one wants to stop using it. In a survey by BlackDuck software, 43 percent of the respondents said they believe that open-source software is superior to its commercial equivalent.
Open source is powerful, and the best developers in the world use it, but it's time to stop ignoring the security concerns and start tracking the dependencies in your software. First I'll give you a quick analysis of the ongoing security problem of open-source software dependencies as they relate to security risks, then I'll wrap things up with a list of tools that you can start using now to get ahead of the curve on this issue.
Software dependencies are often the largest attack surface
Organizations usually assume most risks come from public-facing web applications. That has changed. With dozens of small components in every application, risks can come from anywhere in the codebase.
While bugs like Heartbleed, ShellShock, and the DROWN attack made headlines that were too big to ignore, most bugs found in dependencies often go unnoticed.
There are several reasons for this problem. For starters, most organizations do not have accurate inventories of software dependencies used by different applications. Additionally, most organization don't have reliable means of being notified when zero-days are found or when patches are made available, other than a meager notification from the community supporting the project.
Open-source vulnerability information is fragmented
Most organizations search the CVE and NIST Vulnerability Database for vulnerability information, but these sources provide very little information on open-source vulnerabilities. Information on open-source vulnerabilities is distributed among so many different sources that it's very hard to track it.
Adding insult to injury, OSVDB, which was one of the largest vulnerability databases that was mostly dedicated to tracking open-source-specific vulnerabilities just closed shop, following others such as SecurityFocus. Although that led to the emergence of other security repositories such as the Node Security Project for JavaScript/Node.js-specific vulnerabilities and RubySec for Ruby-specific vulnerabilities, there are still a lot of projects and ecosystems that just aren't well covered.
Organizations still believe that open source code is more secure
The misconception about open source being more secure started with what's known as Linus' Law—named in honor of Linus Torvalds and formulated by Eric S. Raymond in his essay and book The Cathedral and the Bazaar—and Linus' famous quote:
"Given enough eyeballs, all bugs are shallow."
—Linus Torvalds
This statement might have been relevant when the book was first published, in 1999. However, it is far from relevant nowadays, considering that a bug such as ShellShock existed in the OpenSSL library for more than 22 years. The biggest problem is that organizations still believe that open source code is more secure than commercial code; just read this Reddit thread to understand how people view this topic.
Don't get me wrong. I am not suggesting that open source is less secure than commercial. What I am saying is that without intentional effort to secure a piece of code (open source or not), that code is not secure. Intentional efforts mean activities such as code inspection by trained "eyeballs," dynamic security scanning, and penetration testing, among other things.
The open-source ecosystem is more fragile than we think, and that's scary
The whole dependency ecosystem is fragile. A recent incident gave the entire NodeJS community a brutal reality check as one programmer almost broke the internet by deleting 11 lines of code. Attackers could have easily taken the namespaces of these packages, bumped the version, and added malicious code replacing the actual expected code.
Luckily, one nonmalicious developer was able to grab over 240 of said packages before they fell into the wrong hands.
Trying to fix the problem
OWASP recognized this problem and added "Using Components with Known Vulnerabilities" to the OWASP Top 10 in 2013. This is the definition of the issue according to OWASP:
"Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defences and enable a range of possible attacks and impacts."
Different open-source and commercial tools have emerged over the years to tackle this problem. Each tool/service tackles the problem a bit differently, so my consulting firm has reached out to the project leaders and company CEOs to get their feedback on how they believe their tools contribute to the solution and where they see their tools' future.
Node Security Project (NSP)
The NSP is known for its work on Node.js modules and NPM dependencies. It also provides tools that scan for dependencies and find vulnerabilities using public vulnerability databases such as the NIST National Vulnerability Database (NVD) as well as its own database, which it builds from the scans it does on NPM modules.
Adam Baldwin from the NSP sees a future where dependency security is part of the SDLC: "Soon you will see a number of products from us including continuous security monitoring and integration with GitHub (and other products) so that you can plug in security monitoring, detection, alerting, and remediation for the areas of your development lifecycle that are relevant to you."
RetireJS
RetireJS is an open-source, JavaScript-specific dependency checker. The project is primarily focused on ease of use. That's why it has multiple components, including a command-line scanner and plugins for Grunt, Gulp, Chrome, Firefox, ZAP, and Burp. RetireJS also made a site-checking service available to JS developers who want to find out if they're using a JavaScript library with known vulnerabilities.
RetireJS retrieves its vulnerability information from the NIST NVD as well as a multitude of other sources, including mailing lists, bug-tracking systems, and blogs for popular JavaScript projects. Erlend Oftedal from RetireJS thinks that security is everyone's problem and more collaboration is needed: "I would like to see authors of popular open-source frameworks themselves start reporting security fixes to tools such as Retire.js in order to keep the users of their software safer."
OSSIndex
OSSIndex supports several technologies. It extracts dependency information from NPM, Nuget, Maven Central Repository, Bower, Chocolatey, and MSI (which means it's covering the JavaScript, .NET/C#, and Java ecosystems). OSSIndex also provides a vulnerability API for free.
OSSIndex currently retrieves its vulnerability information from the NIST NVD. Ken Duck from OSSIndex plans to include automated importing of vulnerabilities from some key mailing lists, databases, and bug-tracking systems in the near future.
Dependency-check
Dependency-check is an open-source command line tool from OWASP that is very well maintained. It can be used in a stand-alone mode as well as in build tools. Dependency-check supports Java, .NET, JavaScript, and Ruby. The tool retrieves its vulnerability information strictly from the NIST NVD.
Bundler-audit
Bundler-audit is an open-source, command-line dependency checker focused on Ruby Bundler. This project retrieves its vulnerability information from the NIST NVD and RubySec, which is a Ruby vulnerability database.
Hakiri
Hakiri is a commercial tool that offers dependency checking for Ruby and Rails-based GitHub projects using static code analysis. It offers free plans for public open-source projects and paid plans for private projects. It uses NVD and the Ruby Advisory Database.
Vasily Vasinov from Hakiri says that future plans for the software include adding integrations with Slack, JIRA, and Pivotal Tracker as well as supporting other platforms such as Node.js and PHP.
Snyk
Snyk is a commercial service that focuses on JavaScript npm dependencies. New to the scene, Snyk is in a league of its own. Not only does it offer tools to detect known vulnerabilities in JavaScript projects, but it also helps users fix these issues using guided upgrades and open-source patches that Snyk creates.
Snyk has its own vulnerability database, which gets its data from the NIST NVD and the NSP. Snyk's focus is on scaling known vulnerability handling across the entire organization and its teams, with better collaboration tools and tighter GitHub integrations. Snyk's CEO, Guy Podjarny, indicated that Snyk's future plans include building runtime tools that will give developers better visibility and control when running open-source packages on production systems.
Gemnasium
Gemnasium is a commercial tool with free starting plans. Gemnasium has its own database that draws from several sources. However, though the vulnerabilities are reviewed manually on a daily basis, advisories are not automatically published.
Gemnasium provides a unique auto-update feature that uses a special algorithm to test smart combinations of dependency sets instead of testing all the combinations, which saves a bunch of time. Gemnasium supports Ruby, NPM (JavaScript), PHP, Python, and Bower (JavaScript). Another unique offering from Gemnasium is its Slack integration—users are notified through Slack in real time as soon as an advisory is detected.
Philippe Lafoucrière from Gemnasium indicated that future plans include an enterprise version of Gemnasium, running on clients' premises with more languages supported, starting with Java.
SRC:CLR
Source Clear is a commercial tool with a couple of interesting attributes. It has its own database, which leverages the NIST NVD, but it also retrieves vulnerability information from mailing lists and several other sources.
It offers a ton of plugins to several IDEs, deployment systems, and source repositories, as well as a command-line interface. Finally, Source Clear is using "vulnerable methods identification," which is a way to figure out whether a vulnerability found in a dependency is actually being used by the application. It's a feature that dramatically reduces false positives and gives developers detailed target reports for the vulnerabilities that matter. Source Clear just announced plans to offer a free version of its software.
Honorable mentions
BlackDuck Software, Sonatype's Nexus, and Protecode are enterprise products that offer more of an end-to-end solution for third-party components and supply chain management, including licensing, security, inventory, policy enforcement, etc. SecurifyGraphs is a tool from Software Secured, my consulting firm, which helps compare open-source projects based on their CVSS risk scores.
How are you handling security concerns from the open-source components of your codebase?
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.
