Software Bill of Materials workflows and container vulnerability scanning are complementary programs that most organizations run separately. The SBOM team generates SBOMs for compliance. The scanning team runs Trivy in the CI pipeline. The two programs produce data about the same containers that lives in separate systems, is maintained by different teams, and is never combined.
The coverage gaps this creates are real. Vulnerability scanners find CVEs in packages not listed in the SBOM (because the SBOM generation tool missed a dependency). The SBOM lists packages that the scanner did not evaluate (because the scanner’s ecosystem coverage is incomplete). Neither team has a complete picture of the container’s software composition and vulnerability state.
The SBOM-Scanner Gap
The gap between SBOM data and scanner data has several sources:
Different enumeration methods: SBOM generators typically enumerate packages by reading package manager metadata (dpkg, rpm, npm, pip). Vulnerability scanners use the same approach for OS packages but may use different methods for language packages or binary-level packages. The differences in enumeration produce different package lists.
Binary detection vs. package metadata: Some software in container images is installed without a package manager — compiled binaries copied into the image, statically-linked executables, or manually extracted archives. SBOM generators that rely only on package manager metadata miss these. Scanners that include file-based binary detection may find them; those that rely only on package manager metadata also miss them.
Layer attribution: Multi-layer images have packages introduced at different layers by different build steps. Attribution of a package to a specific layer (and thus to a specific team’s responsibility) is tracked in the SBOM but not always in scanner output.
CVE applicability: The SBOM records what is present. The scanner records what has CVEs. But the scanner may not assess every package in the SBOM against the CVE database, particularly for package types outside its primary ecosystem coverage.
Building Unified SBOM and Scanner Integration
Step 1: Generate the SBOM from the image
# Generate CycloneDX SBOM from container image
syft myapp:1.2.3 -o cyclonedx-json > sbom.cdx.json
# Generate SPDX SBOM
syft myapp:1.2.3 -o spdx-json > sbom.spdx.json
Step 2: Assess the SBOM against the CVE database (Grype)
# Grype can assess a pre-generated SBOM, not just an image
grype sbom:./sbom.cdx.json -o json > vulnerabilities.json
Assessing the SBOM rather than the image directly means the vulnerability assessment is strictly scoped to what the SBOM says is present. Discrepancies between SBOM and scanner output point to components that are present in the image but not in the SBOM — a signal to investigate the enumeration gap.
Step 3: Cross-reference scanner and SBOM findings
Components found by the scanner that are not in the SBOM may be:
- Binaries not installed via package manager (SBOM gap, needs investigation)
- OS-level packages enumerated by the scanner but not by the SBOM generator (tool coverage gap)
- Mis-detected packages (scanner false positive)
Components in the SBOM that the scanner did not evaluate may be:
- Language packages in ecosystems where the scanner has limited coverage
- Packages where no CVEs exist (expected)
- Packages that the scanner enumerated differently (version string formatting difference)
The Runtime BOM as the Unified Artifact
The software supply chain security model that resolves the SBOM-scanner gap uses the Runtime Bill of Materials (RBOM) as the unified artifact:
The RBOM is generated by runtime profiling rather than static analysis. It captures:
- Which packages are loaded during actual execution (not just installed)
- Which functions are called (not just which packages are present)
- Which external systems the container connects to
The RBOM answers the question that both the SBOM and the scanner are trying to answer: what software is this container actually using? The SBOM answers “what is installed.” The scanner answers “what has CVEs.” The RBOM answers “what executes.”
For security purposes, the RBOM is the most accurate artifact:
- It eliminates the enumeration gap (only what executes is included)
- It provides natural CVE prioritization (CVEs in executing code vs. installed but unused code)
- It produces a consistent dataset for both compliance inventory requirements and vulnerability management
Container security software that generates the RBOM from runtime profiling and enriches it with CVE data combines the functions of SBOM generation and vulnerability scanning into a single workflow:
- Run the container under profiling instrumentation during representative testing
- Generate the RBOM from the profiling data
- Assess the RBOM against the CVE database
- Output: RBOM (for compliance/inventory) + CVE assessment (for security triage) in a unified artifact
The result is a single artifact that satisfies both compliance requirements (component inventory) and security requirements (vulnerability assessment), derived from empirical execution data rather than static analysis.
Frequently Asked Questions
Why should container vulnerability scanners be integrated with SBOM workflows?
SBOM generators and container vulnerability scanners enumerate software using different methods and produce different package lists from the same image. Running them in isolation creates coverage gaps: the scanner may detect CVEs in packages the SBOM did not enumerate (binary-level packages installed without a package manager), while the SBOM may list packages the scanner did not evaluate (language ecosystems outside the scanner’s primary coverage). Integration exposes and closes these gaps rather than leaving them undetected.
What is the difference between an SBOM and a container vulnerability scan?
An SBOM records what software components are installed in a container — the composition inventory. A container vulnerability scan records which of those components have known CVEs — the vulnerability assessment. Neither artifact alone gives a complete security picture: the SBOM without CVE assessment shows what is present but not what is vulnerable, and the scanner output without full component inventory may miss packages outside its enumeration coverage. Integrating both into a unified workflow produces a complete composition-plus-vulnerability record.
What is a Runtime Bill of Materials (RBOM) and how does it differ from a traditional SBOM?
A Runtime Bill of Materials is generated from execution profiling rather than static package metadata analysis. While a traditional SBOM records everything installed in the container, an RBOM records only what actually executes during representative testing — which packages are loaded, which functions are called, which external systems are contacted. For vulnerability management, the RBOM is more precise because CVEs in executing code are exploitable while CVEs in installed-but-never-executed code represent no practical risk.
How do you sign SBOM and vulnerability scanner attestations together for supply chain security?
Using Cosign, you can attach both attestations to the same image digest: sign the SBOM using cosign attest –predicate sbom.spdx.json –type spdxjson and sign the vulnerability assessment using cosign attest –predicate vuln.json –type vuln. Both attestations are verifiable by Kubernetes admission controllers, providing cryptographic proof that the composition inventory and vulnerability assessment were both performed and are tied to that specific image digest — not a different version of the same tag.
Signing SBOM and Scanner Attestations Together
For supply chain security programs that require signed attestations:
# Sign the SBOM attestation
cosign attest –predicate sbom.spdx.json –type spdxjson myapp:1.2.3
# Sign the vulnerability assessment attestation
grype sbom:./sbom.cdx.json -o cosign-vuln > vuln.json
cosign attest –predicate vuln.json –type vuln myapp:1.2.3
These attestations are attached to the image digest and verifiable by admission control. Both the composition (SBOM) and the vulnerability state (scanner) are captured in signed, immutable records that travel with the image.
The integrated SBOM and scanning workflow, with unified attestation, provides the complete picture that separate programs cannot achieve: what the container contains, what vulnerabilities it carries, and cryptographic proof that both assessments were performed and attached to this specific image.