A pure SBOM is a list of components. It satisfies a regulatory ask. It does not, by itself, drive security action. Most SBOMs that organisations generate sit in artifact stores after release, get pointed at by auditors during reviews, and otherwise produce no operational value. The shift that turns an SBOM from compliance artifact into security control is reachability prioritisation: enriching the SBOM with which components are actually exercised by your application's runtime call graph. The enriched SBOM produces a triage queue. The pure SBOM produces a document.
The compliance vs security gap
Regulatory frameworks (EU CRA, EO 14028, FDA medical device guidance) ask for SBOMs because inventory is a precondition for vulnerability response. They do not ask for reachability prioritisation explicitly — but they do ask "how did you decide what to fix and what to defer?" Programs without reachability data have a hard time answering that question.
The security gap: organisations spend the engineering effort to produce SBOMs, then don't gain the security benefit because the SBOM is not actionable.
How reachability changes the SBOM
Three enrichments:
- Each component flagged with reachability status. Reached / not reached / unknown.
- Each known CVE in each component flagged with exploit reachability. Vulnerable function called from request path / not called / sanitized.
- Aggregate metrics computed. Reachable component count, reachable critical CVE count, depth distribution.
The enriched SBOM is queryable: "give me every reachable critical CVE in production services" returns a worklist.
Operational consequences
Three downstream effects:
Triage focus. Engineering hours flow to reachable findings. The unreachable findings are tracked but not actioned.
Audit narrative. "We have 1,200 components, 280 reachable, 18 reachable critical CVEs in active sprint" is a defensible story.
Vendor conversation. Reachability evidence is what makes the conversation with a vendor about an unfixed CVE productive — "your CVE-X is unreachable in our specific deployment, here's the evidence."
What modern programs put in the SBOM
Five fields beyond the regulatory baseline:
- Component reachability status with timestamp and analyser version.
- CVE-level reachability per known CVE in the component.
- Sanitizer presence on the path to vulnerable functions.
- Service criticality tag (where this component is hosted).
- Composite priority score combining reachability + EPSS + KEV + CVSS.
The fields are not in the standard CycloneDX or SPDX schemas; they go in extension fields or vendor-specific properties.
How Safeguard Helps
Safeguard generates reachability-enriched SBOMs as default output. The standard CycloneDX/SPDX fields are populated; the extensions carry reachability classification, sanitizer state, and composite priority. For programs whose SBOMs have been generating but not driving action, this is the architectural change that makes the SBOM operational.