SBOM Scanning: How to Detect Vulnerabilities in Your Software Components

SBOM scanning is the process of analyzing a Software Bill of Materials to identify known vulnerabilities, license issues, and other risks in the components listed within it. Rather than re-analyzing source code or container images for each new vulnerability disclosure, SBOM scanning matches the component inventory already documented in your SBOM against vulnerability databases. This makes it possible to continuously monitor your entire software portfolio for newly disclosed threats without rescanning every artifact.

How SBOM Scanning Works

The SBOM scanning workflow has three stages:

1. Component Identification

The scanner reads the SBOM and extracts component identifiers — primarily Package URLs (purls) and CPEs — along with version information. These identifiers are the keys used to look up vulnerability data.

A purl like pkg:npm/[email protected] tells the scanner exactly which package (lodash), from which registry (npm), at which version (4.17.20) to check. The more precise your SBOM’s identifiers, the more accurate the scan results.

2. Database Matching

The scanner queries one or more vulnerability databases to find known CVEs affecting the identified components. Major databases include:

• National Vulnerability Database (NVD) — The U.S. government’s comprehensive CVE database with CVSS severity scores
• OSV (Open Source Vulnerabilities) — Google’s database focused on open source package vulnerabilities, with ecosystem-specific advisory data
• GitHub Advisory Database — Community-curated advisories with package-manager-specific versioning
• CISA KEV Catalog — The list of vulnerabilities with confirmed active exploitation

3. Result Reporting

The scanner produces a report listing each vulnerability found, typically including:

• The affected component and version
• The CVE identifier
• The CVSS severity score
• Whether the vulnerability is listed in the CISA KEV catalog
• Fix availability (which version resolves the vulnerability)
• Advisory details and references

SBOM Scanning Tools

Grype

Grype is an open source vulnerability scanner from Anchore that accepts SBOMs as direct input. It is designed to work with SBOMs generated by Syft but supports any CycloneDX or SPDX SBOM.

# Scan an SBOM file
grype sbom:./my-sbom.cdx.json

# Scan an SBOM with specific output format
grype sbom:./my-sbom.spdx.json -o table

Grype matches against multiple vulnerability databases including the NVD, OSV, and ecosystem-specific advisories. It runs as a CLI tool, making it straightforward to integrate into CI/CD pipelines.

OWASP Dependency-Track

OWASP Dependency-Track is a continuous SBOM analysis platform. Unlike CLI scanners that run once, Dependency-Track ingests SBOMs into a persistent database and continuously re-evaluates them as new vulnerabilities are published.

Key capabilities:

• Ingests SBOMs in CycloneDX and SPDX formats via API or web upload
• Monitors against NVD, OSV, GitHub Advisories, and other sources
• Provides a dashboard showing risk across your entire portfolio
• Sends notifications when new vulnerabilities affect your components
• Supports policy management for automated risk evaluation

Dependency-Track is particularly valuable for SBOM management at scale — it maintains a centralized view of all your software components and their vulnerability status.

OSV-Scanner

OSV-Scanner from Google uses the OSV database and supports SBOM input. It focuses on open source package vulnerabilities with ecosystem-specific version matching.

# Scan an SBOM
osv-scanner scan source -S my-sbom.cdx.json

Trivy

Trivy can scan SBOMs for vulnerabilities in addition to its source directory and container image scanning capabilities.

# Scan an SBOM
trivy sbom my-sbom.cdx.json

sbomify

sbomify integrates vulnerability monitoring directly into its SBOM management platform. When you upload SBOMs to sbomify, they are automatically scanned against Google OSV for known vulnerabilities. For organizations needing deeper analysis, sbomify also integrates with OWASP Dependency-Track. This means generation, storage, scanning, and distribution happen in a single workflow rather than requiring separate tools.

For a broader tool comparison, see our SBOM generation tools guide and resources page.

Setting Up Continuous Monitoring

Point-in-time scanning catches vulnerabilities known at scan time but misses those disclosed afterward. Continuous monitoring solves this by repeatedly matching your SBOMs against updated vulnerability databases.

The Workflow

1. Generate SBOMs in your CI/CD pipeline with every build using tools from our SBOM generation guides
2. Ingest SBOMs into a monitoring platform (sbomify, OWASP Dependency-Track, or equivalent)
3. Configure data sources — connect the platform to NVD, OSV, KEV, and ecosystem-specific advisory feeds
4. Set up notifications — alert the appropriate team when new vulnerabilities are found in their components
5. Define policies — establish severity thresholds and SLAs for remediation

Why Continuous Monitoring Matters

New CVEs are published daily. A component that was clean when you deployed it may have a critical vulnerability disclosed a week later. Without continuous monitoring, you will not know until the next scheduled scan — which may be too late.

