How to Analyze an SBOM

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 perform SBOM vulnerability analysis 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 which components have a vulnerability enables a complete SBOM analysis to identify risks in your software supply chain. Continuously scanning SBOMs with an SBOM vulnerability scanner is an efficient way to check for new vulnerabilities in released software.

Before diving into SBOM analysis tools, let’s define the key standards around vulnerabilities:

• 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 include technical details or risk ratings — that’s where CVSS and other tools used in SBOM analysis tools come in.

Scoring Systems

The Common Vulnerability Scoring System (CVSS), managed by First.org, rates vulnerabilities on a scale from 1 (low) to 10 (critical). Log4Shell scored a perfect 10 due to its impact and exploitability.

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. While CVSS measures severity, EPSS measures actual risk – useful for prioritizing threats during SBOM vulnerability analysis.

Data Sources for Vulnerabilities

To connect SBOM component to a vulnerability, your SBOM scanner needs a data source. 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.

Popular 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
  

These databases are crucial to accurate SBOM analysis and are integrated into many modern SBOM vulnerability scanners.

How to communicate that I am not vulnerable…VEX

Not every vulnerability makes your product attackable. A study by ShiftLeft, suggests that only 3% of OSS vulnerabilities are attackable.

Reasons why you may not be vulnerable:

• 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.

Dependency-Track was the only tool to meet all these steps, making it a powerful SBOM Analysis Tool. Other tools can still cover much of the process.

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.

It requires security knowledge to deploy, but it's a leading option for in-depth SBOM Vulnerability Analysis.

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 an SBOM generator.

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 SBOM vulnerability, 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.

SBOM Vulnerability remediation

Once you’ve used an SBOM vulnerability scanner and confirmed issues, remediation is the next step. We need a remediation workflow for your published artifact that fixes or neutralizes detected weaknesses.

Remediation steps:

• 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 new vulnerability like Log4Shell appears, you don’t want to scramble. Instead, with a strong SBOM Analysis workflow and tools like Grype, Cosign, and Cloudsmith’s SBOM vulnerability scanner, you can quickly identify and remediate threats.

SBOM generation and analysis are critical components of modern software security. Cloudsmith is committed to supporting these workflows and providing powerful tools like package quarantine to improve vulnerability management.

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 may still be evolving, but don’t let perfect be the enemy of good. Start small — request SBOMs from suppliers and integrate SBOM scanners and SBOM Analysis Tools into your development workflow today.

Frequently Asked Questions (FAQs)

1. Why is an SBOM scanner important?
   An SBOM scanner helps detect known vulnerabilities in software packages to improve supply chain security and compliance.
   
2. How does SBOM help with vulnerability management?
   SBOMs provide a clear view of software components, enabling fast detection and remediation of vulnerabilities with scanners.
   
3. How often should I run SBOM vulnerability scans?
   Run SBOM vulnerability scans regularly—daily or with every software release—for optimal protection.
   
4. What formats do SBOM Analysis Tools support?
   Most SBOM Analysis Tools support SPDX and CycloneDX formats for scanning and vulnerability detection.
   
5. Can Cloudsmith quarantine vulnerable packages?
   Yes, Cloudsmith can quarantine packages identified by SBOM vulnerability scanners to block unsafe deployments.
   

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