Findings should live in three places for three jobs. The scanner holds raw detection data and history. An ASPM layer or a shared sheet holds the deduplicated, ranked view. The engineering team's own ticket tracker holds the work item that someone is accountable to finish.
Why one location does not work
A scanner is built to detect, not to manage work. An ASPM view is built to rank, not to assign sprint tasks. A ticket tracker is built for work, not for tracking whether the underlying vulnerability still exists. Forcing one tool to do all three produces clutter or gaps.
The three layers
Layer 1, the scanner (system of detection). It owns raw findings, scan history, and proof that something was or was not present at a given time. Do not edit status here by hand. Status should follow the rescan.
Layer 2, the ranked view (system of priority). This is ASPM or, for a small team, a sheet. It owns the deduplicated list, the application and owner mapping, and the priority rules. It answers "what matters most right now."
Layer 3, the tracker (system of work). Developers already live here. A ticket carries the component, the fixed version, the deadline from policy, and a link back to the finding.
How they stay in sync
- Scanner to ranked view: automatic import on every scan.
- Ranked view to tracker: create a ticket when a finding crosses the policy threshold, not for every finding.
- Tracker to scanner: closing a ticket does not close the finding. The next scan does. If the finding persists, reopen the ticket automatically.
This last rule prevents the common failure where a ticket is closed as done and the vulnerability remains in production.
What goes in a ticket
- Application and owning team.
- Component, current version and fixed version.
- Why it matters: KEV listed, exploitation probability, reachable or not.
- Deadline and the policy that set it.
- How to verify: which scan will confirm the fix.
CISA's Known Exploited Vulnerabilities catalog gives each entry a due date, a model worth borrowing: a date attached to the item, visible to the doer.
What to avoid
- Sending every finding to the tracker. That teaches developers to ignore the tracker.
- Making developers log into security tools to find their tasks.
- Closing findings by hand in the scanner to make dashboards look better.
- Tracking exceptions in chat. Record them next to the finding, with approver and expiry.
A small team version
A team of ten can do this with a scanner, one shared sheet for the ranked view, and the existing issue tracker. The sheet has columns for application, owner, priority and ticket link. Review it weekly. Add an ASPM layer later only if the sheet becomes unmanageable.
NIST's patch management guidance frames the work as identifying, ranking, obtaining, deploying and confirming. The three layers map onto that: detect, rank, then execute and confirm.
A worked example
A team has a dependency scanner, a shared sheet and an issue tracker. A new finding arrives.
- Scanner: the nightly scan records a vulnerable library in the billing service, with the build ID and the date.
- Ranked view: the sheet import adds a row. The CVE is looked up in the CISA catalog, EPSS is added, reachability is marked yes. Policy puts it in tier two.
- Tracker: because tier two creates a ticket, a work item appears in the billing team's board with a deadline, the fixed version and a link to the row.
- Fix: a developer upgrades, merges and deploys.
- Scanner: the next scan no longer reports the library. The row in the sheet flips to closed with the date, and the ticket closes by automation.
At every point, each system did the job it was built for.
Step by step: set up the three layers
- Pick the scanner of record for each artifact type and stop editing statuses by hand.
- Create the ranked view with the columns in our sheet guide, or use an aggregation tool.
- Define the ticket threshold in writing, for example tier one and two only.
- Use one ticket template with fields for component, versions, reason, deadline and verification.
- Automate the return path. A persisting finding reopens its ticket.
- Review weekly the items past their deadline.
What each layer should never do
| Layer | Should not |
|---|---|
| Scanner | Hold the only record of exceptions or approvals |
| Ranked view | Become the place where developers are expected to work |
| Tracker | Be the source of truth for whether a vulnerability still exists |
Edge cases
- Findings with no owner. Keep them in the ranked view with a flag, and assign through a weekly review.
- Findings that span services. Create one ticket per owning team, linked to one shared row.
- Accepted risk. Record the approver, reason and expiry date next to the finding and set a reminder on the expiry.
- Scanner outages. Do not close findings because a scan failed. Closure requires a successful scan that no longer reports the issue.
Why this beats a single tool
A single tool tends to do one of these jobs well and the others poorly. Splitting the roles lets you replace one layer later, for example swapping the sheet for an aggregation platform, without rewriting how developers receive work. The tickets stay where they are, which is the part developers care about most.
Try it yourself
Follow one finding from detection to closure and note where a person or a policy takes over.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard provides scanning, policies and gates, and fix pull requests (off by default), which fit the detection and execution layers. A free scan is at gold.safeguard.sh/scan.
Quick check
Should a closed ticket close the finding?
No. Only a rescan that no longer detects the component should close it.
Do small teams need a separate ranked view?
A shared sheet is often enough until the number of tools or applications makes it hard to maintain.
What if developers do not want yet another tracker?
Use theirs. Create tickets in the tracker they already open and link back to the finding, so they never need to log into a security tool for routine work.
Sources
Last reviewed: 19 October 2026.
