There used to be a fairly standard Security Organization paradigm. Infra/Cloud/Network team, Incident Response team, often an Architecture/consulting team, AppSec team, couple of TPMs, a Director or two that ran everything, some Managers to take care of the talent, a CISO that talked to the board.

It no longer gets the job done. Let's panic for a moment.

Take your time.

OK so what now? Now we have to accept a few conflicting things as being equally true, at least for a while. This list is adding a lot of complexity to current operations, but change brings complexity before it brings benefits. Lean into it.

• Your entire company is used to interacting with your security org the way it existed yesterday, and you have to keep supporting that while you change everything.
• AI rollout is already happening and no one is asking for permission or telling you they did it.
• Your engineers are currently integrating agentic systems into everything.
• Your engineering managers are currently integrating agentic systems into everything.
• Your marketing department is currently integrating agentic systems into everything.
• Your finance department etc etc
• We need to define new models, and we need to dig up old ones that worked in times of higher uncertainty and more variable impact.
• We cannot solve this by applying the same tools attackers will be using in an asymmetric manner. In either direction. Either we spend a lot and they still overrun us, or we spend a LOT and go out of business.

That last bullet gets to why some of us are doing the Kermit-panic bit from above and the rest of us should be. The paradigm shift we're experiencing is incredibly more advantageous to the attacker than it is to the defender. Assuming equal access to and time with the same tool sets, defenders are gonna lose. That's OK though, we don't have let the field be even.

Defenders set the starting conditions.

The same core positional strengths and weaknesses that have always been true, continue to be true now. Defenders set the field. Defenders get as much practice time as they want (as the company will let them have). Defenders determine the date the competition starts. Conversely, once defenders say "ok, we're live" then every single advantage of initiative goes to the attackers, and the new reality of AI-assisted hacking is incredibly advantageous here.

This is about going back to fundamentals and first principles. VulnOps is a new Security Engineering team made up of AppSec, InfraSec, SRE, and AI engineers. VulnOps operates a constantly expanding and contracting pool of hostile environments where changes to production code are exposed to attack before release. This will lead to a constant flow of information back to Engineering and Product orgs about findings, mitigations, advisories, blockers, etc. A useful model for this is that instead of Engineering having a release date, Engineering will have a release intent. Engineering releases not into production, but into Staging (we're bringing it back). The actual release date will happen at the end of the Staging process, which could be same day, or could be weeks away depending on findings, fix timelines, and business determinations of risk balancing.

• VulnOps has a role based around the following pursuits:
• Owning the gate from Staging to Production.
• Determining, on a rolling basis, the expected cook time in Staging.
• Managing a set of AI systems that are trying to break into the systems in Staging.
• Maintaining some really informative and real time dashboarding about what's happened to a release in Staging, what's still ongoing, and what tickets have generated
• Maintaining communications with Engineering about what the AI jackals in Staging have done so far, and what the timeline is for patches/adaptations
• Yes, that means that "Staging" actually means several iterations of Staging as changes deploy to adapt to what just happened in the last Staging, and indeed, may still be happening there.

You're still going to have every single piece of the old security org model in place. Those functions didn't stop or become less important. In fact, some of them are more important now than before. Incident Response is going to be dealing with truly gnarly incidents because the code that shipped to production was significantly more hardened than what they were seeing last year. Your architecture team is going to be working very hard to turn the changes they see necessary into structural, foundational improvements in how Engineering produces product. Your AppSec and InfraSec teams are going to be a primary source of achieving shorter bake times in Staging, and are going to find their time/advice highly in demand. They're all going to be existing around and in support of VulnOps though. 

Interestingly, VulnOps is going to be one of the first Security Engineering efforts where metrics are not only useful but more likely to be useful than damaging. This is because the Staging system constitutes a well-bounded black box, and you can metric on the inputs and outputs without trying to muddle with the how. Some potential measurements:

• Average release time in Staging (sliced by release size).
• Token spend in Staging compared to token spend in development (oh boy is that one a potential grenade, there are so many potential ratios here where someone is going to be embarrassed or mad).
• Post-release security bugs count/severity.
• Releases that left Staging early that did/didn't generate production issues.

A perhaps surprising note: this is not a smaller Security org. It's probably a 20-40% larger one. This is of course a major challenge, but it's going to be a challenge for everyone across org types and industries. The reality is that AI adds a lot of velocity, but that velocity adds a lot of turbulence, and turbulence requires humans to manage it.