Home / Knowledge hub / Vulnerability ageing
Knowledge hub
Vulnerability ageing
How long known findings have sat open, as a measure of fix speed.
What it means
Vulnerability ageing is the length of time a finding has been open, counted from when it was found or reported to now. It is usually shown in bands, such as under 30 days, 30 to 90 days and over 90 days, and split by severity.
A count tells you how many flaws are open. Age tells you how well your process works. A hundred findings, all under a week old, describes a healthy flow. A hundred findings that have all been open for a year describes a stuck one.
Why it matters
Time is the thing attackers are racing against. The longer a serious flaw is open, the more chances someone has to find and use it. Age also exposes problems that counts hide: unclear ownership, tickets without a due date, or fixes that always lose against feature work.
It is also easy to explain to leaders, customers and auditors. 'No critical finding is over 15 days old' is a clear statement that can be checked. It supports contract clauses and reporting to boards, where a raw number of findings invites more arguments than it settles.
How it shows up
Pick a start date and keep to it: the day the finding was confirmed, not the day someone triaged it. Set targets by severity and exposure, as CISA does for known exploited flaws with fixed due dates. Report the oldest open item, the share past target, and the average time to close (see mean time to remediate).
Watch for gaming. Closing and reopening tickets resets the clock. Marking items 'accepted' hides them. Splitting one issue into many shrinks the average. Link reports to the backlog and remediation targets, and confirm fixes with a retest before closing, so age stops only when the flaw does.
Questions people ask
Vulnerability ageing, answered
Is ageing the same as mean time to remediate?
Related, but different. Mean time to remediate looks at closed findings. Ageing also looks at those still open, which is where the risk is.
Use both.
What is a good target?
Standards rarely set one for everyone. Many teams use days for exploited flaws, a few weeks for high severity, and a few months for the rest.
Choose targets you can meet, publish them and report against them.
When does the clock start?
From when the finding was confirmed and reported, not from when someone got round to it. Starting later makes the numbers look better and the process look worse.
Be consistent.
What about accepted risks?
Report them separately with an owner and review date. Do not delete them from the age report, or old flaws will vanish from view.
See risk acceptance.
Should we show it to customers?
Some enterprise buyers ask for remediation times in security questionnaires. Stating your targets and your actual results builds more trust than a vague promise.
Only share what you can evidence.
Related
Terms that sit next to this one
Mean time to remediate
The average time from finding a vulnerability to fixing it.
Remediation SLA
The agreed time within which a finding of each severity must be fixed.
Vulnerability backlog
The growing list of known flaws a team has yet to fix.
Vulnerability management
The loop of finding, prioritising, fixing and checking the fix held.
Fix verification
Proving a fix works by repeating the original exploit against the new code.
How long has it been open?
A finding should stop ageing only when the flaw is closed. We re-run the exact exploit against the new code, so the clock stops on proof. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.