Runtime SBOM

A runtime SBOM is a software bill of materials enriched with runtime evidence about which components, libraries, packages, and code paths are actually loaded or executed by an application.

NIST defines an SBOM (software bill of materials) as a formal record containing the details and supply chain relationships of the components used in building software, since developers typically assemble products from existing open-source and commercial components rather than building everything from scratch. That inventory is essential, but it’s static: it describes what could be present, not what actually runs. A runtime SBOM closes that gap by observing the application in motion and correlating what’s actually loaded and exercised against the static inventory.

Bugcrowd’s take: A static SBOM tells teams what software may be present. A runtime SBOM helps reveal what code is actually used, reachable, and relevant to exploitability. That makes it a bridge between supply-chain inventory and offensive validation.

1. What Is a Runtime SBOM?

Definition: A runtime SBOM takes the standard component inventory a static SBOM or software composition analysis (SCA) tool produces and augments it with dynamic evidence, observed from the running application, about which of those components are actually loaded, called, or exercised in practice.

How it extends a traditional SBOM: A traditional SBOM answers “what’s in this build.” A runtime SBOM answers a follow-up question static tooling can’t: “of everything in this build, what’s actually used when the application runs.” It doesn’t replace the static inventory, it ingests it and adds a layer of behavioral evidence on top.

Why runtime evidence matters: Not every component listed in an SBOM is equally relevant to risk. A vulnerable library that’s present in a container image but never loaded, or a code path that exists but is never reachable in practice, poses a fundamentally different level of risk than a vulnerable component that’s actively running in production. Runtime evidence is what lets teams tell those two situations apart.

2. SBOM Basics

A standard SBOM typically documents:

• Component inventory — the full list of software components, libraries, and packages that make up a build
• Dependencies — the relationships between components, including nested and transitive dependencies
• Versions — the specific version of each component included
• Suppliers — who produced or maintains each component
• Licensing — the license terms governing each component’s use
• Known vulnerabilities — CVEs and other disclosed issues associated with the components and versions in use

3. Static SBOM vs. Runtime SBOM vs. Dynamic SBOM

These terms describe different points in a component’s lifecycle, and it’s worth being precise about each:

• Static — what is included: the full inventory of components present in the source, build artifacts, or shipped image, regardless of whether they’re ever used
• Build-time — what is assembled: the specific set of components pulled together during the build process, including exact versions and transitive dependencies resolved at that moment
• Deployed — what is shipped: the components actually packaged into the artifact or image that gets deployed to an environment
• Runtime — what is executed or loaded: the subset of deployed components that are actually loaded into memory or invoked while the application runs
• Dynamic — what changes during execution: the evolving picture of runtime behavior over time and across environments, since the same deployed artifact can exercise different code paths depending on configuration, input, and usage patterns

4. Why Static SBOMs Are Not Enough

• Unused libraries — a component can be included in a build without ever being loaded or called, contributing to inventory size and scan noise without contributing to real risk
• Dead code — even within a used library, entire functions or modules may never execute in a given deployment
• Transitive dependencies — deep dependency chains often pull in components no one on the team directly chose or is aware of, some of which are never actually exercised
• Environment-specific behavior — the same artifact can behave differently depending on configuration, feature flags, or deployment environment, meaning “static” component presence doesn’t tell you what’s true in a specific running instance
• Reachability uncertainty — a known vulnerability in a listed component doesn’t tell you whether the vulnerable function is ever actually called, which is the difference between a theoretical and a real risk
• Alert fatigue — without a way to separate reachable, actively used components from merely present ones, security and engineering teams end up triaging long lists of findings where most carry little practical risk

5. What Runtime SBOMs Capture

• Loaded packages — which components were actually loaded into a running process, as opposed to merely present in the image
• Called libraries — which library functions were actually invoked during execution
• Runtime dependencies — the dependency relationships that are actually active while the application runs, not just resolved at build time
• Active code paths — which specific code paths within a component were exercised
• Network services — the network-facing services and behaviors an application exhibits while running
• Containers and images — behavioral observation is often collected at the container or OCI image level, correlating what’s in the image with what the running container actually does
• Vulnerability context — whether a component with a known vulnerability was observed in use at runtime, and where that usage occurred, giving a known CVE real behavioral context rather than a bare severity score

6. Runtime SBOM and Reachability

Reachable vulnerabilities are higher priority. A vulnerability in a component that’s confirmed loaded and actively exercised at runtime represents a materially higher-priority risk than the same vulnerability sitting in a component that’s present but never invoked.

Non-executed vulnerable components may still matter, but should be ranked differently. A component that isn’t currently reachable can still become reachable later, through a configuration change, a new feature, or a code path that starts getting exercised, so it shouldn’t be dismissed outright. It should simply be triaged with a different urgency than something confirmed active in production today.

