A scan finding becomes work when the ticket states the package, current and fixed versions, where it is used, why it matters and when it is due. Vague tickets such as "fix CVE" sit for months. Specific ones get done. Here is a template and a worked example.
Why findings stall
Scan output lists problems, not tasks. Engineers need to know what to change, how risky the change is and who decides. Without that, a ticket becomes a debate.
The template
- Title: upgrade package X from version A to version B.
- Finding: CVE id and one sentence on the flaw, from the advisory description.
- Fix status: fixed in version B, or not fixed with the mitigation.
- Where used: services and repositories that include it, runtime or dev only.
- Exposure: does it handle untrusted input? Is the vulnerable function called?
- Signals: CVSS vector, EPSS, KEV status, with the date checked.
- Change risk: patch, minor or major upgrade, and tests to run.
- Owner and due date.
- Link to the CVE page.
A worked example
All values here are made up to show the template.
Title: Upgrade a container library from 1.2.0 to 1.2.3 in the build service. Finding: an authorization bypass triggered by oversized request bodies, per the advisory. Fix status: fixed in 1.2.3. Where used: build service, runtime. Exposure: reachable only from an internal network. Signals: local attack vector, low EPSS, not in KEV, checked on the day of triage. Change risk: patch release, run integration tests. Owner: platform team. Due: end of next sprint.
Deciding the due date
Set due dates by risk class, not by mood. For example, KEV listed and exposed: days. High severity and reachable: a couple of weeks. Low exposure: next planned upgrade. Write your own table and apply it consistently. FIRST notes CVSS is severity, not risk, and CISA advises KEV as an input to prioritization, so use them together.
Group related findings
If five packages share a parent framework, one upgrade ticket is better than five. Group by upgrade action, not by CVE count.
Close the loop
Rescan after the change and attach the result. Record any accepted risk with an owner and a review date. If a fix is not available, link to /resources/blog/not-fixed-cve-status-what-to-do-next.
Automate the boring parts
Safeguard can send findings to issue trackers and can propose fix pull requests, which are off by default and require manual approval. To produce a first list, run a manifest through gold.safeguard.sh/scan.
Quick check
How many findings per ticket?
One ticket per upgrade action. Several CVEs fixed by one upgrade belong together.
Sources
Last reviewed: 19 October 2026.
