Group alerts by advisory and package, not by repository. One flawed library across forty repositories is one decision with forty places to apply it. Create a single parent work item, list the affected repositories under it, and track the fix as one campaign with one accountable owner.
Why per-repo alerts mislead
Most alerting tools raise one alert per repository per advisory. That is correct for the repository owner, but it hides the shape of the problem from the person managing risk. Forty open alerts look like forty problems, when the truth is a single upgrade that forty teams must apply. Counting them as forty also inflates dashboards and drains morale.
Build the grouped view
Take the following steps once, then reuse them for every widespread advisory.
- Choose a stable key: advisory ID plus package name plus fixed version.
- Collect affected repositories, images and deployed services under that key.
- Create one parent item with the advisory link, the fix version and the deadline.
- Open one child task per owning team, not per repository, when a team owns several.
- Close the parent only when every child is verified, not when pull requests merge.
Decide who owns the campaign
Someone has to chase. A central security or platform engineer usually owns the parent, while each repository team owns its child. Write that down before the first widespread advisory arrives. Otherwise each team waits for another to move first.
Group across more than source code
The same library often lives in places a repository alert does not cover.
| Location | How it hides |
|---|---|
| Container images | Baked in at build time, so a source fix does not change a running image |
| Cached or vendored copies | Not in the lockfile |
| Old release branches | Not in the default branch alerts |
| Third party products you run | You cannot edit them, but you can ask the vendor |
An inventory built from SBOMs makes this search a query rather than an investigation. See find a compromised package version across repos, images and caches.
Report the campaign, not the alerts
Report progress as repositories remediated out of repositories affected, plus the age of the oldest open one. Those two figures tell leadership more than a raw alert count, and they show whether the long tail is shrinking.
Where Safeguard fits
Safeguard's SBOM and dependency scanning gives one inventory across projects, which supports grouping by package, and autonomous remediation can open fix pull requests (off by default, every category on Manual). A free scan shows how one project's components list out.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for how a single component appears across projects in the inventory.
Quick check
Should I close alerts when a fix pull request opens?
No. Close when the fix is merged and deployed, and verify it by rescanning.
Who should own the parent work item?
One named person or team, often platform or security, who tracks the whole campaign.
Last reviewed: 19 October 2026.
