SBOM maintenance across product releases
Sytance · Updated
An SBOM needs to remain linked to the software release it describes. A software update may change the components, while an SBOM correction may only fix information about an unchanged release. Recording both versions makes it possible to identify what customers received and which inventory describes it accurately.
The software described by each inventory
Choose a repeatable point in the build or release process to generate the SBOM. Preserve the source revision, resolved dependencies, build configuration and final artefact identity needed to reproduce or investigate the inventory.
CycloneDX’s guide distinguishes inventories generated from source code, during a build and in operation. These stages can contain different software. Naming the stage tells a recipient whether the SBOM describes declared dependencies, a build result or deployed software.
For a gateway, combine information from the application build, the base image and supplied firmware components. Keep the relationship to each supplier SBOM. A cloud service used by the gateway may need a separate inventory with its own release cadence.
Component changes between releases
A release comparison shows which components were added, removed, upgraded or rebuilt, together with changed dependency paths. Component counts alone can miss a replacement: one library can be removed and another added without changing the total.
Use normalised identities for comparison while preserving the original version and identifiers. If a tool starts recognising previously unknown packages, distinguish improved visibility from a real software change.
- Added or removed components and their parent dependency paths.
- Version changes, downstream patches and changed artefact hashes.
- Changes to licence declarations or component producers.
- New gaps, corrected identifiers and supplier SBOM revisions.
Checks before release
Validate the file against the format version, then inspect its meaning. Confirm that every reference resolves, the root product is the intended release and the recipient can access any linked component SBOMs.
Run vulnerability and licence checks on the candidate and record the results against that release. A newly introduced high-priority issue needs a treatment decision. An old exception should be reviewed if its component version or operating assumptions changed.
Archive the accepted artefact, SBOM, build references and review outcome together. If signing is used, verify the signature and confirm that it belongs to the expected issuer.
Corrections to an existing SBOM
The 2026 joint SBOM guidance calls for an SBOM for each software version or update, and a revised SBOM when errors are corrected or new component details become known. It also distinguishes information that is unknown from information deliberately withheld.
For example, a supplier corrects a component’s producer while the firmware bytes remain unchanged. Keep the firmware identity, issue a new SBOM revision, explain the correction and retain the previous document. Recipients can then distinguish a data correction from a software update.
Publish an update through the agreed distribution channel. A stable landing page can point to the current revision while immutable files retain the history. Confirm that recipients can identify which revision supersedes an earlier one.
New vulnerabilities in supported releases
When an advisory arrives, search component identities across supported releases. Review the actual builds and product use before assigning impact. Keep the component inventory separate from the vulnerability assessment so the same SBOM can be reassessed as new information appears.
If gateway release 1.0 contains an affected library and release 1.1 removes it, the new release does not change the composition of installed 1.0 devices. The team still needs a response for those devices and an accurate record of the versions covered by an advisory or VEX statement.
Agree who maintains supplier updates, who assesses impact, who approves a response and who communicates it. Define review timing according to the product’s support obligations and the severity of new information rather than relying only on the next scheduled release.
Record retention and handover
At the end of support, preserve the release-to-SBOM mapping and the decisions needed to explain historical deliveries. Restrict sensitive records as appropriate, while keeping authorised recipients able to obtain the information they were promised.
At handover, a new maintainer needs to find the inventory for a product version, locate a component and read the latest impact assessment. Walking through one supported release helps identify missing records or access permissions.