A few weeks ago I stood up in front of about 75 CISOs after dinner and clay shooting, and I opened with two questions. Who's ever been responsible for the security of software in their organisation? Hands went up, a lot of them. Then: keep your hand up if, at the time, you genuinely felt confident you weren't putting critical vulnerabilities into production.

Most hands went down.

I've asked some version of that question to a few rooms now, and the second count never matches the first. That gap is the whole reason Cytix exists, and it's worth sitting with for a second rather than rushing past it, because everything else I'm about to say is really just an attempt to explain why it exists and what to do about it.

Application Security Has Always Been Technical

Application security has always been a technical function, and I think that's mostly right. Supply chain, CI/CD, code review, this stuff is genuinely hard and it needs specialists. But there's a business side to it that keeps getting missed, and the way I've found to explain it is through QA, of all things.

QA catches functional bugs. The checkout's broken, the system's down, something visibly stopped working. That's a broken arm. You can see it, it hurts immediately, and because it hurts immediately we built real processes around it years ago: QA gates, change management, CAB meetings. Nobody had to be talked into caring about those.

Security Bugs Don't Work Like That

Security bugs don't work like that. They're what I'd call a benign condition. You don't feel them. If a critical vulnerability landed in your production environment this morning, you'd carry on with your day exactly as normal, right up until you didn't. And because it doesn't hurt immediately, we never built the same muscle for connecting security decisions back to the business the way we did for functional ones.

So try the uncomfortable version of the same question. If I asked you today to prove that every meaningful software change in your business had been assessed, validated and evidenced, could you actually do it? Most people I put that to can't. I'm not going to answer it for you either.

The Old Model: Manual and Rigid

Some organisations solved this a long time ago, because they had no choice. My co-founder Tom was seconded into a large bank early in his career, the kind of bank that has to plan for nation-state attacks as a matter of course, where being "agile" means something quite different from what most of us mean by it. He sat with seven or eight other pen testers in the basement of the bank's technical headquarters, and the process for making a change was extraordinary: developers wrote it, it went through a project manager, requirements got documented, a meeting was booked with a security clinic, that meeting got documented too, a risk decision was made and recorded, and then, often literally, someone carried it downstairs for a pen test.

It worked. For what that bank was up against and the resources it had, it held. But it was slow, entirely manual, and there's no version of that process that survives contact with a modern engineering team, let alone whatever's coming next.

Everything Is Accelerating

Because things are changing, and not in one direction. Developers can ship code somewhere between three and a hundred times faster than they could a few years back, which sounds abstract until you think about what's actually generating that code. I've started calling it shadow development, borrowing from shadow IT: the same way company data used to end up on devices nobody in the business knew existed, we now have agents writing and shipping code faster than the tickets and review gates built to catch it can keep pace. Change is happening that nobody can see happening.

At the same time the window's closing. There's a site, zerodayclock.com, that tracks time-to-exploitation across tens of thousands of CVEs in real time, and it's gone from around 170 days a few years ago to under 48 hours now. The gap between a vulnerability existing and it being exploited has more or less collapsed.

Silent Killers: The Semantic Vulnerabilities

And the nature of what's breaking is changing too, which is the one I think people underestimate. Humans writing thousands of lines of code a day make simple mistakes, SQL injection, cross-site scripting, the syntactic stuff our scanners are genuinely good at catching. AI doesn't seem to make those same mistakes nearly as often, and that gets waved around as proof that AI writes safer code. It doesn't, not quite. There's a second category, the semantic vulnerabilities, that don't look like anything's wrong at all. Nothing crashes. No error gets thrown. The system does precisely what it was designed to do, it's just been nudged, by a small change, into doing the wrong thing. A business logic flaw. An authorisation check that quietly stopped applying. I call these the silent killers, because your tooling won't tell you you've introduced one. It isn't broken. It's just been abused by design.

The Uncomfortable Reality

Put those three together and you get somewhere uncomfortable: real pain is coming, and if we carry on the way we are, we won't find these issues before someone else does. The choice is really just whether we wait for that pain to force the process into existence, the way it did for QA, or whether we build it now, ahead of the fact.

What We Actually Do About It

Here's what Cytix does about it. It comes down to four things, and none of them are especially glamorous on their own. We sit on your ticketing system and your repos so we know what a team said they'd change and what actually changed, down to the code. Not the version someone wrote in a ticket description. From there we ask two questions that sound simple and mostly aren't: should security even care about this, and if so, why. That second question gets answered with a lightweight threat model against the specific change, not a generic one. Then comes the bit that gets all the attention, agentic testing. This checks whether the risks we flagged actually got introduced. Everything gets written down, including, maybe especially, the times we decide a change is benign. Why did security not care about this one? That reasoning sits on record. Because the regulatory slack around AI-generated code isn't going to last, and when it tightens, having that trail already built is going to matter a lot more than having a faster scanner.

What This Buys You

What that buys you is control, mostly. You actually understand what's changing, you can make a real decision about risk instead of guessing, and you're not relying on hope that the PR got looked at properly. But the bit I think matters more, and the bit that seems to land hardest with the security leaders I talk to, is that it unlocks the business. Every one of them is under pressure to let developers ship faster. Put real governance around change and you can go back and say: go on, build more, we've got this, we'll flag it if we start to struggle. You stop being the department that says no by default and start being the one that makes yes possible. Honestly, the single biggest benefit of Cytix at the moment isn't a feature at all. It's relief. The fear of what all this AI-generated volume is doing to their risk posture, finally addressed. It's the shift from hoping the right things are being tested to actually knowing they are.

Where We Stand

We're three years old. We've gone from twenty-person engineering teams up to some of the largest enterprises in the world, and we sit inside NCC Group's own continuous application security offering, alongside work with KPMG and Bugcrowd. We're a small UK company and I'm not going to pretend otherwise, but we're enterprise-ready, and that's not a hedge.

The Path Forward

This problem is only going to get bigger, and AI is making every part of it worse before it makes any of it better: more code, faster, with less time between a mistake happening and someone finding it. But it doesn't have to turn into the problem the hard way. We built the connective tissue between QA and the business decades ago because functional bugs hurt enough, immediately enough, to force it. Security never got that same treatment, because it doesn't hurt until it does.

The Final Question

So that's really the only question left. Do we put that governance in now, on our own terms, or do we wait for a benign condition to turn into a real one and let it force our hand, the way it always eventually does.