SBOM analysis is the process of examining a Software Bill of Materials (SBOM) to identify vulnerabilities, license risks, outdated components, and compliance gaps across the software your application depends on.
Generating an SBOM tells you what is in your software. Analyzing it tells you what that inventory means for your security posture, remediation priorities, and regulatory readiness.
The urgency around SBOM analysis is increasing. CISA’s 2025 draft SBOM Minimum Elements update reflects growing expectations for SBOM completeness and usability, while the EU Cyber Resilience Act introduces vulnerability and incident reporting obligations beginning September 11, 2026, with broader product security obligations applying from December 11, 2027.
For DevSecOps teams, especially those operating in regulated or government-adjacent markets, SBOM analysis is becoming a practical requirement for managing software supply chain risk.
SBOM generation and analysis are often conflated, and that conflation is where most SBOM programs stall.
Generation produces the inventory: a structured list of components, versions, licenses, and dependency relationships. Analysis is what you do with that inventory to extract security and compliance intelligence.
An SBOM that sits in a repository and gets pulled out for audit requests isn’t functioning as a security tool.
Effective SBOM analysis examines four things that generation alone can’t answer:
That last category is where a significant proportion of real-world supply chain vulnerabilities hide.
No. SBOM analysis and software composition analysis (SCA) overlap, but they answer different questions and produce different outputs.
SCA is the active scanning process. It reads your codebase, lockfiles, and binaries, identifies open-source components, and matches them against vulnerability databases in real time. SBOM analysis is what happens to a generated SBOM after the fact: parsing the inventory, cross-referencing components against CVE feeds, evaluating license obligations, and applying risk context. SCA tools typically generate the SBOM as a byproduct. SBOM analysis tools consume SBOMs from anywhere, including those produced by suppliers and third parties.
The practical difference matters when a customer or regulator hands your team an SBOM from a vendor and asks for a risk assessment. SCA can’t scan code you don’t have. SBOM analysis can read the inventory, query vulnerability databases for every listed component, and produce a defensible risk report without ever touching the source.
Mature programs use both. SCA monitors what your team builds. SBOM analysis covers everything you ship, consume from vendors, or distribute downstream.
SBOM analysis covers more ground than a simple CVE scan. The four areas that matter most for DevSecOps teams are:
Every component in your SBOM has a version. Every version has a known vulnerability profile that can be cross-referenced against the NIST National Vulnerability Database, the OSV (Open Source Vulnerabilities) database, GitHub Security Advisories, and ecosystem-specific feeds for npm, PyPI, Maven, and similar registries. Relying on a single source produces gaps. NVD is widely used and authoritative, but ecosystem-specific advisories may provide package-level context earlier or in more actionable detail. OSV and vendor-curated feeds often publish ecosystem-specific advisories before NVD enrichment, such as CPE mapping, is available.
Effective SBOM analysis automates cross-referencing continuously, not just at the point of generation, so new CVEs that affect existing components surface as they’re published rather than at the next scheduled scan.
SBOM tools that update CVE matching in real time are what separate active vulnerability management from point-in-time snapshots.
Open-source components come with license obligations. GPL, LGPL, Apache, MIT, and proprietary licenses all carry different requirements for distribution, modification, and attribution.
A component with a GPL license in a commercial product can create legal exposure that has nothing to do with security but everything to do with how your product can be distributed. SBOM analysis that includes license mapping surfaces these conflicts before they become legal issues.
For teams working toward SBOM best practices, license governance is as important as vulnerability management.
A component that hasn’t received a security update in a few years isn’t necessarily vulnerable today, but it’s a liability in the making.
Unmaintained components don’t get patched when new vulnerabilities are discovered. An SBOM analysis that tracks component activity and maintenance status gives teams a warning of components that need to be replaced before they become a security gap.
Your direct dependencies are the libraries you explicitly import. Your transitive dependencies are everything those libraries depend on.
The attack surface that transitive dependencies represent is often significantly larger than what’s visible in a direct dependency scan.
The Log4Shell vulnerability, one of the most severe supply chain incidents in recent memory, affected applications whose developers had no idea Log4j was in their stack. Transitive dependency analysis is what makes SBOM analysis comprehensive rather than superficial.
A defensible SBOM analysis follows the same five-stage process, whether the inventory comes from your own build pipeline or a vendor delivering a CycloneDX file as part of procurement:
The first four stages run on every fresh SBOM. The fifth runs forever. Most of the security value comes from how well step five is automated, because vulnerabilities don’t respect release schedules.
A one-time SBOM analysis doesn’t provide ongoing protection as software dependencies change with every build. Integrating SBOM automation into the CI/CD pipeline at three key points gives you continuous visibility rather than periodic snapshots.
That three-point integration model ensures your SBOM reflects the actual state of what’s being deployed, not what was analyzed at the start of the sprint. The discrepancy that arises when deployed software diverges from its declared SBOM is called SBOM drift, and post-containerization and pre-deployment scans exist specifically to catch it before it becomes an incident.
Format choice affects what analysis is possible. The two dominant SBOM standards, CycloneDX and SPDX, have distinct strengths that matter during analysis.
CycloneDX was designed for security workflows and supports native VEX (Vulnerability Exploitability eXchange) data, which is critical for analysis. A VEX document goes beyond listing vulnerabilities by also recording whether each vulnerability is actually exploitable in the specific context of your application.
That distinction matters enormously for prioritization: a CVE with a CVSS score of 9.8 that can’t be reached by attacker-controlled input is a lower priority than a CVE with a score of 6.5 that sits directly in an exposed code path.
SPDX is better suited to license compliance workflows, with broader tooling adoption for legal and procurement use cases.
Most mature SBOM programs generate both formats, CycloneDX for security analysis and VEX workflows, and SPDX for license audits and supplier assessments.
CVSS scores measure theoretical severity in isolation. They don’t account for whether a vulnerability is reachable in your application, whether an exploit exists in the wild, or whether compensating controls already reduce the practical risk.
Relying on CVSS alone produces prioritization queues where teams spend time patching high-scoring vulnerabilities that pose no realistic threat, while genuinely exploitable findings wait.
Risk-based SBOM analysis provides context that CVSS alone can’t.
The CISA Known Exploited Vulnerabilities catalog identifies CVEs with confirmed exploitation in the wild, making it a practical filter for separating theoretical risk from active threat. EPSS (Exploit Prediction Scoring System) adds a probability dimension, estimating the likelihood that a given CVE will be exploited in the next 30 days.
Together, these signals let teams build remediation queues organized around actual risk rather than raw severity scores.
Reachability analysis adds another layer of precision. Where VEX records human judgment about exploitability, reachability analysis builds a call graph that traces whether vulnerable functions are actually invoked anywhere in your code. Some industry analyses suggest that reachability filtering can significantly reduce SCA noise, often by deprioritizing a large share of findings that are unreachable in the application context. Combining VEX, reachability data, KEV, and EPSS turns SBOM analysis from a noise generator into a remediation queue short enough to act on.
The regulatory landscape for SBOM analysis has shifted substantially and continues to tighten. Three frameworks are driving the most immediate compliance requirements, and for most DevSecOps teams, at least one of them already applies:
| Framework | Who it affects | Key SBOM requirement | Timeline |
| CISA 2025 SBOM Minimum Elements | Organizations selling software to US federal agencies | SBOM completeness and analysis capability as part of procurement evaluation | In effect 2025 |
| EU Cyber Resilience Act (CRA) | Manufacturers of connected products sold in European markets | Document all software components, monitor for vulnerabilities, and issue updates when new CVEs are discovered | Reporting obligations from Sept. 11, 2026; main obligations from Dec. 11, 2027 |
| PCI DSS 4.0.1 | Organizations that store, process, or transmit payment card data | Maintain an inventory of bespoke/custom software and third-party components to support vulnerability and patch management | Required as of March 31, 2025 |
| NIST SSDF | Organizations aligning with secure software development guidance, especially federal suppliers | Encourages secure software supply chain practices, including SBOM use for transparency and vulnerability management | Guidance/framework |
The common thread across all three is that SBOM generation alone isn’t enough. SBOM analysis is what generates the evidence trail these frameworks require.
Teams building toward secure SBOM compliance need tooling that produces compliance-ready output as a natural byproduct of the analysis process, rather than as a separate reporting step.
SBOM analysis at scale requires automation that keeps pace with development speed. Manual processes can’t maintain continuous CVE monitoring across hundreds of components and dozens of builds per week.
Kiuwan Insights is built to handle the analysis layer automatically, integrating SBOM generation and continuous monitoring into the CI/CD workflows that DevSecOps teams already run.
Here’s what Kiuwan Insights delivers for SBOM analysis:
For DevSecOps teams navigating tightening regulatory requirements and growing software supply chain risk, SBOM analysis is the function that turns a static inventory into active security intelligence.
Request a Kiuwan trial to see how continuous SBOM analysis integrates with your pipeline.
