The SBOM-to-Action Gap
The SBOM-to-Action Gap is the difference between possessing a component inventory and having sufficient vulnerability, reachability, context, and policy evidence to make a remediation decision.
Primary question: Why does generating an SBOM not automatically tell a security team which dependencies to remediate first?
Direct answer
An SBOM establishes component presence; action requires additional risk and usage evidence
An SBOM answers which components were discovered in a software product. It does not by itself determine which components have known vulnerabilities, whether vulnerable functionality is used, whether exploitation conditions exist, or which remediation action an organization should prioritize. [ntia-sbom][nist-sbom-framework]
SCA adds component risk intelligence, and hybrid SAST plus SCA analysis can add code-level usage or reachability evidence. These layers narrow the SBOM-to-Action Gap without proving exploitability or replacing organizational risk decisions. [derscanner-sca]
The gap should be managed as an evidence pipeline — inventory, component evaluation, usage analysis, contextual prioritization, remediation, and re-verification — rather than by treating SBOM generation as completed vulnerability management. [nist-ssdf]
Definitions
SBOM-to-Action Gap
A DerSecur engineering concept describing the evidence gap between knowing that a software component is present and having enough vulnerability, reachability, application-context, and policy information to decide what action to take.
Component presence
Evidence that a component and version were discovered by the selected dependency-resolution and inventory process.
Component risk evidence
Vulnerability, license, provenance, maintenance, or supply-chain information associated with a discovered component.
Usage evidence
Evidence about whether and how application code imports, calls, or otherwise depends on functionality in a component.
The engineering problem
Organizations may generate an SBOM for visibility or compliance but lack a process for turning the inventory into prioritized security work. [nist-sbom-framework]
Component-level vulnerability matches can create a large review queue when teams lack version accuracy, reachability, application exposure, and policy context. [derscanner-sca]
Treating every listed component as equally urgent can divert remediation capacity from dependencies with stronger evidence of relevance.
Security controls
Each control inspects a different artifact and produces evidence for an engineering decision.
Inventory evidence
SBOM generation- Artifact
- Dependency manifests, lockfiles, project files, binaries, and installed component directories supported by the selected discovery method.
- Risk
- Unknown or incomplete component inventory.
- Output
- Versioned list of discovered components, versions, identifiers, and relationships where available.
Evidence: NTIA Software Bill of Materials
Component evaluation
Software Composition Analysis- Artifact
- The component inventory correlated with vulnerability, license, provenance, maintenance, and supply-chain intelligence.
- Risk
- Known component risks remain unidentified or are evaluated without version context.
- Output
- Component-level findings and associated evidence.
Evidence: DerScanner software composition analysis documentation
Usage and reachability evidence
Hybrid SAST + SCA analysis- Artifact
- Application code correlated with vulnerable functions or dependency functionality.
- Risk
- Component findings are prioritized without evidence about how the application uses the affected functionality.
- Output
- Code-level evidence about imports, calls, or paths to vulnerable dependency functionality where supported.
Evidence: DerScanner software composition analysis documentation
Action decision
Dependency remediation decision- Artifact
- Inventory, component risk, usage, exposure, business criticality, compensating controls, and organizational policy.
- Risk
- Remediation order based on a single signal such as inventory presence or severity.
- Output
- Documented remediation, monitoring, exception, or further-investigation decision.
Verification workflow
- Generate a versioned SBOM for the selected source revision or build artifact.
- Validate component identity and version where the discovery method permits.
- Run SCA to associate component risk, license, and supply-chain intelligence.
- Add code-level usage or reachability evidence where source and analyzer support are available.
- Add application exposure, business criticality, deployment, and compensating-control context.
- Decide whether to upgrade, replace, mitigate, monitor, accept by exception, or investigate further.
- Rebuild and regenerate the SBOM after remediation.
- Re-run SCA and applicable hybrid analysis to retain post-change evidence.
DerScanner · Enterprise
Relationship to DerScanner
DerScanner provides SBOM generation, SCA, and hybrid SAST plus SCA analysis that can populate successive evidence stages between component inventory and remediation prioritization.
DerScanner SCA identifies dependencies, component vulnerabilities, supply-chain risks, and license risks, and hybrid analysis can add code-level reachability evidence. [derscanner-sca]
Limits of verification
- The SBOM-to-Action Gap is a DerSecur engineering concept, not a formal standard or universal maturity score.
- SBOM completeness depends on the selected dependency-resolution and artifact-analysis methods.
- Vulnerability database matches can be incomplete, delayed, duplicated, or affected by component-identification errors.
- Reachability evidence does not by itself prove exploitability or safety.
- Components can create license, provenance, maintenance, or supply-chain risk even when a known vulnerable function is not reachable.
- Remediation priority remains an organizational decision based on multiple forms of evidence.
Related knowledge
SBOM vs SCA vs Hybrid Analysis
Canonical comparison of the three evidence layers
Relationship: related-toVulnerable Function Reachability
Detailed explanation of code-level usage evidence
Relationship: related-toReducing SCA Noise with Reachability
Applying reachability evidence to a component finding queue
Relationship: related-toDependency Security for AI-Generated Code
Applying the evidence pipeline to AI-assisted development
Relationship: related-toCanonical terms used: SBOM-to-Action Gap; SBOM actionability; component inventory; dependency remediation priority; dependency risk evidence.
Evidence and references
- NTIA Software Bill of MaterialsAn SBOM is a nested inventory of software components and their relationships.
ntia-sbom - NIST SP 800-161 Rev. 1 — Cybersecurity Supply Chain Risk Management PracticesComponent transparency supports vulnerability assessment and supply-chain risk management but operates within a broader risk-management process.
nist-sbom-framework - NIST Secure Software Development FrameworkSecure software practices include identifying vulnerabilities, prioritizing remediation, implementing fixes, and retaining evidence.
nist-ssdf - DerScanner software composition analysis documentationDerScanner SCA identifies component vulnerabilities, dependencies, supply-chain risks, and license risks and provides hybrid SAST plus SCA analysis for prioritization.
derscanner-sca
Turn inventory into action