For the first time in 19 years, vulnerabilities are the DBIR's top attack vector
Stolen credentials used to be an attacker's main path into your systems. Now it's exploiting a vulnerability in your software.
For nineteen years, the Verizon Data Breach Investigations Report has told a remarkably consistent story about how attackers get in. Someone logged in. Stolen credentials, phished passwords, reused logins. Identity was the front door, and if you wanted to know where to spend your next security dollar, that was a reasonable place to look.
This year, that flipped.
Per Verizon, exploitation of vulnerabilities is now the most common initial access vector for breaches, at 31% of the dataset. Credential abuse, the long-running number one, dropped to 13%, down from 22% the year before. For the first time in the report's history, the most common first foothold is an unpatched, exploitable vulnerability.
I read this report every year. The top-line has always been some version of "the attacker had valid credentials." Seeing that change is a genuine watershed, and it deserves to be read carefully rather than turned into a bumper sticker.
Identity is not dead, of course. Verizon tracks identity-related access across several categories, and if you add phishing, credential abuse, and pretexting together, identity is still a very large share of incidents. Credentials still show up across a big portion of the full attack chain, not just the first step.
But vulnerability exploitation is now the number one single initial access vector, and it overtook credential abuse to get there. That’s the big shift for this industry.
Remediation is going backwards
The headline is the vector change, but the part that keeps CISOs up at night is underneath it.
Verizon found that only 26% of the vulnerabilities on CISA's Known Exploited Vulnerabilities list were fully remediated by organizations last year. A year earlier that number was 38%. Remediation did not hold steady. It got worse. On top of that, the median time to fully close one of these went up to 43 days, roughly two weeks longer than the year before.
Put those two trends next to each other. Attackers are getting faster, using AI to compress the gap between a vulnerability becoming public and it being actively exploited, in some cases to negative territory, where exploitation is happening before a patch even exists. Defenders are getting slower. The queue is refilling faster than most teams can drain it.
And the queue was already enormous. Ask a CISO how many open findings sit in their backlog and the number lands in the hundreds of thousands. Edgescan found that 45% of the vulnerabilities enterprises discover are still unpatched a year later, and roughly one in six of those is high or critical. The median application fix took 74 days. KEV is only the sliver already being exploited, and teams are losing ground on even that.
Why this is a software supply chain story
Here is what the vector change means in practice. When the most common way in is an exploitable vulnerability, the question stops being "did someone steal a credential" and becomes "do we even know if this vulnerability is in our software, and where."
For most organizations, that is a hard question, because most of the exploitable surface does not live in the code they wrote. It lives in the dependencies they pulled in, and more specifically in the transitive dependencies, the packages their packages depend on, three and four layers down. Standard scanning reads the top of that tree and calls it coverage. The real risk is usually deeper, in a component nobody on the team chose or has ever heard of.
You cannot remediate what you cannot see. And when a zero-day drops, you cannot move fast if the first thing you have to do is spend a week figuring out whether you are even affected.
What to do about it
The teams that will come out of this shift ahead are the ones that stop treating vulnerability management as a scan-time, count-the-CVEs activity and start treating it as a continuous function.
That means a few concrete things. Full visibility built from source, including the transitive layer, so you actually know what is in your software. Prioritization by real reachability and exploitability instead of raw CVE counts, so your limited hours go to the handful of issues that can actually hurt you. And remediation you can trust, ideally automated, so closing a finding does not take 43 days.
The CSA, SANS, and OWASP briefing on the AI vulnerability storm calls this a permanent VulnOps function, staffed and automated like DevOps and built to run continuously. It requires a living knowledge graph of your entire software estate, updated in real time, so that when the next vulnerability lands, the answer to "are we exposed, and where" already exists.
For what it is worth, that is the architecture we built Kusari around. Reachability, a graph of the full dependency tree from source, and autonomous remediation. We built it that way because the direction was obvious, well before this particular headline. When the attack surface moves into the software supply chain, defense has to move with it.
The Verizon DBIR is a lagging indicator by design. It measures what already happened. This year it caught up to something a lot of us have been watching arrive for a while. The vector changed. The smart move is to change with it.
Want the deeper playbook? Our Mythos Executive Threat Briefing maps the AI-accelerated threat to a specific set of actions, from this week to twelve months out. Read the briefing.