Security vulnerability trends

Security vulnerability trends measure how the volume, severity, and age of open vulnerabilities change across an estate over time. A snapshot count tells you how many open vulnerabilities exist today. The trend tells you whether that number is rising or falling, and whether the mix is shifting towards more severe or older issues. If 50 new vulnerabilities are discovered in a month and only 30 are remediated, the net trend is plus 20, and risk is building even though no single day looks alarming.

The metric matters because point-in-time counts are misleading on their own. A team can fix vulnerabilities at a healthy rate and still fall behind if new ones arrive faster. Equally, a high open count can be improving fast if remediation is outpacing discovery. Only the trend reveals which of those two situations you are actually in.

Severity weighting is central. One critical, internet-facing, exploitable vulnerability matters far more than a hundred low-severity issues on an isolated internal service. A useful trend weights by severity and exposure so the line reflects real risk rather than a raw count that treats every finding as equal.

The core of the trend is the net change per period: new vulnerabilities introduced minus vulnerabilities remediated. A positive net means the backlog is growing. The real diagnostic value comes from decomposing both sides of that equation and watching the inputs that drive each one.

1. 1

   New vulnerabilities introduced

   The count of vulnerabilities first discovered in the period, whether from scanning, new disclosures against existing dependencies, or newly deployed code. Rising introduction usually points to dependency drift or expanding attack surface.

2. 2

   Vulnerabilities remediated

   The count of vulnerabilities closed in the period through patching, configuration changes, or removing the affected component. This is the direct output of the remediation engine.

3. 3

   Net change

   Introduced minus remediated. A persistent positive net is the clearest single signal that risk is accumulating and remediation capacity is not keeping pace with discovery.

4. 4

   Mean time to remediate

   The average age at which vulnerabilities are closed, banded by severity. A rising remediation time means findings are sitting open longer, which lengthens the exposure window regardless of the headline count.

5. 5

   Ageing backlog

   The count of open vulnerabilities older than their severity-appropriate fix target. A growing aged backlog is where the most exploitable risk tends to concentrate.

Report these inputs on a rolling basis, severity by severity, so a single critical finding cannot be averaged away by many trivial ones. Most teams plot introduced and remediated as two lines on the same axis. When the remediation line sits above the introduction line, the backlog shrinks. When it sits below, the backlog grows, and the gap between the lines is the rate at which risk is compounding.

A metric tree decomposes the net vulnerability trend into its discovery side and its remediation side, then traces each back to the operational levers that move it. This turns a worrying line on a chart into a clear statement of what to fix and who owns it.

The first level splits the trend into new vulnerabilities introduced and vulnerabilities remediated. The introduction branch decomposes into dependency drift, new code shipped, and expanding infrastructure footprint. The remediation branch decomposes into patch throughput, the share of fixes that are automated, and the friction of getting a fix deployed. The ageing backlog hangs off both, because it is what is left when remediation cannot keep up.

The tree makes the diagnosis precise. A worsening trend driven by a surge in new dependencies needs a different response from one driven by a remediation team that has lost capacity. One is a supply-chain and intake problem, the other is a throughput problem, and confusing the two wastes effort.

There is no universal target count, because estates differ enormously in size and exposure. The benchmarks worth holding teams to are about remediation windows by severity and the direction of the net trend, since those translate directly to how long real risk stays open.

The single most telling benchmark is whether the remediation line sits above the introduction line over a rolling quarter. A team that consistently closes more than it discovers is reducing risk over time even from a high starting count. A team where introduction outruns remediation is accumulating risk no matter how impressive the absolute number of fixes looks in isolation.

Improving the trend means either slowing the rate at which vulnerabilities arrive or speeding the rate at which they are fixed, and ideally both. The most durable gains come from the introduction side, because preventing a vulnerability is cheaper than chasing it once it is in production.

The metric tree approach starts by asking which branch is driving the trend. If introduction is surging, the lever is upstream in dependency management and pipeline checks. If remediation has fallen behind, the lever is throughput and automation. Pushing harder on the branch that is already healthy moves the trend very little.

KPI Tree lets you connect each branch to the team that owns it. Application teams own the code and dependencies that drive introduction. Platform teams own the infrastructure footprint. The security function owns triage and prioritisation. With RACI ownership on each node and a push to the accountable owner when their branch starts to worsen, an adverse trend reaches the person who can act on it while it is still small, and the verified impact loop confirms whether the intervention actually bent the line.

1. 1

   Watching the count instead of the trend

   A single snapshot cannot tell you whether risk is rising or falling. A high count that is shrinking is healthier than a low count that is growing. Always read the direction of travel, not the level.

2. 2

   Treating all severities as equal

   A blended count lets a hundred low-severity findings outweigh one critical, exploitable one. Weight by severity and exposure so the trend reflects real risk, not raw volume.

3. 3

   Ignoring the introduction side

   Focusing only on how fast vulnerabilities are fixed misses the question of why so many keep appearing. A worsening trend is often an intake problem that no amount of faster patching will solve.

4. 4

   Hiding the aged backlog

   Old, unfixed findings are where exploitable risk concentrates, yet they are easy to bury in a total. Track findings past their fix target as a separate line so they cannot be averaged away.

5. 5

   Closing findings without remediating

   Marking a finding resolved without actually fixing or risk-accepting it flatters the remediation line while leaving the exposure in place. Closure must mean fixed, removed, or formally accepted with an owner.