Group by advisory and package, not by repository. Open one tracking item per advisory with a named lead, list the affected repositories inside it, and close the item when the last repository is fixed. This turns forty alerts into one piece of work with forty checkboxes.
Why one advisory becomes many alerts
Alerting tools raise an alert per repository and per manifest that lists the affected package. A popular library is in many repositories, and a package can appear several times in one repository through lockfiles in different folders. So one advisory produces a flood that looks like forty problems and is really one decision.
The alerts are not wrong. The unit of work is wrong. Engineers who see forty tickets each assume someone else is coordinating.
The grouping key
| Level | Key | Why |
|---|---|---|
| Advisory | Advisory ID | One decision about severity and urgency |
| Package | Ecosystem and package name | One fix version to agree on |
| Repository | Repo and manifest path | The actual place to change |
| Owner | Team | Who does the work |
Create the tracking item at the advisory and package level. Everything below it is a sub task.
Steps
- Pick the identifier you will group on. Use the advisory ID, and cross reference the CVE if one exists.
- Collect every affected repository from your inventory. An SBOM per service makes this a search instead of a hunt. See deduplicate components across many SBOMs.
- Decide severity once for the organization, then adjust per service if a service does not reach the code. See reachability filter math.
- Agree the fix version. If versions differ per major line, list each.
- Assign a lead who tracks progress, and ask each owning team to confirm their repositories.
- Post a short status update every few days: repos done, repos remaining, blockers.
- Close when every repository is fixed, excepted with an expiry, or confirmed not affected.
Handling the exceptions
Some repositories will not be fixable quickly. Record them in the same item with a reason, an owner and a review date, so the exception is visible and not hidden inside a muted alert. See mute alerts with an end time and an owner.
What to measure
Time from advisory published to the last repository fixed, and the share fixed in the first week. These show whether coordination works. The count of raw alerts does not.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how many findings remain once reachability is applied.
Quick check
Should each repository get its own ticket?
Usually the owning team needs a task per repository, but they should hang under one tracking item per advisory so progress is visible in one place.
How do I know which repositories are affected?
Search your SBOMs or dependency inventory for the package and version range named in the advisory.
Safeguard's SBOM and dependency scanning, with reachability analysis, show which services contain an affected package and whether the vulnerable code is reached. A free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
