Runtime Bill of Materials (RBOM)

What Is a Runtime Bill of Materials?

A runtime bill of materials (RBOM) is an inventory of the software components that actually execute when an application runs, the libraries loaded, the binaries invoked, the code paths exercised. It is produced by observation rather than declaration.

This makes it the empirical counterpart to an SBOM. An SBOM answers what is in this artifact. An RBOM answers what does this artifact use. In a typical container image those two answers diverge dramatically, and the gap between them is where most vulnerability findings live.

The practical value is triage. If a CVE sits in a package that never loads, it is a real vulnerability in code that cannot be reached, and knowing that with evidence rather than assumption changes what you do about it.

How an RBOM Differs From an SBOM

Both are inventories. They answer different questions, are produced differently, and are used for different decisions.

SBOM vs. RBOM

Question answered: An SBOM answers "What is in this artifact?" while an RBOM answers "What does this artifact use?"
Produced by: An SBOM is produced by static analysis of manifests; an RBOM is produced by runtime profiling under load.
Timing: An SBOM is generated at build time; an RBOM is generated at execution time.
Completeness: An SBOM captures everything present; an RBOM captures everything observed.
Primary use: SBOMs support compliance, provenance, and disclosure; RBOMs support triage, reduction, and reachability.
Blind spot: An SBOM has no execution signal; an RBOM makes unexercised paths look unused.

How RBOM Data Is Used to Eliminate Unused Vulnerabilities

The workflow is straightforward, and the discipline is entirely in the profiling stage.

Profile Under Representative Load

Run the workload across a period long enough to exercise real behaviour, production traffic, peak periods, batch jobs, failure modes, admin operations. A profile from a smoke test in staging will show you a fraction of what genuinely runs.

Diff Against the SBOM

Subtract observed components from installed components. The remainder is the candidate set: everything present that was never touched. In a conventional base image this is typically the large majority of packages.

Segment the Findings

Cross-reference open CVEs against the diff. Findings in observed components are reachable and belong at the front of the queue. Findings in unobserved components are real but dormant, and can be handled by removal rather than patching.

Remove Rather Than Patch

For unused components with CVEs, deletion is superior to patching in every respect: the finding disappears permanently rather than returning at the next disclosure, and there is no upgrade to test. This is the same mechanism described in container hardening techniques, the safest component is an absent one.

Keep a Rollback Path

Removal based on incomplete observation breaks things. Stage removals, monitor for missing-file and missing-library errors, and be able to revert quickly. Treat the first weeks after a removal as a validation period, not a completed project.

Where the RBOM Fits in a Container Security Program

The RBOM is a diagnostic instrument, not a control. It tells you what to do; it does not do anything by itself. That framing matters because it is easy to mistake having the data for having acted on it.

It sits between two things you also need. Upstream, software composition analysis produces the SBOM, the complete picture, required for compliance, provenance, and disclosure obligations. Downstream, reduction acts on the RBOM's findings by removing what it proves unnecessary.

The relationship to SBOM tooling is worth being precise about: an RBOM is generated per workload per environment and reflects one deployment's behaviour, whereas an SBOM is generated per artifact and reflects its contents anywhere. They live in different parts of the pipeline, which is why SBOM generation tooling and runtime profiling are separate capabilities rather than competing ones.

There is a sequencing argument worth making. RBOM-driven reduction takes a bloated image and carves it down through observation, which works but requires ongoing profiling discipline and carries removal risk. Starting from a minimal image inverts the problem: instead of proving what is unused, you add only what is proven necessary. The RBOM is most valuable for workloads you cannot rebuild from minimal foundations, and for verifying that a minimal image really is as minimal as claimed.

FAQ

Can an RBOM replace an SBOM for compliance purposes?

No. Compliance frameworks and disclosure obligations require a complete inventory of what an artifact contains, including components that never execute. An RBOM records only observed behaviour in one environment. It is a complement for triage and reduction decisions, not a substitute for the full component record an SBOM provides.

How is runtime profiling used to generate an RBOM?

Instrumentation observes the running workload and records loaded shared libraries, invoked executables, opened files, system calls, and network activity. Profiling must span representative behaviour, peak traffic, batch jobs, error paths, admin operations, because anything not exercised during observation will appear unused whether it is or not.

How does an RBOM affect CVEs from unused components?

It reclassifies them. A CVE in a component the RBOM never observed is real but not reachable in that deployment, so it can be de-prioritised against reachable findings and resolved by removing the component rather than patching it. Removal is permanent; patching only lasts until the next disclosure.