Rarely. A deadline to reach zero open findings creates a cliff: effort bunches before the date, and items get reclassified, excepted, or closed without verification to hit the line. Set a goal on the trend of exposure and the age of the oldest high risk item, and review it on a steady cadence.
Why the cliff happens
A deadline plus a count gives people two levers. They can do the work, or they can change what counts. Goodhart's law predicts the second lever gets pulled when the first is expensive. Campbell's law makes the same point: the more a quantitative indicator drives decisions, the more it invites pressure to distort the process it monitors.
In a vulnerability backlog the second lever is easy. Severity can be argued down, status can move to accepted, scope can shrink, and tickets can be merged.
Signs your burn down is bending
- A sharp drop in open items in the last week before the date, with no matching deployments.
- A matching rise in exceptions or accepted risk.
- Findings that reappear after the date, because the underlying fix never shipped.
- Quiet changes to which repositories or environments are in scope.
If you see two or more, sample the closed items before you celebrate.
Better ways to set a backlog goal
| Instead of | Try | Why |
|---|---|---|
| Zero open by a date | Age of the oldest open high risk item trending down | Targets the hard items, not the easy ones |
| Count closed per month | Share of exploited or reachable issues past the agreed window | Aims at risk |
| One deadline for everything | Staged goals by service tier | Fits capacity to importance |
| Report only open items | Report open, excepted, and reopened side by side | Makes trade offs visible |
DORA's guidance warns against making a metric a goal in a broad statement, such as telling every application to meet a number by year end, because it increases the chance teams game it. It also suggests choosing several metrics with some tension between them.
A steadier plan
- Tier services by importance and exposure. Start with the top tier.
- Set the first goal on the exposure window for exploited or reachable issues in that tier.
- Add a counter metric: exceptions past expiry and reopen rate.
- Review monthly, not just at the deadline, so no cliff forms.
- Verify a sample of closed items in production at each review.
If leadership wants a date, give one for a milestone that is hard to fake, such as all exploited issues in the top tier fixed or formally excepted with an expiry.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings change over time, and notice that new issues keep arriving, which is why zero is a moving target.
Safeguard's continuous monitoring keeps scanning as new advisories appear, which is a reason to set goals on trend and exposure rather than on zero. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Can the backlog ever really reach zero?
New advisories arrive constantly, so a count of zero is brief at best. Aim for a short exposure window for what matters.
What is a safe alternative to a deadline?
A steady review cadence with goals on exposure window and oldest item age, plus sampling checks on closed items.
Sources
- Goodhart's law (Wikipedia)
- Campbell's law (Wikipedia)
- DORA, software delivery performance metrics and common pitfalls
Last reviewed: 19 October 2026.
