Before you open a ticket for a container scan finding, confirm the exact image digest, the package and its layer, the installed and fixed versions, the vendor status, whether it is a duplicate of another row, whether the code is reachable, and who owns the fix. A ticket with those seven items rarely bounces.
The seven checks
1. Name the digest, not the tag
Tags move. Record the digest the scan ran against so the engineer can reproduce it. Without it you may be arguing about an image that no longer exists.
2. Find the layer and the owner
Which build step brought the package in? A base layer points to the platform team, an install step to the app team. Layer background: what a container image layer is.
3. Read installed and fixed versions
Use the package manager's comparison. A blank fixed version means no published fix for that release. See what the fixed version means.
4. Check the vendor status
Fixed, deferred, ignored and not affected lead to different actions. Do not file a fix ticket for something the vendor marked not affected.
5. Look for duplicates
Several rows may share one source package or one CVE. File one ticket per fix, not per row. See why one CVE lists several packages.
6. Judge reachability
Is the vulnerable code loaded by the service? Presence is not exploitability. See installed is not exploitable. Reachability sets priority and does not remove the ticket.
7. Choose the action
Pick from rebuild, update lockfile, remove, replace base, or exception. See rebuild, patch or replace.
A ticket template
Image: registry.example.com/team/app@sha256:<digest>
Finding: CVE id, package, path
Layer / owner: base or app step, team name
Installed: version Fixed: version or none
Vendor status: fixed / deferred / ignored / not affected
Duplicates merged: list of rows
Reachable: yes / no / unknown, how checked
Action: rebuild / update / remove / replace / exception
Due: date, per your policy
Verification: new digest and rescan result
Why this saves time
Most bounced tickets fail on missing context. The engineer cannot tell which image, which layer or which version, so they ask, and the clock runs. Filling the template takes minutes and prevents a day of questions.
Close the loop
When the work is done, add the new digest and the rescan result to the ticket. Steps are in confirming a fix landed.
Where Safeguard fits
Safeguard's SBOM and dependency scanning supplies the package, version and path data for each finding, and its policies can route work by rule. Free scan: gold.safeguard.sh/scan.
Common mistakes the checklist prevents
Filing against a tag. The engineer pulls the tag a week later, gets a different image, cannot reproduce the finding, and closes the ticket as not reproducible. The digest in the ticket prevents that.
Filing one ticket per row. A single source package can produce several rows. Three tickets get three owners, who each upgrade the same package, and two of them find nothing left to do.
Filing a fix ticket for a finding the vendor has marked not affected or ignored. The engineer cannot fix it, so the ticket idles. Route those to a review of exceptions instead.
Skipping the owner. A ticket assigned to a general security queue waits for someone to read it, work out whose layer it is and reassign it. Naming the layer and the likely owner in the first message removes that wait.
Leaving out the verification step. Without a definition of done, a ticket is closed when a pull request merges, not when the new digest is scanned clean. Add the verification line so the closure means something.
How long the checklist takes
For most findings the seven checks take a few minutes, because the scan already shows the package, version and path. The slower parts are reachability and the vendor status lookup. If you do them often, write down the answers for common packages in a shared note so the next ticket can copy them.
Review the template every quarter. If engineers keep asking for the same missing field, add it. If a field is never read, drop it. A short template that gets filled in beats a long one that does not.
Quick check
Should low severity findings get tickets?
Follow your policy. Many teams batch low findings into base refreshes instead of individual tickets.
What if I cannot tell the owner?
Start from the layer. If it is the base, route to the platform team. If you still cannot tell, assign the service owner and let them reroute.
Last reviewed: 19 October 2026.
