Application Security Testing Evolution and How a Software Bill of Materials Can Help

Early in my career, I developed web applications. At the time there were practically no frameworks or libraries to help.  I was coding with Java using raw servlets and JSPs – very primitive by today's standards.  There was no OWASP Top 10 and writing secure code was not something we paid much attention to.   

I specifically remember coding an open redirect years ago.  I didn't know it was a vulnerability at the time.  In my mind, it was a great feature for my Java servlet to recognize a special query string parameter that, if present, would trigger a redirection to the given URL!  Interestingly, a dynamic scan or penetration test of the application would not have found my vulnerability.  The name of the parameter was undocumented and not easy to guess.  On the other hand, static application security testing (SAST) or a manual code review would have found it.   

My first stint at Veracode was in 2012, after six years working as an application security consultant.  It was exciting to join an up-and-coming company on the cutting-edge of AppSec testing.  Since then, open source software has grown enormously and proliferated in all aspects of application development.  Building apps today is faster because of how easy it is to integrate these components into our own projects.  Package managers and open source registries like Maven repository, NPM registry, PyPI, and RubyGems.org provide a way for developers to quickly access and leverage a rich plethora of ready-to-use libraries and frameworks. 

The downside with this model of building applications is that vulnerabilities present in open source components are inherited by our software as well.  This has resulted in many data breaches over the years (Equifax via Apache Struts comes to mind).  One of the reasons I recently re-joined Veracode is to have the opportunity work with a premier Software Composition Analysis (SCA) tool.  SCA is complementary to SAST.  While SAST checks 1st-party code for security flaws, SCA looks at 3rd-party code like open source libraries.  In terms of the OWASP Top 10, this falls under OWASP #9 – Using Components with Known Vulnerabilities.   

If your application is using a vulnerable component, it's not necessarily your fault.  The vulnerable component may be present because a library that your code is using directly has a dependency on another library.  This is called a transitive dependency.  Transitive dependencies are pulled in automatically by build systems, aka package managers.  Data from our State of Software Security: Open Source Edition report shows that 71 percent of applications have a vulnerability in an open source library on initial scan, and that nearly half of those (47 percent) are transitive.  

Now let's talk about a software bill of materials (SBOM).  An SBOM lists the individual components that are included in a piece of software.  This can help with identifying vulnerabilities or license risks that may affect your organization. The concept of an SBOM is not new, but it's garnered much more interest lately due to the recent U.S. Cybersecurity Executive Order.  One of its requirements is having an SBOM for all critical software sold to the federal government.  

There are different SBOM specifications in the marketplace today.  I will focus on CycloneDX, which was recently accepted as a flagship OWASP project.  CycloneDX is a security-focused SBOM specification and capable of describing the following types of components: 

• Application 
• Container 
• Device 
• File 
• Firmware 
• Framework 
• Library 
• Operating System 
• Service 

CycloneDX's supported data formats are XML, JSON, and Protobuf.  Here's an example of a CycloneDX SBOM in JSON format: 

​

Right away we can see that the software represented by this SBOM includes one library –Apache's Commons Collections version 3.2.1.  We also have the purl (package URL) of the library, which is a standardized way to identify components across different programming languages and package managers.   

One of the most important aspects of an SBOM is to understand if the software in question includes components with known vulnerabilities.  In the example here, the purl can be leveraged for this purpose.  It includes the version number, which is critical since different versions of the component may be vulnerable while others are not. 

Important to note is that an SBOM does not necessarily inform you directly if vulnerabilities exist in the components.  You'll typically need to use a tool like Veracode SCA or take the time to check each component manually.  Using an SCA tool is much more efficient, especially because many vulnerabilities are never added to the National Vulnerability Database (NVD), so you simply won't know about them.  The Veracode vulnerability database supplements the public NVD with thousands of vulnerabilities that were never announced or assigned a CVE ID, and it's continuously updated with both public and non-public vulnerability data. 

Note that our example SBOM includes license information as well.  This helps you understand if your software is using a component with a strong copyleft license that would require you to release your code as open source.  The library in this example was released under the Apache 2.0 license, which has no copyleft provision and suggests very minimal risk.  A URL to the full license text is present in this example.  CycloneDX also provides a way for the full license text to be embedded into the SBOM directly. 

Finally, the hash values in the SBOM enable you to verify the integrity of the component to ensure it hasn't been tampered with.  CycloneDX also supports authenticity checks via digital signatures. 

Besides what's been discussed here, SBOM specifications like CycloneDX can provide additional information applicable to various use-cases.  Examples include: 

• Evaluating the age and health of components. 
• Understanding the dependencies among components. 
• Parent-child/nesting relationships of components. 
• Component authorship/supplier information. 
• Pedigree information like ancestors, variants, and others. 
• Metadata about the SBOM (software author, tools that generated the SBOM, etc.). 
• External references to security advisories. 

Expect to hear more about SBOMs as time goes on.  Security teams and developers alike can leverage SBOMs to confirm that the software they're using, purchasing, or building is free from known vulnerabilities and components with unacceptable licenses.  This in turn can provide evidence that their organization is meeting compliance requirements.  And as mentioned above, SBOMs will be especially important for software vendors that sell to the U.S. government due to the requirements in the executive order.