How DeployHub Uses SBOMs to Turn Bills of Materials into Production Security Insight

Updated

DeployHub uses SBOMs as the component inventory input, then combines them with deployment evidence to map each open-source package and version to the endpoints where it is actually running. When a new CVE is disclosed, that mapping lets teams see which live systems are exposed instead of guessing from a static dependency list. The approach fits organizations that already produce SBOMs and want post-release visibility; it is not a replacement for pre-release scanning or runtime threat detection.

From SBOM to Endpoint Mapping

The core mechanism has three parts:

  1. SBOM as the component record. The SBOM identifies which open-source packages and versions are part of a release. On its own, it answers "what is in this build," not "where is it running."
  2. Deployment evidence as the location record. DeployHub pairs the SBOM with evidence of where that release was deployed. This is what connects a vulnerable package to a specific endpoint at risk.
  3. Continuous CVE matching. As new vulnerabilities are disclosed, DeployHub checks them against the mapped components and surfaces the affected endpoints in real time.

The platform describes this as agentless post-deployment vulnerability detection built on the Ortelius open-source core. The practical result is a production view that ties a CVE to the systems that actually contain the vulnerable version.

Why the Distinction Matters

Knowing a dependency exists is not the same as knowing it is exposed. DeployHub's own example makes this concrete: a 2025 vulnerability in React Server Components (rated CVSS 10.0) could affect applications simply because they supported React Server Components, even if they never explicitly implemented Server Functions. A dependency list alone would not tell you whether the vulnerable version is live.

The same logic applies to any newly disclosed CVE. The question shifts from "do we use this package?" to "which running endpoints use the vulnerable version?" That is the gap SBOM-plus-deployment-evidence is meant to close.

What Teams Get from the Mapping

Capability What the SBOM contributes What deployment evidence adds
CVE exposure visibility Package and version identity Which endpoints run that version
Attack surface analysis Open-source component inventory Real production footprint
Security profiles of open-source packages Package-level context Where each package is deployed
Production digital twin Component baseline A live model of deployed software

DeployHub also positions this data for DevSecOps pipeline integrations, so the same component and deployment records can feed security workflows rather than living in a separate silo.

When This Approach Fits

This model is a good match when:

  • You already generate SBOMs for releases and want them to drive security decisions after deployment.
  • You need to answer "where is this CVE running?" quickly across many endpoints.
  • You prefer agentless detection over installing agents on every host.

It is less suited as a standalone answer if you have no deployment tracking in place, since the SBOM alone cannot locate running instances. It also does not replace pre-release dependency scanning, which catches issues before code ships; the two serve different stages.

Getting Started

DeployHub offers a demo path and free open-source resources, and its platform pages cover SBOM intelligence, attack surface analysis, and production digital twins. Pricing and login requirements are not specified in the available material, so confirm access terms directly before planning a rollout. A practical first step is to verify that your SBOM output includes package versions and that your deployment records can be tied to specific endpoints, since those two inputs determine how useful the resulting exposure view will be.