The off-the-shelf player in this space (structured red-team search) is probably https://github.com/usestrix/strix (no affiliation). But any frontier model, if you tell it "here's how the authentication system works, go looking for bugs" will probably do a good job.

This whole vulnerability thing is the first time I'm really feeling like AI tech is a shakedown more than a value-add to my job. So I have to take multiple different frontier models, burn tokens constantly scanning all my code bases with complicated harnesses that eat tokens by the hundreds of millions, burn tokens cross-checking the cross-checks of the cross-checks in some eight-phase process made out of non-deterministic agents, to feed them into another multi-stage multi-agent pipeline to try to turn them into actionable vulnerabilities, and if I ever stop or slow down this process I can expect to be explaining why I did that in a court case someday.

That's ridiculous.

And yet, presumably, the vulns are real.

What are businesses supposed to actually do with this?

What happens to the whole AI value proposition when instead of it being a way to pump out lines of code for crazy cheap it becomes a way for each line of code to become vastly more expensive than it was before?

I can't help but notice that in the section headed "What it costs" the $ symbol is conspicuously absent. I would definitely like to hear a much more concrete number on some sort of per-100k-line basis or something. I know that per-line isn't great but at least it would be something.

Maybe if the models get a lot better we wouldn't need all this cross-checking. And maybe they'd write fewer vulnerabilities for the other models to laboriously and expensively figure out in the first place.

But good gracious does this sound like the AI industry just asking for you to hand the a blank check, because it sure would be a shame if something happened to your code base, wouldn't it?

I don't have a solution to this. This is stricly a cri de coeur.

Except maybe to say that if this is going to be the way in the future that it becomes vastly, vastly more important to work out how to write more secure code from the very beginning. We've certainly been trending this way for the last few decades, hand-wringing aside security has gotten a lot better than it used to be, it's just the world has gotten more complicated and harsh as well so it doesn't always look like it. But it takes over a decade for things like "use parameters in your SQL query instead of concatenation" to go from some crazy guy's idea in some obscure open source package somewhere to common practice that can almost be counted on. That loop is going to have to close much faster and there's a lot of things that are barely registering on people's radars, like, the *at APIs for files (openat, etc.) need to be the default much, much sooner than their current trajectory has them on.

VISA open sourced an expense-to-run harness they developed under glasswing, and I used that as the basis of a skill that I've found to be pretty effective with Claude Code: https://github.com/atgreen/secscan-skill

If I was doing this at scale, I'd be looking at two features in particular. Cached input tokens - leveraging the LLM's token cache to get a 10:1 cost advantage, and batch tokens, 2:1 cost saving.

The benefits of doing your own harness here is that you get to explicitly program around those specific things to optimize cost. And they both heavily benefit you in the way that these sorts of jobs work - at least for the hunt side of things.

TLDR - context management is pretty important for cost management when you're doing something repetitive in bulk.