Route an SBOM diff to a reviewer when it adds a new component, changes a component's supplier or source, removes a component without explanation, jumps a major version, drops integrity data, changes licenses, or introduces a finding that is in the Known Exploited Vulnerabilities catalog. Most other changes can be logged automatically.
Why triage the diff
Suppliers update frequently. If every diff goes to a person, the queue will be ignored. If none do, a risky change slips in. A short list of triggers gives you a middle path.
The seven triggers
| Change | Why it matters | Reviewer question |
|---|---|---|
| New component | New code, new maintainers | Who maintains it, why was it added? |
| Supplier or origin changed | Same name from a new source can be a swap | Is this the same project? |
| Component removed | Could be a fix, could be hiding | Was it replaced? |
| Major version jump | Behavior can change | Did the supplier test it? |
| Hash changed with same version | Same version label, different bytes | Why would a release change? |
| License changed | Obligations shift | Does legal need to look? |
| New finding in KEV | Active exploitation | Is it reachable, is a fix available? |
CISA says its catalog lists vulnerabilities with reliable evidence of active exploitation, and encourages organizations to treat it as an input to prioritization. That makes the seventh trigger easy to automate.
How to run the diff
- Match old and new documents on the same product and supplier.
- Compare components by identifier such as purl, not by display name. Names change in spelling and case.
- Classify each change into added, removed, version changed, metadata changed.
- Apply the trigger rules to produce a review list.
- Log everything else as informational.
- Send questions to the supplier with the component, old and new values, and your concern.
- Record the decision so the same change is not reviewed twice.
Same version, different hash
If a component keeps its version label but its hash changes, treat that as a trigger. Release artifacts should be immutable. A change might be innocent, such as a rebuild, but it deserves an answer.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new advisory is tied to a component you already hold, which is the same event as the seventh trigger.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, with policies and gates you can set on findings. You can try the free scan on two versions of a project and compare.
Quick check
Should I compare components by name?
Compare by identifier, such as purl. Display names vary.
Is a removed component always good news?
No. Ask whether it was replaced or just dropped from the file.
Sources
- CISA KEV catalog: meaning and use of the catalog.
Last reviewed: 19 October 2026.
