Make a small change in a test branch, ask the demo to rescan, and look for three groups: new findings, fixed findings, and unchanged ones. A scanner that tracks identity over time can answer this. One that starts from scratch each run cannot, and your developers will drown in repeats.
Why this matters
Developers care about what their change did. If a pull request check lists two hundred findings and only one came from the change, the signal is lost and the check gets ignored.
Tracking the difference between runs also underpins everything else: trends, closure rates, and the evidence that a problem was fixed on a certain date.
The rescan test
- Scan a branch and note the findings.
- Upgrade one vulnerable dependency in a new commit.
- Rescan. The fixed finding should move to a fixed state, not just vanish.
- Add one dependency with a known vulnerability in another commit.
- Rescan. That finding should appear as new, and the others as unchanged.
- Revert the second commit and rescan to see how it is recorded.
What to look for
| Behavior | Good | Concerning |
|---|---|---|
| Fixed finding | Marked fixed with a date | Disappears with no record |
| New finding | Clearly labeled as new on this change | Mixed in with old ones |
| Unchanged finding | Keeps the same identity and age | Appears as a new item each run |
| Reverted change | Reflected correctly | Stale state |
Identity is the key idea. A finding should be recognized as the same one across runs, so its history, owner and status stay attached. Ask how identity is decided, for example by package, version, advisory and location.
Ongoing monitoring
Findings also change without any code change. New advisories are published against packages you already use. Ask how the tool handles this: does it rescan stored inventory when advisory data updates, and how are you notified? A repo that was clean on Monday can have a finding on Friday with no commit at all.
Ask also how long it takes between an advisory being published and the tool reflecting it. A precise answer, with a way for you to measure it, is better than a general promise.
Questions for the follow-up
- Is finding history kept after a branch is deleted?
- Can status be carried over when a repository is renamed or moved?
- How are duplicate findings across branches handled?
- Can I see the age of each open finding?
Where Safeguard fits
Safeguard supports continuous monitoring of stored inventory, plus zero-day discovery. The demo below shows monitoring over time.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a change over time is presented, and whether you can tell what is new.
Quick check
Why not just rescan from scratch each time?
You can, but you lose history, ownership and the ability to tell developers what their change introduced.
Can new findings appear without a code change?
Yes. New advisories can be published for packages you already use, so monitoring matters.
Last reviewed: 19 October 2026.
