Treat every security ticket that has sat untouched for a set period as needing one of three decisions: close it because it no longer applies, schedule the fix, or accept the risk in writing with an expiry date. Leaving it open "for now" is the fourth option, and it is the one that wrecks the backlog.
Why stale tickets matter
A backlog full of old items teaches the team that tickets are not real. Real problems hide among obsolete ones. Triage gets slower, reports look worse than reality, and new findings feel hopeless to add. Cleaning is not cosmetic. It restores trust in the list.
Set a staleness threshold
Pick an age with no activity that triggers review, such as a quarter. The exact number matters less than applying it consistently. Run a short review on a schedule, perhaps monthly, using a saved filter for tickets past the threshold.
The three decisions
Close. The finding no longer applies: the code was removed, the service retired, the dependency upgraded, or the scanner reported a false positive. Verify before closing. Add a one line reason. Closing without checking creates the exact distrust you are fighting.
Fix. The problem is real and should be addressed. Give it a size, an owner and a target sprint. If it cannot be scheduled within a reasonable window, you are really in the third option.
Accept. The problem is real, you will not fix it now, and you are choosing that deliberately. Move it to your risk or debt register with an owner and an expiry date, and close the ticket with a link. See what to record in a security debt register.
Rules that help
- A ticket with no owner after review gets an owner or gets decided on the spot.
- "Wait for upstream" is allowed only with a named upstream issue and a recheck date.
- No ticket can be reopened by a bot more than once without a person reading it.
- Duplicates are merged into one root cause ticket. Many findings often share a single cause.
Handle scanner findings differently
Automated findings regenerate. If you close one and the scanner reports it again next week, you have done nothing. Fix the cause, suppress with a reason in the tool, or adjust the rule. For dependency alerts, reachability information tells you which ones touch code you run, which helps you decide faster. The demo below shows a findings queue. Click through to see how items are grouped and prioritized.
Try it yourself
Click through it at your own pace, or open it full screen.
Announce the cleanup
Tell the team before you start. Explain the three decisions and the time limit. People are more cooperative when they know a mass close is not a punishment but a reset. Share the result: how many closed, fixed, accepted. Those numbers are an honest picture of where you stand.
Quick check
Is it acceptable to auto close tickets after a period of inactivity?
Not for security tickets. An automatic close hides real risk. Use the age as a trigger for a human decision.
What if the team cannot decide?
Escalate to whoever owns the product risk. Undecided tickets are effectively accepted, so make that acceptance explicit and dated.
Last reviewed: 19 October 2026.
