Open a ticket now for findings that are exploited, reachable and exposed, or that break a written commitment. Schedule fixable routine findings into batches. Track the rest without a ticket. Written intake rules protect engineering time, because every ticket costs triage, ownership and review.
Why intake rules protect capacity
A scanner reports everything it can see. If each finding becomes a ticket, the tracker fills with items nobody will touch, and the ones that matter get lost. Intake rules are the filter between the scanner and the team. They are a capacity control as much as a security control.
A three tier intake
| Tier | Criteria | Action |
|---|---|---|
| Ticket now | Known exploited, or reachable and internet exposed, or breaches a contractual or policy commitment | Create a ticket with an owner and a due date |
| Scheduled | Fix available, routine class, reachable or unknown | Add to the next batch or upgrade day |
| Track only | Not reachable, dev only, or no fix and low exposure | Record in the register, review on a schedule |
Write the criteria in your own terms. For exploited status, many teams look at the CISA Known Exploited Vulnerabilities catalog, which lists vulnerabilities with evidence of exploitation. See using the KEV catalog as a first patch priority.
Rules that keep the filter honest
- Every rule has an owner and a review date. Stale rules hide real risk.
- Track only is not ignore. Items stay visible and are re-evaluated when facts change, such as a new exploit or a change in exposure.
- Deduplicate before ticketing. One vulnerable package in ten repositories is one fix class, possibly ten pull requests, not ten investigations. See deduplicating findings across scanners.
- Record why. A short reason on every track only decision lets an auditor or a new engineer follow your logic.
- Escalation path. Anyone can promote a track only item to a ticket with a reason.
Inputs to the decision
- Exploitation evidence.
- Whether the vulnerable code is reachable in your use.
- Exposure of the asset.
- Whether a fixed version exists.
- Business criticality of the service.
None of these needs a score to apply. A simple yes or no on each is enough to place most findings.
Review the rules
Each quarter, sample the track only list and check whether any item should have been a ticket. If you find several, the rule is too loose. Also sample the ticket now list for findings that cost effort and added little, which suggests the rule is too tight.
Share the rules
Publish the intake rules where engineers can read them. People tolerate a filter they understand. A hidden filter looks like hidden risk.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the signals the check uses to place a finding. They map to the criteria in the intake table.
Where Safeguard fits
Safeguard's reachability analysis and policies can encode intake rules, so findings are sorted before they reach engineers.
Quick check
Is track only the same as accepting the risk?
No. Track only means no ticket yet, with the item still visible and reviewed. Accepted risk is a named decision with an owner and an expiry.
Who should write the intake rules?
Security and engineering together, so the rules reflect both risk and what work is realistic.
Sources
Last reviewed: 19 October 2026.
