How to Analyze an SBOM

Analyzing SBOMs

Last year's Executive Order on Securing the Supply Chain kick-started tooling, workflows, and discussion around Software Bill of Materials (SBOMs).

My last blog detailed how to host and generate an SBOM. Let's assume we are all generating SBOMs for our software product and requesting SBOMs from our suppliers- what will we do with them?

One of the primary use cases with SBOMs is to analyze them for vulnerabilities and to see if any components can be an attack vector for your software product. SBOMs are especially powerful when critical new vulnerabilities, like Log4Shell, are discovered, and organizations want to know if and where they are affected.

Today, let us take a look at:

• Vulnerability terminology and the databases that disseminate information about discovered vulnerabilities.
• Open source tools to connect these vulnerabilities to SBOMs like Grype and Dependency- Track.
• Vulnerability remediation steps, like Cloudsmith’s quarantine feature.

What are vulnerabilities?

A vulnerability is a flaw in your software product that an attacker can exploit. Examples of critical vulnerabilities are Log4Shell, Heartbleed, Shellshock/Bash, and POODLE.

An SBOM of a software product combined with information on what components have a vulnerability will tell you the risks within your software supply chain. Continuously scanning SBOMs is an efficient way to check for new vulnerabilities in released software.

Before we dive into tooling on how to get vulnerability information of an SBOM, let's explain terminology and standards around vulnerabilities, including:

• CVEs.
• Scoring systems to prioritize vulnerabilities like CVSS.
• Data sources for vulnerabilities.
• How to communicate I am not vulnerable to a flaw.

Common Vulnerabilities and Exposures (CVEs)

The Common Vulnerabilities and Exposures (CVE) program is a list of publicly disclosed computer security flaws maintained by the MITRE corporation. There will be one CVE record per vulnerability, and each record will have an assigned CVE ID number and a brief description. Log4Shell’s CVE number was CVE-2021-44228.

CVEs don’t contain a risk rating or any technical data- that’s where CVSS, VEX, and Vulnerability Databases come into play.

Scoring Systems

The Common Vulnerability Scoring System (CVSS), overseen by First.org, is an open framework for rating the severity of vulnerabilities based on ease and impact on a scale from 1 (least severe) to 10 (most severe). The Log4Shell vulnerability was an easy-to-exploit remote code execution vulnerability with enormous reach and was assigned a CVSS severity of 10, the highest value a CVE can achieve.

The Exploit Prediction Scoring System (EPSS), also maintained by First.org, is an effort to estimate the likelihood that attackers will exploit a software vulnerability. CVSS measures severity while EPSS measures risk. EPSS uses CVSS scores as well as different signals like Twitter mentions to predict whether vulnerabilities will be exploited.

Data Sources for Vulnerabilities

In order to connect a component in an SBOM to a vulnerability, you need to use some data source of that vulnerability. Vulnerability databases are used to collect, maintain, and disseminate information about discovered vulnerabilities.

The information in vulnerability databases is not restricted to CVEs.

A security advisory, published to a vulnerability database like GitHub Security Advisories or PyPI Advisory Database, is a document describing a security vulnerability in a software product. Often a vulnerability is published to a security advisory or some ecosystem-specific database, and they will be allotted some ID while awaiting a CVE.

Major public vulnerability databases include:

• The National Vulnerability Database (NVD), run by the https://www.nist.gov/ (NIST), contains all vulnerabilities with CVEs.
• The Open Source Vulnerabilities (OSV) is a Google maintained VDB created to address many of the shortcomings of dealing with vulnerabilities in open-source software. It aggregates a broad range of publicly disclosed vulnerabilities that don’t necessarily have a CVE assigned. The OSV is intended to better support tracking vulnerabilities within open source software but is mappable to the CVE database. It includes information from security advisories that have adopted the OpenSSF Vulnerability format:
• GitHub Security Advisories
• PyPI Advisory Database
• Go Vulnerability Database
• Rust Advisory Database
• Global Security Database
• OSS-Fuzz
• LoopBack Advisory Database
  

Other vulnerability databases are proprietary, or you may have an internally managed vulnerability database not disclosed to the public.

How to communicate that I am not vulnerable…VEX

Not all vulnerabilities in a software product that apply to a software component are exploitable. A study by ShiftLeft, suggests that only 3% of OSS vulnerabilities are attackable.

Your software product may not be vulnerable to vulnerability because:

• You have patched the software
• The compiler does not load the affected code
• Some protections exist in your software to counteract this vulnerability

Alert fatigue and false positives are a massive concern for security professionals, and knowing how to prioritize attackable vulnerabilities would be hugely beneficial.

Vulnerability Exploitability Exchange (VEX) allows software creators to communicate the exploitability of vulnerable components to software consumers. It’s especially useful when sharing your software product’s SBOM with external users.

Its early stages for this standard and the tools around it are still emerging- Tools to help generate, consume and validate VEX include Dependency Track, Secvisogram, Grype, Fortress, and FACT.

Tools for Analyzing SBOMs for Vulnerabilities

How do we connect components in an SBOM with these vulnerabilities?

After generating an SBOM, Tom Alrich, co-leader of the NTIA Energy SBOM PoC and Supply chain cybersecurity consultant, suggests performing the following steps (and steps 2-4 should be repeated regularly):

