Burn down old SAST findings with a fixed slice of every sprint, usually a small share of capacity, ordered by severity first and by how often the code changes second. Track the unchanged count weekly. Slow, steady and visible beats a one time security sprint that never repeats.
Start from the right list
After a baseline, the backlog holds findings nobody chose. Before fixing any, shrink it honestly.
- Remove findings in code that is dead, generated or vendored.
- Confirm or dismiss the top severity items, with a reason each.
- Group findings by root cause. One unsafe helper function may account for dozens of alerts.
Many alerts vanish at step one and three. CVSS is a reminder of why severity alone is not enough: the specification says the base score reflects intrinsic characteristics and assumes a reasonable worst case across deployments, and that environmental metrics exist so an organisation can adjust for the importance of the asset and for mitigations. Your own context should reorder the list.
Four step plan
| Step | What | Output |
|---|---|---|
| 1. Cleanse | Exclude dead and generated code, dismiss clear false positives | Smaller honest list |
| 2. Rank | Severity, internet exposure, data sensitivity, code churn | Top 20 by real risk |
| 3. Budget | Reserve a fixed share of each sprint | Predictable capacity |
| 4. Report | Weekly trend of open, new and fixed | A line that goes down |
How to choose the budget
Ask the team what they can absorb without moving release dates. Ten to fifteen percent of a sprint is a common starting point, but treat that as a guess to adjust. A smaller budget that survives is better than a large one that gets cut in the first crunch.
Where to look first
Code that changes often is where a fix pays twice: it removes the finding and the team touches that file anyway. Pair each fix with a pull request that is already open nearby. Fix by pattern, not by instance: add a safe wrapper, then replace calls across the codebase in one change.
What to avoid
- A heroic security week. It burns people out and the backlog regrows.
- Closing alerts to hit a number. Measure fixed, not closed.
- Letting the baseline absorb new findings. See failing only on new findings.
Try it yourself
Open the demo and sort findings the way you would for a sprint plan.
Click through it at your own pace, or open it full screen.
One factual note on Safeguard
Safeguard offers autonomous remediation with fix pull requests, which is off by default and starts with every category on Manual. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
How do I know the burn down is working?
The unchanged count falls week over week while the new count stays near zero. If new findings keep rising, fix the intake first.
Should every old finding be fixed?
No. Some are false positives, some are in code being retired, and some are low value. Record the decision for each and move on.
Sources
Last reviewed: 19 October 2026.
