What To Look For in an Open Source Vulnerability Scanner

One of the top security concerns we hear from technology leaders is about the security of open source software (OSS) and cloud software development. An open source vulnerability scanner (for scanning OSS) helps you discover risk in the third-party code you use. However, just because a solution scans open source does not mean you are ultimately reducing security risk with it. Here is what to look for in an open source vulnerability scanner and security testing solution to find and fix vulnerabilities in OSS.  

Background on Vulnerabilities in Open Source and What the Risk Looks Like 

Before we can talk about what to look for in a scanning solution, we need to talk about the vulnerabilities the tools are looking for. Born in 1999, the National Vulnerability Database (NVD) was a product of the National Institute of Standards and Technology (NIST) made to be “the U.S. government repository of standards based vulnerability management data.” It represents an index of known vulnerabilities and makes use of the Common Vulnerability Scoring System to catalog the vulnerabilities and their severities. 

This repository is a resource used by security professionals and researchers to understand and track application of required patches or to derive exploit conditions used in the generation of exploit code. Another repository similarly used is Exploit Database. I have personally written my own security research code from both of these indexes such that I could understand the real world implications of exploitation scenarios. 

The problem is that adversaries use these repositories, too. The threat here is that people uncover a security vulnerability, and now all the opportunists attackers also know there is a new exploit for something. Chances of exploitation move from the metaethical pursuits of a skilled hacker to one where the method of detection and exploitation is indexed in a search engine, in many cases with downloadable exploit code examples. The race is truly “on” if you are still vulnerable by the time a CVE is assigned a name and an ID value in the database. 

First Top Factor: Size and Active Curation of a Proprietary Database 

The first factor to look for in a tool for detecting vulnerabilities in OSS is what it is scanning for. Sure, it inventories libraries (and, hopefully, indirect libraries), but can it protect applications because it knows what to look for?  

Consider the limitations of a public repository like the NVD that relies on public input. When confronted with a security vulnerability, most developers will remediate the vulnerable code or move the item to the blacklog. What most developers will not do is seek to add cycles by following to "responsibly disclose" the vulnerability to the NVD.  

The point to be made here in looking for a solution is about the pedigree and proprietary data that your solution is scanning against. Anyone can inventory libraries and match them with indexed vulnerable OSS library versions.  

If you are worried about security, only consider vendors that solve for the security use case by asking: How many sources of vulnerability information outside of the NVD are matched against my libraries? What areas of growth are the vendors investing in to bring additional security value and enrich their proprietary data sets? 

Second Top Factor: Vulnerable Methods Detection 

Make sure your OSS vulnerability scanner is tackling the most pioneering research in OSS vulnerability detection: vulnerable methods. This has to do with following paths of code execution through invocation of known vulnerable code; it is determining the point of exploitation. Let me explain further.  

Being vulnerable because of open source happens because your first party application code invokes an open source library where execution processes vulnerability-afflicted code. Vulnerabilities targeted with intentionally malicious malformed data lead to exploitation.  

You are not vulnerable to a particular OSS security vulnerability unless you actually touch the portion of code that is vulnerable. In other words, you are not vulnerable simply because you have x.y.z version of a library in your inventory; you are vulnerable if you invoke execution of the afflicted code.  

Understanding that you are invoking the method that contains the afflicted code is like the analogy of horseshoes and hand grenades. If you have this information, you are more likely to know when things go boom.   

How does the scanner know what to look for and if it is truly vulnerable? Be sure to challenge your representative with this question when looking for an open source vulnerability scanner. 

Third Top Factor: Including Transitive Dependencies 

Direct dependencies often depend on other libraries known as transitive dependencies. This means that indirectly introduced code and vulnerabilities happen beyond the open source code explicitly introduced by a developer. 

Veracode’s State of Software Security: Open Source Edition found that 70.5 percent of the applications contain an open source flaw, and of those applications, 46.6 percent of the flaws were transitive. Clearly, indicating detection of transitive vulnerabilities is a vital quality in tooling for open source vulnerability management that reduces real security risk. 

When it holds true that your database holds proprietary information, AND you can determine code invocation of an afflicted method, AND you can do it at the point of any OSS dependency in the call chain, then you have a real world-class technology that is focused on security.   

Fourth Top Factor: Ability to Generate Software Bill of Materials (SBOM) 

The ability to generate a Software Bill of Materials (SBOM) is a critical factor in the open source vulnerability scanning solution you choose. Highlighted in the United States’ Executive Order on Improving the Nation’s Cybersecurity, SBOMs come up frequently with our prospects and customers. If you are not being asked for these already, then you will be. 

SBOMs are generated to tell you the inventory of your applications. You generate the SBOM to build trust with someone considering your application services, so they understand the existing risks within these applications. In turn, you will begin to ask others so that you understand the risks associated of code you intend to execute within your environment. Veracode Software Composition Analysis (SCA) enables generation of SBOM in CycloneDX and SPDX formats, which are approved formats for compliance with the above Executive Order. 

Why Go Commercial vs Open Source in a Scanning Solution 

Here is a caution about using an open source tool for open source vulnerability scanning. Even if you picked an open source scanner, it is just doing NVD look up. Open source tools are not curating all the necessary proprietary data for protecting applications. Often these are written by a security researcher, and once the theoretical minimally viable project is over, the researcher moves on. 

Final Tip for Quantifiable Risk Reduction from an Open Source Vulnerability Scanner 

It is worth keeping in mind that the ultimate goal of your open source vulnerability scanner is to help you reduce risk. Here is an additional note about first-party code and third-party libraries you want to consider.  

Static Application Secuity Testing (SAST) is used to scan first party code, and Software Composition Analysis (SCA) is used to look at what libraries and packages developers are using that other people wrote. Think of containers as the turtle shell and the application as the turtle. If your tool is only giving you an inventory of the shell, it is not telling you what the shell is protecting which means there are many blind spots in the results. And remember, every CVE started out as a flaw in first party code, and then it was given a record in the index.   

Putting the information from all these tools together is a nightmare if they are not integrated on a unified platform like Veracode. Schedule a demo today, and let us help you secure cloud development at scale.