Some years ago I closed over a thousand vulnerabilities in three months. It went on my resume. It still does.
The script that did it was maybe two hundred lines of Python. Regex patterns, some BeautifulSoup4 for parsing, search and replace at scale. The vulnerabilities were real — but the reason there were a thousand of them was massive code duplication. The same vulnerable pattern, copied across dozens of files, counted as a distinct finding each time. Fix the pattern, fix them all. Run the numbers. Report the number.
A thousand vulnerabilities. Ninety days. Impressive.
It was also, in every way that matters, meaningless. The underlying issue wasn't the vulnerable pattern. It was the culture that produced the code duplication, the resourcing decisions that made remediation a script instead of a refactor, and the reporting apparatus that turned a regex find-and-replace into a quarterly win for senior leadership.
I'm not embarrassed by it. I'm using it as evidence.
Coverage metrics — finding counts, closure rates, scan percentages, mean time to remediate — are not security measurements. They are activity measurements that have been relabeled as security measurements because security measurements are hard and activity measurements are easy.
A finding count tells you how many things a scanner flagged. It does not tell you whether any of them represent exploitable risk, whether any of them will be fixed, or whether the ones that get fixed are the ones that actually matter. A closure rate tells you how many tickets moved from open to closed. It does not tell you whether the underlying vulnerability was remediated, accepted with a documented rationale, or quietly suppressed because the finding was inconvenient.
The distinction matters because organizations optimize for what they measure. If you measure finding counts, you get organizations that manage finding counts. You get scanners tuned to produce impressive numbers. You get remediation velocity reports that look like progress. You get quarterly decks with upward-trending graphs that bear no relationship to the actual risk posture of the product.
This is not hypothetical. It is the default state of most enterprise security programs.
SAST alert fatigue, CI/CD notification spam, findings propagated across five platforms simultaneously — these are treated as tooling problems. They are not tooling problems. They are organizational problems wearing tooling's clothes.
In a well-run engineering organization, engineers own their tooling decisions. They decide what alerts, what thresholds are meaningful, what gets routed where, what constitutes a blocking finding versus a logged one. When that decision-making authority lives with the people who understand the codebase and the deployment context, the signal-to-noise problem is self-correcting. Engineers don't tolerate noise in their own environment.
The noise enters when that authority gets diffused. When a security team deploys tooling into engineering's environment without engineering's buy-in. When a compliance requirement mandates scan coverage without mandating that anyone is responsible for the output. When a platform team wires up integrations because the integrations were available, not because anyone thought carefully about what should happen when they fire.
And underneath all of that, typically, is a resourcing decision. The hyper-scaling mentality — grow headcount, ship faster, fix tech debt later — produces codebases where the cost of properly triaging and remediating findings is genuinely prohibitive. Not because the engineers can't do it. Because there aren't enough engineers, the ones that exist are stretched across too many priorities, and the organizational math on "fix this SAST finding properly" versus "close the ticket and move on" has a clear answer when you're three sprints behind on a roadmap that was committed to before the sprint started.
Burn the engineers out. They're replaceable. The finding count goes down either way.
At some point in a company's lifecycle — usually correlated with a funding round, a board composition change, or the arrival of a class of leadership that came up through finance rather than product — engineering starts getting evaluated on P&L metrics. CapEx and OpEx ratios. Headcount efficiency. Cost per feature delivered.
This is when security programs start generating reports instead of outcomes.
The executives and board members receiving those reports are not, in most cases, asking the right questions. Not because they're incapable, but because they don't know what the right questions are — and the people producing the reports have a strong incentive to keep it that way. A security team that reports "we closed 847 findings this quarter, a 34% improvement over last quarter" is not going to voluntarily add the footnote that 600 of those closures were duplicates of the same underlying issue, that 150 were marked won't-fix without documented rationale, and that the 12 critical findings from six months ago are still open because product won't allocate sprint capacity to address them.
The report goes up. The graph trends up. The box is checked. The risk compounds.
This isn't unique to security. It's the standard operating mode of organizations that have optimized for appearing to function rather than functioning. But it's particularly acute in security because the consequences of the gap between appearance and reality are not distributed evenly. The executives who approved the headcount decisions and the roadmap commitments that made remediation impossible are not the ones on call when the breach happens. Engineering is.
There is a version of a tech company that scales deliberately, maintains engineering quality, treats its technical staff as the core asset rather than the core cost, and builds something that sustains everyone involved. That company exists. It is not the dominant model.
The dominant model is: scale at whatever cost, capture market, exit. The top tier gets liquid. The engineers who built it get acqui-hired into something worse or laid off in the rationalization round. The security debt accrues throughout and gets handed to whoever buys the company as a surprise in due diligence.
Security programs inside that second model are not designed to reduce risk. They are designed to satisfy auditors, pass certifications, and produce the documentation required to check the compliance boxes that the acquirer's legal team will ask about. The finding counts and closure rates and coverage percentages exist to support that documentation. They are not lying to you accidentally. The incentive structure produces the lie deliberately.
Placing accountability where it belongs means being willing to say that out loud. The CISO who presents a board deck full of upward-trending metrics while knowing the critical findings are aging out in a backlog nobody owns is making a choice. The product leader who repeatedly deprioritizes security remediation in favor of feature delivery is making a choice. The executive team that funds tools without funding the headcount to act on the output is making a choice.
The numbers aren't lying. The people producing the numbers are choosing what to measure, how to frame it, and what to leave out — and they're doing it inside an incentive structure that rewards the appearance of progress over the reality of it.
If you're going to measure anything, measure outcomes, not activity.
Not findings opened — findings that represent exploitable risk in production, weighted by blast radius.
Not findings closed — findings closed with documented rationale: remediated, accepted with justification, or false positive with evidence.
Not scan coverage — the percentage of your actual attack surface that is instrumented with tooling someone is accountable for triaging.
Not mean time to remediate — the age distribution of open critical and high findings, and how many of them have been sitting in a backlog for more than one sprint cycle without movement.
These metrics are harder to produce. They require judgment calls, not just counts. They require someone to own the definition of "exploitable risk" and "blast radius" and enforce it consistently. They require the reporting chain to be willing to surface uncomfortable numbers instead of comfortable ones.
They also require an organization that actually wants to know whether it's secure, rather than one that wants to be able to say it is.
That's the prerequisite. Everything else is downstream of it.
A thousand vulnerabilities in ninety days. The script still works. The number still goes on the resume because in the environment it happened in, it was the right tool for the job — and shipping a number that leadership could process was the only way to create the space to do anything meaningful afterward.
But I know what it was. A well-dressed metric doing the job metrics are usually asked to do: making something complicated look simple enough for a dashboard.
Your scan numbers are lying to you. Not because the scanner is misconfigured. Because the system that produced them, reported them, and rewarded them was never designed to tell the truth. It was designed to tell a story. Until the incentive structure changes, the story is the product.