Keep release artifacts and SBOM revisions aligned
Decide when to regenerate an SBOM and when to update vulnerability analysis instead. Preserve artifact mappings, previous inventories, and correction history.
A mutable release tag can point to new software while its attached SBOM still describes yesterday's image. Use artifact digests to prevent that mismatch. Keep an explicit map between each distributed artifact and the inventory that describes it, including platform variants and emergency rebuilds.
Classify what changed
Not every security update changes the component inventory. CycloneDX recommends separating dynamic VEX information from an SBOM whose inventory remains unchanged. Use the change itself to decide which record needs a new version.
| Event | Record to review | Reason |
|---|---|---|
| Base image or package changed | New artifact and SBOM | Distributed contents differ |
| Platform variant added | Variant inventory | Components may differ by platform |
| Inventory omission discovered | Corrected SBOM for existing artifact | Earlier description was incomplete |
| New advisory published | Vulnerability analysis or VEX | New knowledge, not new software |
| Deployment configuration changed | Applicability assessment | Exposure can change without package changes |
A corrected SBOM and a new software release are different events. Make that distinction visible to consumers so they do not assume that an inventory correction installed a fix.
Maintain an artifact-to-document map
For each release, retain the artifact digest, platform, release identifier, SBOM identifier and revision, SBOM digest, generation timestamp, and publication location. Add the reason for replacement or correction and a link to the preceding record.
When a build produces new bytes, run collection against the resulting artifact. Reusing the previous document merely because the source commit is unchanged can miss a changed base image, dependency resolution, or build input. Compare the inventories and investigate unexpected removals as well as additions.
For a metadata-only correction, preserve the artifact identity and document the evidence behind the corrected fields. Do not overwrite the only copy of the earlier document. Consumers investigating an older decision need to know what information was available at that time.
Verify publication and consumption
Publish the new mapping with the release evidence. Retrieve the artifact and SBOM through the same distribution path used by recipients, then verify their recorded digests. Confirm that the inventory tool resolves the intended document rather than a cached file under a reused name.
Reassess existing VEX decisions when changed components or build options invalidate their assumptions. Keep advisory refresh timestamps separate from inventory generation timestamps. Close the update only when the release owner can identify which artifact each document describes and consumers can obtain the correct revision without losing historical records.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.