To compare two SCA reports, match findings by vulnerability ID, package and version, then sort them into four buckets: new, fixed, unchanged and changed. Then ask why each new finding appeared. The cause is either a code change or a database update, and the right response differs for each.
Why a diff beats a total
A single number such as "112 findings" tells you little. Whether it went up or down matters, and so does why. A report that grows because a developer added a risky package is a different story from one that grows because a new advisory was published for a package you have had for two years.
The four buckets
| Bucket | Definition | What to do |
|---|---|---|
| New | In the second report only | Find the cause |
| Fixed | In the first report only | Confirm the fix landed |
| Unchanged | In both | Check age and owner |
| Changed | Same ID, different attributes | Look at what moved |
Changed covers cases such as a package version bump that did not clear the finding, a new fixed version appearing, or a severity or exploit flag changing.
Two causes of new findings
- Code or dependency changes. A package was added or upgraded. The diff of the lockfile will show it. This is the case a pull request check should catch.
- New knowledge. A vulnerability database added an entry for a package you already had. Nothing in your code changed. This is why scanning continuously matters: your inventory can become vulnerable overnight.
To tell them apart, compare the package lists of the two reports. If the package and version were in the first report and the finding was not, the cause is new knowledge. If the package or version is new, the cause is a change.
Steps
- Normalize both reports to a key of vulnerability ID, package name and version, and collapse alias IDs.
- Join the two lists and label each row with its bucket.
- For new findings, label the cause as change or new knowledge.
- For unchanged findings, record how long each has been open and whether it has an owner.
- For fixed findings, spot check that the package version in the lockfile actually changed.
- Summarize in three lines: new, fixed, still open, with the oldest open item named.
What to watch in the trend
- A steady inflow of new knowledge findings is normal. A steady inflow of change findings means review at the pull request stage needs work.
- A growing pile of unchanged findings means ownership or time is the bottleneck, not detection.
- Fixed counts that exceed new counts over several reports show the backlog actually shrinking.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a finding can appear later for a package that has not changed.
Where Safeguard fits
Safeguard's continuous monitoring and SBOM scanning rescan inventory as new advisories arrive, so new-knowledge findings are surfaced as they happen rather than at the next release.
Quick check
Why did a new finding appear when nothing changed?
A vulnerability database likely added an advisory for a package you already use. Continuous rescans catch this.
What if the finding is gone but the package version did not change?
Check the advisory. It may have been withdrawn, or the record may have been corrected. Confirm before counting it as fixed.
Last reviewed: 19 October 2026.
