SBOM and OBOM: connect your release with what runs in production

Your release inventory and your production inventory answer different questions. Understanding the relationship between them helps you find affected deployments, focus mitigation and explain what is running in a specific customer environment.

Two inventories, two questions

When a software issue affects a particular package version, two questions follow: did we include that version in a release, and where is it running now? A release inventory helps answer the first. An inventory tied to a deployed device helps answer the second.

A Software Bill of Materials, or SBOM, records (among other things) the dependencies and versions included in or referred to by a software release. It establishes a baseline for understanding what was supplied. An Operational Bill of Materials, or OBOM, records the packages and versions deployed in a specific context, including changes made after release.

The distinction matters whenever production changes. A release remains an important reference, but the environment running today may contain a different version of a component.

An illustrative example

Imagine a platform release containing Component A version 1.0. Its release SBOM records that version. Two customer services initially use the release: Service North and Service South.

Later, Service North receives an update to Component A version 1.1, while Service South continues to run version 1.0. The release SBOM still correctly describes the original release. Operational inventories should now distinguish the versions deployed in the two services.

Suppose a newly identified issue affects version 1.0. The release baseline tells the team that the affected version was supplied. The service-specific inventories help identify where to investigate and plan action: Service South still contains that version, while Service North has changed.

These names and version numbers are illustrative. They demonstrate an inventory question, without implying that a particular update fixes a particular vulnerability.

Use inventory to focus the next decision

An inventory is evidence for investigation. A package's presence does not, by itself, establish the effect of an issue on a complete application. Teams still need to assess the affected version, its use in the service and the relevant security information before deciding what action is appropriate.

Connecting release and operational inventories makes that assessment more focused. Teams can identify the services containing a version, distinguish deployments that have changed, and direct attention to the environments requiring investigation. This can help shorten the path from a component-level issue to a service-specific mitigation plan.

The same connection is useful before production. Release inventories support dependency assessments during development and testing; operational inventories carry that visibility into deployed services.

Give operational inventory an owner

Inventory becomes less useful when its scope or currency is unclear. Establish which service an operational inventory describes, what it covers, when it was produced and how changes will be reflected. Agree who maintains that evidence when different teams own the platform, application and operations.

For customer deliveries, include this in the responsibility discussion. A release document alone cannot explain every subsequent change in a customer's environment. The team operating the service and the supplier maintaining the platform need a shared understanding of their respective roles.

How DeeDee Inspect supports this work

Visar supplies SBOMs in CycloneDX format for DeeDee releases and all software packages in our repositories. DeeDee Inspect connects this release baseline with customer-specific production inventory through OBOMs, helping teams understand the relationship between supplied software and deployed versions.

That visibility supports locating exposure, targeting mitigation and providing inventory evidence for security and compliance reviews. It complements the assessment of your application and complete environment.

Discuss your first environment with Visar

Bring an application, its required platform services and your security requirements. Together, define what to evaluate, which responsibilities Visar will take on, and what your team will retain.