Rank security work by evidence of exploitation, whether the code is reachable and exposed, and how cheap the fix is. Reserve standing capacity for routine fixes so they stop competing with every feature, and take only the urgent ones off the top. Severity labels alone make poor sprint inputs.
Why the tradeoff feels unfair
A feature has a customer, a date, and a champion. A vulnerability fix has none of those until something goes wrong. That is why fixes lose arguments unless the team agrees rules in advance.
Use evidence, not labels
Three inputs make the conversation less subjective.
- Exploitation. CISA describes its Known Exploited Vulnerabilities catalog as an input to prioritization. A listing means exploitation has been observed.
- Probability. FIRST describes EPSS as an estimate of the chance a CVE is exploited in the next 30 days, meant to complement other inputs.
- Reachability. Is the vulnerable function called in your code, and is that path exposed to untrusted input?
A simple intake table
| Evidence | Sprint handling |
|---|---|
| Listed as exploited and reachable | Interrupt the sprint |
| Reachable, not known exploited, fix is a patch bump | Add to the current sprint |
| Not reachable | Schedule in the routine update slot, record the reason |
| Fix needs a major upgrade | Make it a roadmap item with its own estimate |
Standing capacity beats negotiation
Instead of arguing each ticket, agree a standing allocation, such as one slot per sprint for dependency updates and one owner on rotation. The number should come from your own history of how much update work arrives, not from a rule of thumb. When the slot is full, the overflow is visible and can be discussed with data.
Present it in the language of the roadmap
Executives and customers understand dates and commitments. Express security work as "this removes the risk before the support end date" or "this keeps our patching promise", and connect it to commitments already made.
Track whether it works
Two measures are enough: the age of the oldest open fix, and the number of exceptions past their expiry. If either grows for several sprints, the standing capacity is too small.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how findings are grouped and ordered. That ordering is the input to your sprint intake.
Quick check
Should we fix every critical finding immediately?
Not automatically. Check exploitation evidence and reachability first, then decide.
Who decides when security interrupts a sprint?
Agree the rule in advance: exploited and reachable interrupts, and the product owner confirms.
Safeguard's reachability analysis and vulnerability policies support this kind of ranking, and the free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
