Know which packages actually run
An SBOM lists everything shipped in an image. A runtime BOM shows the fraction that actually loads. SBOMVault runs your image in an isolated, agentless sandbox, watches the files it touches, and maps them back to packages — turning a thousand-component inventory into the handful that truly execute.
From image to runtime footprint — agentlessly
“Agentless” means there is nothing to deploy. SBOMVault does the running and the watching in its own isolated sandbox, so you get a runtime view of any image without instrumenting it, shipping a sidecar, or putting a kernel agent anywhere near production.
01
Flatten the image
We pull and flatten the container image to a root filesystem with a daemonless tool — no Docker, no privileged runtime, just the bytes that ship.
02
Run it in isolation
The entrypoint runs inside an isolated Firecracker microVM for a bounded warm-up window. Untrusted code never touches your infrastructure — or ours.
03
Observe file access
We record which files the running process actually reads — no instrumentation, no eBPF agent in your cluster, no changes to your image.
04
Map files to packages
Accessed files resolve back to their owning OS packages (apk / dpkg), producing the set of components that genuinely load at runtime.
Most of an image never runs
A container image carries hundreds — often a thousand or more — packaged components. Only a small fraction are exercised when the workload starts. Dynamic RBOM separates the two, so “everything that’s installed” stops being the same thing as “everything that matters.”
That gap is leverage: a smaller attack surface to harden, a shorter vulnerability queue to triage, and a clear, evidence-backed list of components you can strip from the next build.
Illustrative: a stock nginx image
1,026
components shipped
12
loaded at runtime
A measured run of nginx:alpine. Your numbers depend on the image and what its entrypoint does during the warm-up window.
Shrink the attack surface
Packages present but never loaded are removal candidates. Dynamic RBOM tells you which ones are safe to strip from the next build.
Deprioritize, never hide
Vulnerabilities in components that never execute drop down the queue so your team works the findings that actually matter — but nothing is removed from the SBOM.
Zero setup
No sidecar, no kernel module, no code change. Point it at an image reference and get a runtime picture back — the fastest path to a first RBOM.
What it is — and what it isn't
Dynamic RBOM observes what an image loads when it starts, inside a bounded warm-up window in our sandbox. It is a fast, zero-setup runtime picture — not a full census of every code path your production traffic will ever exercise.
It is credibility-gated: when an observation is inconclusive, SBOMVault keeps the complete SBOM and marks nothing as unused. It will never hide a component — or a vulnerability — on weak evidence. Findings are only ever deprioritized, never removed.
For continuous evidence from real production traffic, pair it with RBOM ingestion — feed your own eBPF, APM, or coverage data and SBOMVault correlates it the same way. Dynamic RBOM is the agentless way to get that first runtime signal without deploying anything at all.
See what actually runs in your images
Point SBOMVault at a container image and get back a runtime BOM — the components that truly load, the ones you can safely strip, and a vulnerability queue ranked by what really executes.
Frequently asked questions
- What is a dynamic RBOM?
- A runtime bill of materials (RBOM) records which components of a piece of software actually execute, as opposed to an SBOM, which lists everything that is installed. SBOMVault generates a dynamic RBOM by running a container image in an isolated sandbox, observing which files the running process reads, and mapping those files back to their owning packages — the components that genuinely load at runtime.
- Why "agentless"? Where does it run?
- There is nothing for you to deploy. SBOMVault runs the image in its own isolated Firecracker microVM sandbox and observes file access there — no eBPF agent, no sidecar, no kernel module, and no changes to your image. You provide an image reference; SBOMVault does the running and the watching.
- How does it decide a package is "used"?
- During a bounded warm-up window, SBOMVault records the files the running process actually reads, then resolves those files back to the OS packages that own them (via the apk and dpkg databases inside the image). A package whose files are read is marked runtime-used; one whose files are never touched becomes an attack-surface-removal candidate.
- Could it wrongly mark a real dependency as unused?
- No — that is the design constraint. The result is credibility-gated: if the observation is inconclusive, SBOMVault keeps the full SBOM and marks nothing as unused. Vulnerabilities in components that did not load are only deprioritized in the queue, never hidden or removed. A false "unused" must never mask a real vulnerability.
- Does it replace a production runtime agent?
- No. Dynamic RBOM captures what an image loads at startup in a sandbox — a fast, zero-setup first picture. For continuous evidence from real production traffic, pair it with RBOM ingestion: feed your own eBPF, APM, or coverage data and SBOMVault correlates it the same way.
- Which plans include it?
- Dynamic RBOM is available on the Growth and Enterprise plans, since it runs on the worker sandbox substrate. It produces a normal SBOM that appears in your estate, with vulnerability matching and the runtime-used correlation applied automatically.