Score what runs, not just what ships
An SBOM lists everything installed; a runtime BOM records what actually executes. Feed SBOMVault the runtime evidence your own tooling already produces — eBPF, APM, coverage — and it correlates that against your SBOM to focus triage on what runs and surface what you can safely strip.
Your evidence, our correlation
You already have tools that see runtime: eBPF tracers, APM, RapidFort, even test-coverage. Post that used-package set to SBOMVault and it matches each entry against your SBOM's components by purl, purl-base, or name — marking what ran and what didn't, and recomputing VaultScore accordingly.
Focus the queue
Vulnerabilities in components that never execute drop down the VaultScore queue, so your team works the findings that actually run.
Shrink the attack surface
Components present but never observed at runtime are flagged as removal candidates — concrete, evidence-backed advice for the next build.
Reranked, never hidden
Unused findings are only deprioritized, never removed from the SBOM. A weak runtime signal can never mask a real vulnerability.
What it is — and what it isn't
Runtime BOM ingests and correlatesevidence — it does not generate it. A SaaS can't run an eBPF agent inside your production environment, so you bring the observation from tooling you already run, and SBOMVault does the correlation, scoring, and removal-candidate analysis.
Want the evidence generated for you without deploying anything? That's the agentless Dynamic RBOM — it runs a container image in a sandbox and observes what loads, then feeds this same correlation. Runtime BOM is the bring-your-own-evidence half of the same capability.
It is API-first (post the used-set from CI or your observability pipeline), per-SBOM, and idempotent — the used list is treated as the complete runtime-observed set, and re-ingesting with better evidence simply overwrites the prior correlation. It only ever deprioritizes; nothing is hidden.
Make runtime evidence count
Correlate what your workloads actually run against your SBOM — and get a ranked queue plus a concrete list of components you can remove.
Frequently asked questions
- What is a runtime BOM (RBOM)?
- A runtime bill of materials records which components of your software actually execute, versus an SBOM, which lists everything installed. SBOMVault ingests runtime-usage evidence you supply, correlates it with your SBOM, and reranks findings so you focus on the components that truly run.
- Where does the runtime evidence come from?
- From your own tooling — eBPF tracers, APM, RapidFort, or even test coverage. You post the set of observed package identifiers and SBOMVault correlates it. A SaaS cannot run an agent inside your environment, so this is the bring-your-own-evidence model. For evidence generated for you, see the agentless Dynamic RBOM.
- How is this different from Dynamic RBOM?
- They are two halves of the same runtime-BOM capability. Dynamic RBOM generates the evidence agentlessly by running a container image in a sandbox and observing what loads. Runtime BOM ingests evidence you already have from production tooling. Both feed the same correlation, scoring, and removal-candidate analysis.
- Could it hide a vulnerability on an "unused" component?
- No. Components not observed at runtime are deprioritized in VaultScore and flagged as removal candidates — but they are never removed from the SBOM and the findings stay visible. A weak or incomplete runtime signal can only lower priority, never mask a real vulnerability.