There's a stat from dinner in Cincinnati that stuck with me. The window between a vulnerability going public and someone exploiting it has collapsed from 60 days, to 7, to, increasingly, negative. Exploits are now showing up before the CVE does.
That changes the math. The patch-management playbook most organizations run assumes you have time after disclosure to assess, prioritize, and fix. That assumption doesn't hold anymore. And if detection has gotten this fast, the real question is why testing is still the bottleneck.
That question shaped most of the evening.
The room
We had security and delivery leaders from across financial services and technology, alongside Harness, Cursor, and Kong, talking through what it actually takes to govern software delivery at scale in 2026, at organizations running dozens of business units and hundreds of developers.
Confidence creep is the AI risk nobody's tracking
The most memorable moment of the night wasn't a slide. It was a demo.
One of the AppSec leaders in the room had built a Kahoot-style quiz app with an AI coding tool, for a security training summit. He'd found broken object-level access control and exposed AWS environment variables in it, serious enough to submit as bug bounties to the original vendor. Then he used the live vulnerabilities as the teaching exercise.
The lesson wasn't "AI writes insecure code," though it can. The real lesson was named directly in the room, confidence creep. A developer gets a few clean results from an AI tool, and the review muscle quietly atrophies, right as the tool becomes capable of touching more of the stack than ever. Non-technical "vibe coders" spinning up agents with zero code review made the same list of concerns.
The danger isn't that AI writes bad code. It's that trust in AI output outpaces the org's ability to verify it.
What actually moves the needle
Two ideas are worth stealing. First, on scope: if your org uses less than 70-90% of an open-source dependency's functionality, it's worth asking whether you should maintain that surface area at all, versus replacing it with something narrower or building it yourself. AI has made "build it yourself" cheaper, which helps with sprawl but introduces its own licensing and security literacy gaps.
Second, on culture. Not every governance win was technical. After a policy decision restricted corporate data access to Apple devices only, one company reimbursed employees who'd just bought Android phones. Small decision, clear signal, don't treat people like they're the threat model. Paired with a philosophy built on giving developers real choices and explaining the "why" before falling back on enforcement, it was a reminder that secure behavior sticks when it feels built for people, not against them.
The Part That's Actually Hard
The sharpest reframe of the night: governance isn't fundamentally an engineering problem. It's a risk-tolerance decision that belongs with leadership. Engineering's job starts after that threshold is set, automating enforcement to it, consistently, at scale.
That distinction is easy to agree with and hard to operationalize. At organizations with a dozen CIOs and hundreds of developers spread across them, "we'll handle governance case by case" isn't a philosophy, it's a guarantee of inconsistency. The teams furthest along had stopped writing policy into wikis and started writing it into tooling: dependency version currency rules, license compliance checks, reachability analysis to separate "there's a CVE in this library" from "this vulnerable path can actually be reached." Enforced automatically, not requested politely.
That's the difference between governance as approval theater and governance as a permission structure, rules specific enough to automate, and automated enough to hold under scale. Someone above engineering has to own the threshold decision, and that's the part most orgs in the room admitted they haven't nailed down.
The takeaway
Every thread from the evening led back to the same place: the constraint in modern software delivery isn't how fast you can write code. It's whether your org can absorb, verify, and govern change at the speed AI now lets you generate it.
The organizations that win this decade aren't generating the most code. They've turned governance into infrastructure, automated, evidence-producing, and fast enough that it never becomes the excuse to slow down.