Use SBOMs to understand what was included in the image, then use runtime profiles to see what actually executes. Together they support better remediation, exception handling, and compliance reporting than either evidence source can provide on its own.
What SBOMs tell you, and what runtime profiles add
SBOMs answer the inventory question: what components, packages, and transitive dependencies were present when the image or artifact was built. Runtime profiles answer the behavior question: what code paths, binaries, libraries, and processes actually executed in production. The value comes from combining them, because an included component that never executes is a different remediation priority from a live dependency that is routinely exercised.
That distinction helps teams avoid treating every disclosed component as an urgent fix. A combined view gives you a better basis for deciding whether a finding is dead code, dormant risk, or an active exposure that deserves immediate attention. It also makes it easier to explain why a given exception exists, because you can show both build-time inclusion and runtime evidence.
For containerized systems, the most useful mindset is to treat the SBOM as the declaration of contents and the runtime profile as the declaration of use. NIST’s container guidance emphasizes both image composition and runtime behavior as separate security concerns, which is why each source is stronger when used to validate the other. Open source supply chain guidance from OpenSSF is also useful here because SBOM quality and downstream verification only matter when they support a real operational decision.
How to use the two signals together in remediation and exception handling
Use the SBOM to scope blast radius, then use runtime profiles to rank which components matter first. If a library is present in many images but only one service actually loads it, you have a narrower and more actionable fix path than the raw SBOM would suggest. If a package appears in the SBOM but never executes in the observed runtime, you can often defer remediation while still documenting the residual risk and expiry date for the exception.
This pairing is especially useful when teams are deciding whether to patch, replace, or suppress a finding. Runtime evidence can reduce noise, but it should not be treated as a permanent waiver if the artifact may later exercise the code path after a config change, feature flag flip, or traffic shift. The strongest practice is to keep the exception tied to the exact build, image digest, deployment context, and observation window.
In practice, the best remediation workflow is to first confirm whether the vulnerable component is reachable from the running workload, then check whether it is actually invoked. When the SBOM and runtime profile disagree, investigate the gap rather than choosing one source as “more true.” That mismatch can indicate dead code, incomplete coverage, unexpected plugin loading, or a visibility problem in your telemetry.
Why the combined view matters for compliance and operational reporting
SBOMs give auditors and internal stakeholders a static supply-chain record, while runtime profiles provide evidence that the deployed system behaves as expected. Together they support a more credible report than either source alone, because they show both what was shipped and what was exercised. That matters for policy enforcement, exception review, and proving that a control is not just documented but observed.
The combined model is also better suited to change management. A product team can tell security whether a dependency is still included, whether it is live in production, and whether the current deployment set matches the approved baseline. For compliance reporting, that lets you separate inventory completeness from operational exposure, which is usually the distinction decision-makers need.
Runtime-aware reporting can also improve trust in software composition data. If the SBOM says a package is present but telemetry never shows it loading, the security team can prioritise validation of the inventory pipeline or the deployment path rather than immediately escalating the dependency itself. If the package is both present and active, the case for remediation becomes materially stronger.
Risk and Threat Considerations
The main risk is false confidence from a single view. An SBOM can overstate practical exposure if it lists dormant components, while a runtime profile can understate exposure if it only captures a narrow window, misses rare code paths, or fails to observe a production variant. Attackers benefit when defenders assume one signal fully describes the workload.
Failure mechanism: A component is declared safe because it is not seen at runtime, but a later configuration change, plugin load, new request pattern, or alternate deployment path activates it. The reverse failure is equally common: a component looks important in the SBOM, but it never executes in the observed environment, so teams spend remediation effort on the wrong priority.
Impact: The result is mis-scoped remediation, weaker exception decisions, and reporting that is either too alarmist or too permissive. In the worst case, an exploitable dependency remains live because it was hidden by incomplete runtime visibility, or teams burn scarce patching capacity on components that do not affect the actual running surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | SBOM plus runtime evidence helps prioritize and validate remediation of component flaws. |
| CM-8 — System Component Inventory | SBOMs support component inventory, while runtime profiles validate what is actually in use. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Runtime profiles provide operational evidence that strengthens reporting and review decisions. | |
| Recommendation — Prioritize fixes for components shown as both present and executed. Maintain an accurate component inventory and reconcile it with observed runtime behavior. Correlate runtime evidence with inventory data to support audit and reporting decisions. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Comparing declared components to observed runtime use supports controlled software configuration. |
| Recommendation — Verify deployed software against approved component baselines and runtime behavior. | ||
Practitioner Guidance
What to verify: Confirm that your runtime profile covers the same image digest, deployment tier, and time window as the SBOM you are comparing against. If those scopes differ, treat the comparison as directional, not authoritative.
Decision rule: If a component is present in the SBOM and observed at runtime, treat it as active exposure; if it is present but unobserved, require a clear justification before assigning it low priority.
What good looks like: Teams can trace a finding from artifact inventory to execution evidence to the final remediation decision, with exceptions explicitly bounded by version, environment, and expiry date.
Practitioner takeaway: Use SBOMs to enumerate potential exposure and runtime profiles to prove actual use, then let the combination drive prioritization instead of letting either source become a false source of certainty.
Related resources from NHI Mgmt Group
- How should security teams use SCIM and SAML together in IAM programmes?
- How should security teams use audits and penetration tests together?
- How should security teams use runtime blocking to reduce application exploit risk?
- How should security teams handle identity verification when attackers can use generative AI to spoof face, voice, and documents together?