Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A release adds an unexpected network client even though nobody changed the application’s dependency manifest. An SBOM diff can expose that change, provided the two inventories describe comparable artefacts and the comparison preserves uncertainty.
Consider a fictional invoice service moving from one approved container image to its next release candidate. The candidate includes an updated base image and a regenerated lockfile. The release engineer needs a reviewable explanation of what changed, which changes deserve investigation, and what the inventories cannot establish.
An SBOM diff starts with comparable inputs
Record both image digests before comparing package lists. A tag such as a release name can move between collection and review, leaving a report attached to different bytes. Keep the source revision and build reference with each digest so the reviewer can trace a surprising component back to the relevant build.
Next record how each inventory was produced. Comparing a source-manifest inventory with a final-image inventory mixes different scopes: the second can include operating-system packages and files introduced during packaging. That comparison may be useful, but it is a reconciliation exercise rather than a simple release difference.
For the invoice service, generate both inventories using the same supported tool configuration and scanning scope. Preserve the original files as well as the comparison output. If the older inventory cannot be regenerated, document the difference in collection methods and identify which conclusions remain reliable.
Component identity matters more than display names
Two entries with the same short name can belong to different package ecosystems or namespaces. Conversely, one component can appear under slightly different display names after a collector update. Choose matching fields that preserve ecosystem, namespace, name, version and any relevant qualifiers instead of relying on a case-insensitive name comparison.
Treat file hashes and package coordinates as complementary evidence. A version string can stay the same while a distributor rebuilds a package, and identical names do not establish identical contents. If the data does not support a confident match, retain an unresolved pair for review instead of silently merging the entries.
The invoice candidate’s network client illustrates the problem. First establish whether it is a newly introduced package, a previously unrecognised component, or a renamed inventory entry. Each interpretation leads to different work: dependency review, collection-quality review, or a correction to the matching rule.
An SBOM diff needs more than added and removed
Use categories that help someone decide what to inspect. Added and removed components are useful, but changed relationships and missing metadata can matter just as much. A package that moves from a development-only path into the shipped image deserves attention even if its name and version are unchanged.
| Difference | First review question | Evidence to retain |
|---|---|---|
| Added component | Which build input introduced it? | Dependency path and candidate digest |
| Version change | Was the update intended and tested? | Lockfile change and release reference |
| Removed component | Is it absent or no longer detected? | Matching scope and collection result |
| Changed dependency edge | Did packaging change how it is used? | Old and new parent relationship |
| Missing identity fields | Can the entries be compared safely? | Collector warning and original record |
Assign a reviewer to each unexplained change. The application team can explain a library upgrade, while the image-maintenance team may own an operating-system change. Do not route every difference to the developer whose commit happened to trigger the release build.
Keep inventory completeness visible
An inventory is a record of identified components within a collection scope. It is not automatically proof that every bundled, generated or dynamically retrieved dependency was found. CycloneDX can express composition completeness, but the presence of a field does not make the underlying collection complete.
For the invoice example, check whether both scans completed successfully and whether either collector skipped a filesystem location. A failed archive extraction could make several packages appear removed. That is a collection failure to investigate, not evidence that the release reduced its dependency surface.
Retain an explicit unknown state when completeness cannot be established. A reviewer should see the collection warning next to the difference, rather than discovering it later in a separate log. The SBOM fundamentals guide explains the inventory record that this comparison depends on.
Separate release changes from advisory changes
A vulnerability advisory can change between two evaluations even when the image bytes are identical. Keep the inventory comparison separate from the advisory assessment so a new alert is not misreported as a newly introduced package. Record the assessment time and relevant advisory reference with the finding.
Run the candidate’s identified components through the current review process, then explain whether each result follows from changed software or changed knowledge. In the invoice release, an unchanged compression library may acquire a new advisory while the newly added network client has no reported issue. Both observations matter, but they answer different questions.
Avoid equating an empty advisory result with permission to release. Source approval, provenance, licensing review and functional testing remain separate decisions. A useful comparison points to those decisions without pretending to replace them.
Turn the comparison into a release record
The final review should name the baseline digest, candidate digest, inventory inputs, comparison method and unresolved differences. For each accepted change, record the explanation and responsible reviewer. For each unresolved change, state whether it blocks release or follows an explicitly approved exception process.
Use a reproducibility check before closing the review. Give another engineer the two retained inventories and the comparison configuration, then ask them to locate the unexpected network client. If they cannot reproduce the result, improve the record before relying on it during an incident.
After deployment, verify which digest the workload actually uses. An excellent comparison between two images is irrelevant to a service that still runs a third image. The image-to-workload guide connects the release record to that final operational question.
Key takeaways
- Compare inventories tied to immutable artefacts and clearly stated collection scopes.
- Preserve component identity, dependency relationships and unresolved matches.
- Distinguish software changes from advisory updates and collector failures.
- Retain a reproducible comparison and verify the digest that reaches the workload.
How SecurityVault approaches this
SecurityVault retains an SBOM per scan as evidence and connects findings to repository, build, image and workload context. The SCA and SBOM workflow gives teams a place to investigate identified dependencies alongside the artefacts that contain them. That context helps a reviewer distinguish a package in an older image from the same package in a current release candidate.
A comparison still needs clearly defined inputs and matching rules. This guide does not imply that every inventory format or comparison operation is automatically supported. During an evaluation, confirm which component identifiers, dependency relationships and original evidence your chosen integration preserves, then use those records to explain an unexpected change.
The platform overview shows how ownership and retained evidence contribute to the broader investigation. Bring a pair of representative test images, including an intentional dependency change and an incomplete inventory, to a scoped walkthrough. To agree that evaluation and its acceptance criteria, request a demonstration.