The CISA KEV catalog is updated multiple times per week with vulnerabilities that are actively being exploited. Continuous monitoring against KEV ensures you are alerted immediately when a component in your portfolio is under active attack.

Acting on Scan Results

Scanning without action is overhead. An effective vulnerability response process turns scan results into remediation.

Prioritization

Not all vulnerabilities require immediate action. Prioritize based on:

1. KEV status. If the vulnerability is in the CISA KEV catalog, it is being actively exploited — treat it as urgent regardless of CVSS score.
2. CVSS severity. Critical (9.0-10.0) and High (7.0-8.9) vulnerabilities warrant faster response. See our CVSS guide for scoring details.
3. Exploitability. Is there a public exploit? Is the vulnerability exploitable remotely without authentication?
4. Deployment context. Is the affected component in an internet-facing application or an internal tool? Is the vulnerable code path actually reachable?
5. Fix availability. If a patched version exists, updating is straightforward. If no fix is available, you need a workaround or compensating control.

Remediation

The most common remediation is updating the vulnerable component to a fixed version. For transitive dependencies, this may require updating the direct dependency that pulls it in — see our dependency guide for details on dependency trees.

When an update is not immediately possible:

• Apply vendor-recommended mitigations or workarounds
• Implement compensating controls (WAF rules, network restrictions)
• Document the accepted risk with a timeline for permanent remediation

VEX (Vulnerability Exploitability eXchange)

VEX is a standardized way to communicate whether a vulnerability in a component actually affects a specific product. A VEX statement might declare that CVE-2024-XXXX in lodash “does not affect” your application because the vulnerable function is never called.

VEX reduces false positives by distinguishing between “this component has a known CVE” and “this CVE actually impacts our product.” Both CycloneDX and OpenVEX support VEX documents that can be consumed by scanning tools to suppress known non-exploitable findings.

Best Practices

1. Scan SBOMs, not just source code. SBOM scanning catches vulnerabilities in deployed components, including OS-level packages in containers that do not appear in your source repository.

2. Monitor continuously. Do not rely on scan-at-build-time alone. Use a platform like sbomify or OWASP Dependency-Track for ongoing monitoring against updated vulnerability feeds.

3. Prioritize with KEV. Use the CISA KEV catalog as a top-priority signal. KEV-listed vulnerabilities are confirmed to be actively exploited and should be remediated first.

4. Define SLAs. Establish clear timelines for remediation based on severity and exploitability. Example: KEV-listed critical vulnerabilities within 48 hours; critical non-KEV within 2 weeks; high severity within 30 days.

5. Use VEX to reduce noise. When a vulnerability does not affect your product (because the vulnerable code path is not reachable), document this with a VEX statement rather than suppressing the alert entirely.

6. Automate the pipeline. Generate SBOMs automatically in CI/CD, ingest them into monitoring automatically, and route alerts to the right teams automatically. Manual steps create gaps.

Frequently Asked Questions

What is SBOM scanning?

SBOM scanning is the process of analyzing a Software Bill of Materials to identify known vulnerabilities, license issues, and other risks in the components it documents. Scanners match SBOM component identifiers (purls, CPEs) against vulnerability databases like the NVD and OSV to find known CVEs. This enables continuous vulnerability monitoring without repeatedly scanning source code or container images.

What tools scan SBOMs for vulnerabilities?

Leading SBOM scanning tools include sbomify (integrated platform with built-in OSV and Dependency-Track scanning), Grype (CLI scanner from Anchore), OWASP Dependency-Track (standalone monitoring platform), OSV-Scanner (Google’s open source scanner), and Trivy (comprehensive security scanner from Aqua Security). Grype and Trivy are best for CI/CD pipeline integration; sbomify and Dependency-Track are best for ongoing portfolio monitoring.

How often should I scan my SBOMs?

SBOMs should be scanned continuously, not just at build time. New vulnerabilities are disclosed daily, and a component that was clean at build time may have a critical CVE disclosed afterward. Use a continuous monitoring platform that automatically re-evaluates your SBOMs as vulnerability databases are updated.

What is the difference between SBOM scanning and SCA?

Software Composition Analysis (SCA) scans source code, dependency files, or binaries to identify components and their vulnerabilities. SBOM scanning takes an already-generated SBOM as input and matches its components against vulnerability databases. SCA produces the inventory; SBOM scanning monitors it over time. They are complementary — SCA for discovery, SBOM scanning for continuous monitoring.

What is VEX?

VEX (Vulnerability Exploitability eXchange) is a standardized format for communicating whether a known vulnerability in a component actually affects a specific product. A VEX statement can declare that a CVE “does not affect,” “is under investigation,” or “is affected” in your product. VEX reduces false positives from SBOM scanning by distinguishing theoretical vulnerability from actual impact.