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 therespondents 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.
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.
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.
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.
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 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.
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.
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."
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.
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 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 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 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.
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.
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.
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.
How are you handling security concerns from the open-source components of your codebase?
This article appeared first at teachbeacon.com