1. Ingest SBOMs and retrieve the identifies of all components
2. Look up each component in the National Vulnerability Database (NVD) or the OSS Index database (or another vulnerability database), and identify any open CVEs that apply to them.
3. Stores each of these CVEs and temporarily assigns them a status of “exploitable.”
4. Ingests VEX docs and flag components as not exploitable where applicable. VEX and CVSS will help prioritize vulnerabilities.

Only Dependency-Track passed all of Tom’s steps- it’s a security tool many security professionals use for managing the supply chain in organizations and requires a level of knowledge and maintenance to host and use. Other tools are easier to set up and can be used to perform much of Tom’s steps above.

Let's examine some tools and how they can help us check for vulnerabilities in our SBOMs.

OWASP’S Dependency Track

Dependency Track is an open-source security tool from OWASP that consumes and analyzes SBOMs to monitor component usage proactively across an organization.

It has a rich API, good documentation, a huge community of users, and so many useful features, including:

• Integrations with your CI/CD, including Dependency-Track Jenkins Plugin and Dependency-Track GitHub Action.
• It has integrations with all the major public data sources of vulnerabilities, proprietary databases, and private vulnerability databases.
• It ingests not only VEX but EPSS data too.

Such a full-featured product will need security knowledge and specific Dependency Track knowledge to use and host the tool effectively.

SPDX to vulnerability tool

The spdx-to-osv tool can be used to produce an open source vulnerability JSON file based on information in an SPDX document. The Kubernetes project has used spdx-to-osv to search for vulnerabilities in their project.

Grype

Anchore’s Grype is an open source vulnerability scanner for container images and filesystems and has initial support for CycloneDX VEX documents. It works well with, Syft, Anchor’s open source tool that generates SBOMs for container images and filesystems.

Here's an example of a Github Action workflow that uses Grype, Syft, and Cosign with Cloudsmith (forked from Dan Luhring code). It continuously scans the SBOMs generated for each of your packages, leveraging Cloudsmith's quarantine feature, to automatically prevent any packages entering your pipeline with a vulnerability score higher than Critical.

DaggerBoard

DaggerBoard is a vulnerability scanning tool that ingests Software Bill of Material (SBOM) files (CycloneDX, SPDX) and outputs vulnerabilities in a human-readable format.

Sigstore’s Cosign

Although Sigstore can’t be used to find vulnerabilities in an SBOM, it helps host vulnerability information as a signed attestation in an OCI registry. This can be used to prove at build time- no vulnerabilities of a certain level were in the built artifact.

Cloudsmith’s artifact repository integrates with Cosign, and Cloudsmith’s help docs will show you how to attach an attribution here.

Vulnerability remediation

Now that we have figured out what components have a vulnerability and have prioritized them, remediation is the next step. We need a remediation workflow for your published artifact that fixes or neutralizes detected weaknesses.

What to do with your list of exploitable vulnerabilities:

• Notify the internal owners of the artifacts/images that their software contains a vulnerability, update the artifact, and alert users. CI/CD tools all have ways to notify participants of failures, including Github Actions, Buildkite, and Circle CI.
  
• Software vendors can notify customers.
  By distributing SBOMs to your customers, they can work the SBOM into their security processes to check for vulnerabilities.
  
  If a vulnerability reaches a certain threshold, you may want or be required to disclose the issue to your customers. You may also want to inform the user of the fix, the timeline for the fix, and possibly the VEX document to inform customers that you are not vulnerable.
  
  If you distribute your software to 3rd parties, you will need to know who has downloaded the compromised software and how to contact them. Cloudsmith allows users to distribute and license to 3rd parties using entitlement tokens. Using these entitlement tokens, you can track downloads by associating an entitlement token per customer.
  
• Stop an artifact/image from being deployed to production or downloaded. Cloudsmith’s artifact quarantine feature allows you to temporarily block any downloads of an artifact in a Cloudsmith artifact repository until you release the artifact from quarantine. Unlike deleting an artifact, you can restore access to the specified artifact at a later stage if required.
  
  This Github Actions workflow mentioned earlier shows how to use Grype, Syft, Cosign, and Cloudsmith to run a nightly scan of your SBOMs and will quarantine images in your Cloudsmith artifact repository for vulnerabilities higher than critical.
  
• Automatic fixes to the deployed artifact. The ideal scenario is to update the vulnerable artifact automatically wherever it is deployed. To do this, you need to:
• Know where your artifacts are deployed.
• What versions are deployed, and
• You need to have a new artifact that fixes the issue.

Deployment information can be determined using deployment and monitoring tools.

Conclusion

When a major new vulnerability is discovered, you can use an SBOM to determine if and where you are vulnerable rather than manually searching and analyzing all your products.

SBOM generation and analysis is not enough to secure your software, but it can be an essential part of your organization's defense.

Cloudsmith is committed to integrating with SBOMs tooling like Cosign and developing features, like package quarantine, for remediation workflows.

Package Quarantine

Package quarantine allows you to temporarily block any downloads of a package until you release the package from quarantine. This is useful in any case where you wish to remove the ability to access a package that is present in your Cloudsmith repository, for example in a case where a security vulne…

Cloudsmith Help

The tooling around a complete workflow is not here for all ecosystems but don’t let perfect be the enemy of the good, ask your suppliers for SBOMs and add SBOM tooling to your workflow to make our software more secure.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet