Understanding SBOM scanning fundamentals
An SBOM contains an inventory of all software components, libraries, dependencies, versions, licenses, and relationships. There are two primary SBOM formats you will encounter. CycloneDX is security-focused, while SPDX formats focus on compliance and licensing.
SBOM scanning works by using parsers to read SBOM files, extract component identifiers, and query vulnerability databases (OSV for ecosystem-specific advisories, NVD for CVE records, and vendor-specific feeds from GitHub, npm, PyPI) to return findings. It is important to understand the difference between SBOM generation, which creates the inventory, and SBOM analysis, which analyzes it for risks. Scanning is critical for identifying transitive dependencies, which are vulnerabilities hidden deep in the dependency tree.
Scanners match component versions to known CVEs primarily using package URLs (PURLs) and ecosystem metadata from sources like OSV (Open Source Vulnerabilities), vendor advisories, and NVD. CPE identifiers may supplement matching for OS-level packages. This process can detect licensing violations, outdated dependencies, and supply chain tampering indicators. SCA (Software Composition Analysis) tools integrated with SBOM scanning are vital for maintaining visibility into these hidden risks.
Secure Coding Best Practices [Cheat Sheet]
Gain practical tips and coding examples to write secure code from the start and reduce vulnerabilities.
Why SBOM scanning matters for modern application security
Most applications contain more third-party code than proprietary code, with 96% using open-source components, which creates a large software supply chain attack surface. Modern threats like the SolarWinds attack and Log4j demonstrated that vulnerabilities in dependencies can have catastrophic impact.
Regulatory drivers like the NIST Secure Software Development Framework (SSDF), Executive Order 14028 guidance for federal procurement, and the EU Cyber Resilience Act increasingly drive SBOM adoption. SBOMs are being requested in procurement processes and compliance programs, though specific requirements vary by jurisdiction, product category, and customer base. This aligns with the DevSecOps shift-left philosophy, as catching vulnerabilities before they reach production reduces cost and risk. Scanning solves the challenge of "unknown unknowns" because teams can't secure what they can't see in their software inventory.
Automated SBOM workflows enable rapid incident response when new zero-days emerge by allowing you to quickly identify affected systems. It also provides a compliance benefit by demonstrating due diligence in software supply chain security for audits and certifications. SBOM vulnerability management is essential for maintaining this security posture.
SBOM scanning for compliance and audit evidence:
SBOM scanning supports multiple compliance frameworks:
ISO 27001 (Annex A.8.30, A.15.1): Demonstrates supplier security assessment and software inventory controls
SOC 2 (CC6.1, CC7.1): Provides evidence of vulnerability management and change control processes
PCI DSS 4.0 (Requirement 6.3): Documents secure software development and third-party component tracking
HIPAA Security Rule: Supports risk analysis requirements for software handling PHI
NIST SSDF: Aligns with practices PO.3 (component inventory) and PW.2 (vulnerability management)
Generate audit reports showing: SBOM coverage percentage, time to identify exposure to new CVEs, remediation rates, and policy compliance trends.
The Top 11 Open-Source SBOM tools
This article will start with a quick refresher on SBOMs and then list the top SBOM-generation tools available.
Read moreHow SBOM scanning works in cloud-native environments
The scanning workflow moves from SBOM generation to parsing, vulnerability matching, prioritization, reporting, and remediation. A unified policy engine that spans IDE, CI/CD, registries, cloud, and runtime prevents policy drift and applies consistent security guardrails end-to-end—the same vulnerability threshold that fails a build also blocks deployment and triggers runtime alerts. You can establish integration points in CI/CD pipelines using pre-commit hooks, build-time scanning, pre-deployment gates, and runtime monitoring.
Container image scanning works through layer-by-layer analysis to identify which dependencies come from base images versus application layers. Agentless scanning approaches analyze container images and VM disks through cloud provider APIs and container registries—no software installation inside running containers or VMs required. This method reads filesystem layers and package manifests directly from storage. Scanners handle ephemeral resources by generating SBOMs at build time and scanning deployment artifacts in registries before short-lived containers and serverless functions are deployed. This shift-left approach captures inventory before resources become ephemeral.
Automated SBOM workflows play a key role by triggering scans on every build, blocking deployments with critical findings, and creating tickets for remediation. You can also integrate these results with security platforms by feeding SBOM scan results into SIEM, SOAR, and vulnerability management systems. This is critical for container SBOM scanning and open-source SBOM tools management. An SBOM management platforms can centralize these efforts.
Watch 5-min demo
Learn about the full power of the Wiz cloud security platform. Built to protect your cloud environment from code to runtime.
Watch now
SBOM scanning implementation strategies and use cases
Pre-deployment scanning: You can scan during the build to prevent vulnerable code from reaching production.Use the same policies to fail builds and to quarantine images at admission control—this prevents policy drift where different thresholds apply at different stages.
Integrate scanners into CI/CD pipelines as quality gates.
Configure policies to fail builds based on vulnerability severity or exploitability.
Enable developers to see scan results in pull requests for immediate feedback.
Continuous production scanning: This involves ongoing monitoring of deployed workloads for newly disclosed vulnerabilities.
Schedule regular rescans of production SBOMs to catch emerging threats.
Correlate dynamic SBOM data with runtime behavior to identify actively exploited components.
Trigger alerts when new CVEs affect components running in production.
Incident response use case: You can rapidly assess exposure when zero-day vulnerabilities emerge.
Query all SBOMs across the organization to identify affected systems within minutes.
Prioritize patching based on which systems are externally exposed or handle sensitive data.
Document remediation progress for compliance and stakeholder reporting.
Third-party risk management: Evaluate the security posture of vendor-supplied software.
Request SBOMs from vendors and scan them before procurement decisions. Industry studies show that supply chain attacks affect a majority of organizations, driving increased SBOM adoption in vendor risk management.
Monitor vendor software for unpatched vulnerabilities throughout the contract lifecycle.
Compare vendor SBOM claims against actual scanned inventory to verify accuracy.
Third-party software intake checklist:
Evaluate vendor security posture using these SBOM-based criteria:
SBOM availability: Vendor provides machine-readable SBOM (CycloneDX or SPDX) with each release
SBOM signing: Cryptographically signed SBOMs prove authenticity
VEX support: Vendor publishes VEX documents for non-exploitable findings
Update cadence: Vendor commits to SBOM updates within 48 hours of releases
Vulnerability disclosure: Clear process and SLA for security issues (e.g., 30-day critical patch SLA)
License compliance: SBOM includes complete license metadata for all components
Remediation transparency: Vendor documents which vulnerabilities are fixed in each release
Historical data: Request SBOMs for past 12 months to assess security posture trends
Score vendors on these criteria during procurement and re-evaluate quarterly for existing vendors.
License compliance: Identify open-source licenses that conflict with organizational policies.
Detect GPL, AGPL, or other copyleft licenses that may create legal obligations.
Track license changes in dependencies over time.
Generate compliance reports for legal and procurement teams.
SBOM signing and provenance attestation:
Signed SBOMs prove authenticity and detect tampering. Provenance metadata shows where and how software was built.
Signing mechanisms: Cryptographically sign SBOMs using industry-standard tools and protocols
Provenance standards: Supply chain attestation frameworks document build environment, source repo, and builder identity
Verification workflow: Validate SBOM signatures before scanning to ensure you're analyzing authentic inventory
Policy enforcement: Reject unsigned SBOMs at deployment gates in regulated environments
Container Image Signing
Container image signing is a critical security process for establishing trust. Just as you'd expect a signature to verify the authenticity of a document, image signing does the same for container images—those neat packages that carry your code along with all the necessary parts to run it anywhere.
Read more
Overcoming SBOM scanning challenges in enterprise environments
False positive management: Scanners often flag vulnerabilities that don't apply to how the code is actually used. Graph-based security context and runtime evidence help validate reachability and reduce noise from non-exploitable findings by connecting SBOM data to actual network exposure, data access patterns, and execution evidence.
Reachability analysis: Estimates whether vulnerable code paths are invoked by analyzing call graphs from static analysis or runtime evidence. This reduces noise from non-exploitable findings where vulnerable functions are present but never called.
Contextual filtering: Filters findings based on network exposure, data sensitivity, and privilege levels.
Human review: Establishes exception processes for known false positives.
VEX (Vulnerability Exploitability eXchange) integration:
VEX documents accompany SBOMs to communicate which vulnerabilities don't apply to your specific use case. For example, if your application includes a vulnerable image processing library but never calls the vulnerable function, a VEX statement documents this non-exploitability.
Reduces false positive noise by 40-60% in typical environments
Standardized by CISA and supported in CycloneDX and SPDX formats
Enables vendors to communicate security posture without patching non-exploitable issues
Requires validation—verify VEX claims through reachability analysis
Scale and performance: Large organizations may have thousands of applications and millions of dependencies, with the average app containing 595 components.
Computational cost: Addresses the resource intensity of scanning every component in every SBOM.
Incremental scanning: Uses strategies like only checking changed components.
Distributed infrastructure: Utilizes caching mechanisms and distributed scanning to maintain speed.
SBOM quality and completeness: Validate SBOMs against NTIA minimum elements (author, timestamp, dependency relationships, component identifiers). Incomplete SBOMs may miss critical transitive dependencies or lack license metadata. Different generation tools (Syft, Trivy, SPDX tools) produce varying levels of detail.
Incomplete SBOMs: Highlights the problem of missing critical dependencies.
Tool variance: Explains how different generation tools produce varying levels of detail.
Validation: Discusses the need to validate SBOM accuracy before relying on scan results.
Prioritization complexity: Security teams face alert fatigue from large vulnerability volumes. Industry studies (such as this SBOM analysis) note that applications commonly contain dozens to hundreds of vulnerabilities depending on dependency depth and tech stack.
Beyond CVSS: Explains why severity scores alone are insufficient for prioritization.
Risk-based prioritization: Introduces concepts using exploit availability, asset criticality, and environmental factors.
Threat intelligence: Mentions the role of intelligence in understanding actively exploited vulnerabilities.
How Wiz transforms SBOM scanning with cloud security context
Wiz takes SBOM scanning beyond simple inventory checks by connecting code-level findings to your actual cloud environment. Instead of treating SBOMs as static lists, Wiz Code automatically generates them across your repositories and container images, then analyzes dependencies for vulnerabilities, secrets, misconfigurations, and license risks all in one pass.
What makes this powerful is the Security Graph—it maps how vulnerable components in your SBOM relate to running workloads, data stores, identities, and other cloud resources. You can trace a production issue back to its source code in minutes, and see which vulnerable dependencies are actually deployed versus sitting unused in your codebase.
Wiz Cloud enrichment adds the context that matters most: attack path analysis showing how a vulnerable dependency connects to sensitive data or excessive permissions, prioritization based on real-world exploitability rather than just CVSS scores, and continuous monitoring that automatically rescans as new CVEs emerge. Meanwhile, Wiz Defend uses runtime sensors to validate which components are actually executing and whether vulnerable functions are reachable—eliminating false positives from code that's present but never called.
For teams building containers, WizOS provides hardened base images with near-zero CVEs, so you start with a secure foundation instead of inheriting vulnerabilities from upstream images. The result: SBOM scanning that focuses your team on vulnerabilities that pose actual risk, not just theoretical ones.
Ready to see how context-aware SBOM scanning works in your environment? Get a personalized demo of Wiz's cloud security platform and discover how to cut through vulnerability noise to focus on what actually matters.
Catch code risks before you deploy
Learn how Wiz Code scans IaC, containers, and pipelines to stop misconfigurations and vulnerabilities before they hit your cloud.
