Why Should We Look to Check Security Risk?
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? Clearly, open source components are growing in popularity, and it is important to regularly check security risk in these areas.
Today, the software development environment has an enormous amount of work crowdsourced to a large community of open-source developers and communities. Yet, there is 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. Recently, 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. However, 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 and why you should check security risk. Then, I’ll wrap up with a list of tools to start using now to get ahead of the curve.
Software dependencies are often the largest attack surface.
Organizations usually assume most risks come from public-facing web applications. That has changed. Now, dozens of small components are in every application. As such, risks can come from anywhere in the codebase.
Bugs like Heartbleed, ShellShock, and the DROWN attack made headlines that were too big to ignore. In reality, 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. Typically, they only have a meager notification to check security risk from the community supporting the project.
Open-source vulnerability information is fragmented.
Most organizations search the CVE and NIST Vulnerability Database for vulnerability information. Unfortunately, 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.
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. Linus’ Law is named in honor of Linus Torvalds and formulated by Eric S. Raymond in his essay and book The Cathedral and the Bazaar. 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. 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, etc.
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. Consequently, 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. One example is the NIST National Vulnerability Database (NVD). Alternatively, NSP has 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. RubySec 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, the vulnerabilities are reviewed manually on a daily basis. As such, advisories are not automatically published.
Philippe Lafoucrière from Gemnasium indicated that future plans include an enterprise version of Gemnasium. The new version would run 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. 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.” This 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. Additionally, it also gives developers detailed target reports for the vulnerabilities that matter. Source Clear just announced plans to offer a free version of its software.
Or Check Security Risk With Our 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.
What are your plans to check security risk for the open-source components of your codebase?
This article appeared first at teachbeacon.com