Scan both release SBOMs against the same advisory data on the same day, then compare the two finding sets. Findings only in the old release are fixed, findings only in the new one are introduced, and findings in both are carried over. Using different advisory snapshots makes the comparison meaningless.
Why a component diff is not enough
A component diff says what changed in the software. A vulnerability diff says what changed in your exposure. They differ because advisories are published after release. A component that did not change can gain a new finding next week, and an unchanged release can look worse tomorrow than it did yesterday.
Steps
- Pick one scan date and one advisory data source for the comparison.
- Scan the old SBOM and the new SBOM against it.
- Key each finding on component package URL plus advisory identifier.
- Classify: in old only, in new only, in both.
- For the introduced group, check whether it came from a new component, an updated one, or a newly published advisory on an unchanged one.
- Record the date and source with the result.
Reading the three groups
| Group | Meaning | Typical response |
|---|---|---|
| Fixed | Resolved by updates or removals | Report as improvement, verify the component is really updated |
| Introduced by a code change | Your release added exposure | Review before shipping |
| Introduced by new advisory data | Same software, new knowledge | Handle as normal incoming vulnerability work |
| Carried over | Known and still open | Check it has an owner and a plan |
The second and third groups look identical in a sloppy report. Separating them stops teams being blamed for advisories that appeared after their work.
Handling severity differences
Different databases and scoring versions can rate the same flaw differently, so compare scores from the same source. If you re-score for context, label it separately from the published rating.
Prioritising what remains
Within the carried over and introduced groups, rank by whether the vulnerable code is reachable, whether a fixed version exists, and whether exploitation is known. Reachability analysis reduces the list to what is actually exposed. A fix available now should go through quickly, ideally as an automated pull request that a person reviews.
Reporting to leadership or customers
State the date, the data source and the method, then the three counts and the notable items. Avoid claiming the release is free of vulnerabilities. A statement that scans on a given date found no known issues in the listed components is accurate and defensible.
Keep history
Store each comparison with its release. Over several releases the record shows whether carried over findings shrink or linger, which is more informative than any single report.
Safeguard scans SBOMs and dependencies, applies reachability analysis, and can open fix pull requests with autonomous remediation, which is off by default with every category set to manual. Try the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are grouped and tracked over time.
Quick check
Why scan both releases on the same day?
Advisories keep being published. Scanning at different times mixes new knowledge with real changes.
Can an unchanged component gain a finding?
Yes. A new advisory can apply to a version that did not change.
Last reviewed: 19 October 2026.