Runtime evidence improves remediation decisions. Knowing not just that a vulnerability exists but where and how the affected component is actually used gives a remediation team a running start: which code path to investigate, whether the exposure is realistic, and how urgently it needs to be patched.

7. Use Cases

• Vulnerability prioritization — ranking the long list of findings a static SBOM or SCA tool surfaces based on which ones are confirmed active at runtime
• Incident response — quickly determining, during an active incident, whether a vulnerable or suspicious component was actually loaded and running in a given environment
• Software supply-chain risk — building a truer picture of an organization’s actual exposure to third-party and open-source risk, beyond what’s merely listed in a manifest
• Container hardening — identifying and removing components that are present in a container image but never used, shrinking the attack surface
• Reducing unused components — feeding runtime evidence back into build and packaging decisions to trim components that add risk without adding function
• Compliance evidence — generating attestations, justifications, and exportable reports (such as VEX and SARIF) that demonstrate not just what’s in a build but how it behaves, supporting frameworks like Executive Order 14028, NIST guidance, and the Secure Software Development Framework (SSDF)
• Exploitability validation — feeding runtime evidence into adversarial testing to help confirm whether a theoretically vulnerable component is genuinely exploitable in context

8. Limitations

Runtime visibility depends on exercised paths. A runtime SBOM can only observe what actually executes during the observation window. Code paths that never run during that window won’t be reflected, even if they’d be exercised under different conditions.

Test coverage matters. The quality of runtime SBOM data is tied to how thoroughly the application has been exercised, whether through real production traffic, realistic test scenarios, or both. Thin coverage produces a thin, potentially misleading runtime picture.

Runtime SBOMs should complement, not replace, static SBOMs and SCA. A runtime SBOM has no way to describe a component that’s present in a build but has literally never been observed running. Static inventory remains the ground truth for what could theoretically be exposed; runtime evidence narrows and prioritizes that ground truth rather than substituting for it.

9. Bugcrowd Perspective

Bugcrowd positions runtime SBOM data as an input to adversarial validation, feeding a single underlying question: is the vulnerable component present, loaded, reachable, and exploitable? Each of those four words describes a distinct, increasingly rigorous level of confidence, and a runtime SBOM is what moves a finding from “present” toward “loaded” and “reachable.”

Savant Runtime (formerly Mayhem Dynamic SBOM) is built by Bugcrowd’s Mayhem team to do exactly this. It deploys an observability service in userland, alongside the container engine running an application, with no kernel modules or code changes required. That service watches containers behave in the real world and builds a historical record of what’s actually loaded and used. It then ingests SBOM and SCA reports from existing tools (supporting formats like SPDX, CycloneDX, and SARIF, and integrations including Anchore, Docker Scout, and Trivy) and annotates each reported finding with runtime evidence: whether the vulnerable component was observed in use, and where. Bugcrowd reports this correlation cuts roughly 80% of the false positives that come from static analysis alone, by pinpointing the issues that only emerge, or only matter, at runtime, while also generating the attestations, VEX, and SARIF exports needed for compliance reporting.

10. FAQs

Is a runtime SBOM required for compliance? Not on its own, but it increasingly supports compliance obligations. Frameworks tied to Executive Order 14028, NIST guidance, and the Secure Software Development Framework (SSDF) require organizations to maintain a detailed SBOM; a runtime SBOM isn’t a separate mandate but a way to generate stronger evidence and justifications (including VEX reports) in support of those existing requirements.

How is a runtime SBOM different from SCA? Software composition analysis (SCA) typically identifies known vulnerabilities in the components listed in a static SBOM, based on what’s present in the code or build. A runtime SBOM adds a behavioral layer on top: it observes the actual running application to determine whether those same components are loaded and exercised in practice, not just present.

Can a runtime SBOM prove exploitability? Not by itself. A runtime SBOM confirms that a component is loaded and reachable, which is a necessary condition for exploitability but not sufficient proof of it. Confirming genuine exploitability typically requires pairing runtime evidence with active validation, such as fuzzing or adversarial testing, that actually attempts to trigger the vulnerable behavior.

Does a runtime SBOM reduce vulnerability noise? Yes, substantially. By distinguishing components that are merely present from those confirmed active at runtime, a runtime SBOM lets teams filter out a large share of theoretical findings and focus triage effort on the smaller set of vulnerabilities with real, observed exposure.

How often should runtime SBOM data be updated? As continuously as the application runs. Because runtime behavior can shift with new deployments, configuration changes, or usage patterns, runtime SBOM observation is most useful as an ongoing, continuous process rather than a periodic snapshot, so the data reflects how the application is behaving now, not how it behaved at some earlier point in time.

Sources:

NIST Computer Security Resource Center: SBOM Glossary
Mayhem Documentation: Dynamic SBOM with Mayhem
Bugcrowd: Bugcrowd Acquires Mayhem Security