What is the difference between an SBOM and runtime evidence when managing container risk under the Cyber Resilience Act?

Why This Matters for Security Teams

Under the cyber resilience Act, the difference between an SBOM and runtime evidence is not academic. An SBOM gives a declared inventory of components, while runtime evidence shows the binaries, libraries, and processes that actually execute in a container. For regulated products, that gap determines whether a vulnerability is real exposure or dormant baggage. Security teams that treat the SBOM as proof of runtime risk often over-prioritise noise, miss active attack paths, or struggle to justify remediation decisions during assurance reviews.

The practical value is clearer when container images are built from layered base images, package managers, and application bundles. A component can exist in the image without ever being loaded in production, and a process can appear at runtime even when it is absent from a stale inventory. That is why current guidance suggests combining declared software composition with observed execution data, rather than choosing one as a substitute for the other. The EU Cyber Resilience Act raises the stakes by pushing manufacturers toward traceable vulnerability handling and evidence-backed product security claims.

In practice, many security teams encounter the SBOM and runtime gap only after a shipped container has already been assessed as more exposed, or less exposed, than it really was.

How It Works in Practice

An SBOM is best treated as the declared bill of materials for a build artifact. It helps answer what was introduced during build, where dependencies originated, and which known vulnerabilities might be inherited. Runtime evidence answers a different question: what code paths, packages, and processes were actually active in the deployed environment. In container risk management, the two views work together because modern images are often generic, reusable, and partially unused at execution time.

For a CRA-aligned workflow, teams typically start with build-time software transparency, then add runtime telemetry from Kubernetes, container runtime security tools, or host sensors. The objective is to correlate declared components with observed execution so that security teams can distinguish dormant libraries from in-use attack surface. This supports better triage for patching, compensating controls, and exceptions where a vulnerability is present but not reachable in the current workload.

• Use the SBOM to establish product composition and supplier dependency visibility.
• Use runtime evidence to confirm which components are loaded, executed, or exposed to attacker-controlled input.
• Prioritise vulnerabilities that are both present and reachable, not merely listed.
• Preserve evidence for audit, incident response, and product assurance under regulated release processes.

For broader control mapping, the NIST Cybersecurity Framework 2.0 helps organisations connect asset visibility, monitoring, and response into one operating model. Where container estates are heavily automated, runtime evidence also supports faster validation of whether a finding is exploitable in the deployed image rather than just theoretically present in the package graph. These controls tend to break down when images are mutable, runtime telemetry is incomplete, or sidecar and init-container activity is not captured because the evidence no longer reflects the workload that was actually delivered.

Common Variations and Edge Cases

Tighter evidence collection often increases operational overhead, requiring organisations to balance assurance value against telemetry cost, storage, and release friction. That tradeoff is especially visible in high-churn container environments where images are rebuilt often and workloads scale elastically.

One common edge case is a vulnerability in a package that exists in the SBOM but is never executed in the deployed service. Best practice is evolving here: some teams treat that as lower priority, while others still require remediation if the component remains reachable through the image and could be activated in a future change. Another case is short-lived jobs, init containers, and debug shells, where runtime evidence can show transient execution that never appears in a static manifest.

There is also an identity and supply-chain angle. If container images, scanners, or policy engines are driven by autonomous agents or AI-assisted workflows, the provenance of the evidence matters as much as the evidence itself. Agentic tooling can accelerate analysis, but it can also introduce misclassification if it reasons over incomplete telemetry. In that sense, the concern is not just what is in the image, but who or what asserted that it was safe. For resilience and assurance, teams should retain chain-of-custody for both the SBOM and runtime observations, then reconcile differences before making compliance claims.

For threat context, the CISA cyber threat advisories are useful when validating whether an exposed component has known exploitation in the wild, but they do not replace local runtime proof.

Related resources from NHI Mgmt Group

• What is the difference between the UK Cybersecurity and Resilience Bill and the EU Cyber Resilience Act?
• What is the difference between prohibited AI practices and high-risk AI systems under the EU AI Act?
• What is the difference between shift left and runtime enforcement for container security?
• What is the difference between static image security and runtime container security?