Here's a number that should reorganize your roadmap: AI-assisted fuzzing pulled hundreds of distinct bugs out of Firefox — one of the most scrutinized, most-fuzzed, most security-mature codebases on the planet. Not a hobby project. Not a startup's first commit. A codebase that has had professional fuzzing infrastructure, paid researchers, and a bug bounty pointed at it for years. And a machine still walked in and found more.
The lazy read is "wow, AI is good at security now." The operator read is colder. If AI can find that much in code that has already been picked over by experts, then the latent vulnerability count in your repos — the ones that have had a fraction of that attention — is much higher than your last pentest report implies. The bugs were always there. The cost of finding them just dropped through the floor.
That single fact has two ends, and a security leader has to plan for both at once.
The two-sided problem nobody wants to say out loud
Offense and defense are the same capability viewed from opposite sides of a disclosure timeline. The exact technique that lets your team surface a heap overflow before shipping is the technique that lets an adversary surface it after you've shipped. There is no version of this where the tooling helps defenders and politely declines to help attackers. It's a general-purpose capability, and capabilities don't take sides.
So the strategic question isn't "should we adopt this." That's already decided for you — your adversaries are adopting it whether you do or not. The question is the order of operations. Do you find your bugs first, on your schedule, in your CI pipeline where the only consequence is a failed build? Or do you find them second, in a CVE someone else filed, on a clock you don't control?
I want both ends handled deliberately. On offense: get AI-assisted SAST and fuzzing into the pipeline now. On defense: assume the time-to-exploit for any disclosed vulnerability is collapsing, and re-price your patch SLAs accordingly. Those are different programs with different owners, and most shops are doing neither.
Offense: run the machine against yourself, on purpose
The honest truth about traditional SAST is that it drowns teams in findings that are technically true and operationally useless. Developers learned to ignore it, and you can't entirely blame them. What's different about the current generation of AI-assisted analysis is that it reasons about reachability and exploit conditions, not just pattern matches — and coverage-guided fuzzing with an AI generating harnesses gets into the parsers, deserializers, and input-handling paths where the genuinely dangerous bugs live.
If you own DevOps as well as security — I do — this is a platform decision, not a tooling purchase. A few principles I'd hold to:
- It runs in the pipeline, not in a quarterly engagement. The value is continuous. A bug found at PR time costs a code review comment. The same bug found in production costs an incident bridge.
- Triage is the actual product. An AI that generates 271 findings and zero prioritization just moved the bottleneck from discovery to the security team's inbox. Demand exploitability scoring and dedupe, and measure the tool on signal, not raw count.
- Mind what you feed it. The moment "AI reads your repos" stops being a headline about Firefox and starts being your own proprietary code going to a third-party endpoint, you've created a data-governance question. In regulated environments, where the model runs and what it retains is a control, not a footnote. I want self-hosted or contractually-bounded analysis for anything touching sensitive paths.
Done right, you've turned the scary headline into a competitive advantage: you are now finding your bugs at the cheapest possible point in their lifecycle.
Defense: the disclosure-to-exploit window is closing
Here's the part that changes the math even for teams who don't touch a single AI security tool. The historical comfort blanket in vulnerability management was the gap between disclosure and weaponization. A CVE dropped, and you often had days — sometimes weeks — before a reliable public exploit existed. That gap was the slack in everyone's patch SLA. It's why "patch criticals in 30 days" felt defensible.
AI compresses that gap from the attacker's side. If a model can read a patch diff and reason its way to a working exploit, then "we have a few days" becomes "we have hours." N-day vulnerabilities start to behave like zero-days. And the uncomfortable implication is that publishing the fix becomes the starting gun for the attack, because the diff itself is the tip-off about where the bug was.
So the patch-SLA conversation has to get more honest and more tiered. A flat "criticals in 30 days" policy was always a fiction; now it's a dangerous one. What I'd actually plan around:
- Separate your clock by exposure. Internet-facing, unauthenticated, on a system handling sensitive data is a different SLA than an internal service behind three layers of network control. Treat them differently or you'll burn your fast lane on things that don't need it.
- Buy time you don't have with compensating controls. When patch-in-hours isn't physically possible, a WAF rule, a feature flag kill switch, or network segmentation is the bridge. The ability to deploy a virtual patch fast is now a first-class capability, not a fallback.
- Instrument for exploitation, not just for known-vulnerable. If the time-to-exploit is shrinking, detection has to assume some bugs will be hit before they're patched. Behavioral detection on the exploit's effects outlasts any single CVE.
Why this lands harder in fintech
When you sit behind 1,500+ financial institutions, your dependency tree is your customers' dependency tree. A vulnerability in a library you ship propagates downstream into regulated environments, and every one of those institutions has examiners who will eventually ask how fast you found it and how fast you fixed it. "We were within our 30-day window" is not going to age well as an answer when the exploit was live on day one.
The reframe I keep coming back to: AI-assisted vulnerability discovery isn't a threat to manage or a tool to evaluate. It's a permanent change in the cost structure of finding bugs, and that change benefits whoever moves first. The advantage doesn't go to the side with the better technology — both sides will have the same technology. It goes to the side that found the bug first.
So here's the challenge. Pull up your last vulnerability scan and your patch-SLA policy, side by side. Ask one question of each: would this survive contact with an adversary who can read diffs and write exploits at machine speed? If the honest answer is no, you already know what's actually on your roadmap. The machine that found 271 bugs in Firefox is for hire by both teams. Make sure yours is the one that hired it first.
