Make every finding carry a stable fingerprint, store its state, and notify only when a finding is new, reopened or changed in severity. A nightly scan that re-sends the full list teaches people to mute the channel, and then a real alert is missed.
Why repeats happen
A scan is stateless by default. Every night it reports everything it sees. If 80 known findings are open, you get 80 lines each morning. After two weeks, nobody reads them.
The fix is to separate two jobs: detecting findings and deciding whom to tell.
The fingerprint
A fingerprint must stay the same across runs for the same issue. A common recipe:
| Part | Why |
|---|---|
| Advisory or rule ID | Which issue |
| Project or repository | Where |
| Package name and version, or file and rule | What exactly |
Hash those together. When a package is upgraded, the version changes and the fingerprint changes, so the old finding closes and any new one opens.
State model
| State | Meaning | Notify? |
|---|---|---|
| New | First seen tonight | Yes |
| Open | Seen before, unchanged | No, except in a digest |
| Worsened | Severity or exploit evidence increased | Yes |
| Fixed | No longer present | Close quietly |
| Reopened | Fixed, then seen again | Yes |
| Accepted | Suppressed with a reason and an expiry date | No, until expiry |
GitHub's own alert event model follows a similar idea. Its dependabot_alert webhook has actions such as created, fixed, reintroduced, dismissed, reopened and auto dismissed (webhook events reference).
Steps
- Compute fingerprints in the scan job.
- Compare tonight's set to yesterday's stored set.
- Send immediate notices only for new, worsened and reopened.
- Send a weekly digest of everything still open, grouped by owner.
- Give accepted findings an expiry date so they come back for review.
A caution on baselines
When you first turn on a scanner, the whole backlog looks new. Mark the initial set as the baseline and alert on change from there, then work the backlog on a planned schedule. See baseline a new scanner without a finding flood.
Try it yourself
In the demo, look at how findings are listed with status and priority. Notice what you would want to be told about versus what can wait.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning with reachability analysis, which helps rank what deserves an alert. A free scan is at gold.safeguard.sh/scan.
Quick check
Should I hide open findings completely?
No. Keep them in a digest and a dashboard so they are not forgotten. Just stop pushing them daily.
What if the fingerprint changes every night?
Then it includes something unstable, like a timestamp or line number. Remove it.
Sources
Last reviewed: 19 October 2026.
