I know Mastodon hates LLM's and AI. So here goes!

I recently got access to trusted access of cyber capabilities of both openai and anthropic, which also allows you to weaponize security vulnerabilities.

The speed at which these parrots can find bugs and be creative enough to exploit them is staggering.

I recently pointed an LLM at an kernel fix that was reachable by an unprivileged namespace on Debian and it fully weaponized it, without too much me prompting it in the right direction, in about 7-9 hours.

I don't think open-source and companies will know what's coming for them once these open-source weight models will have broader reach and get better at exploiting vulnerabilities on a massive scale as anyone can access them.

The bottom line I think is, you cannot patch faster than the attackers can easily chain all kinds of vulnerabilities together and just move laterally on an incredibly fast pace.

I've started reporting vulnerabilities to all kinds of projects and the majority have trouble or patching issues found. There's not enough maintainers, or there's simply none anymore.

I've been getting quite worried about what our future will look like for data privacy. I think outright not running an LLM over your codebase to find critical security vulnerabilities because of your moral stance will keep us more insecure.

Please run an LLM over your code base if it's internet facing or something critical, we thank you!

Can't wait for the discussions on this!

Replying to @⁨drwhax@infosec.exchange⁩

@drwhax I think we need a bit of nuance here.

As much as I am no fan of LLMs, I can see the value of running them over one's own codebase in order to find vulnerabilities.

But I remain unconvinced that vibe-coded fixes are a good idea, or ever will be. I think this needs to be clearly said.

The reason is that these are fundamentally different problems.

Replying to @⁨rysiek@mstdn.social⁩

@drwhax finding vulnerabilities can be stochastic because it has a very clear and effective verification function: either the exploit works or it does not. Exploit code can be messy and convoluted, as it is not going to be maintained after the vulnerability is fixed.

Vibe-coding fixes does not have that kind of verification function: the fix must not only close the specific vulnerability, but *also* not introduce new ones or re-introduce old ones, and it has to be maintainable in the future.

Replying to @⁨rysiek@mstdn.social⁩

@drwhax and just to drop some data on vibe-coded software quality:
faros.ai/blog/ai-acceleration-

The report tries to be very "AI"-positive. But the numbers don't lie: +861% code churn, +242% incidents per PR, +54% bugs per developer.

www.faros.aiThe AI Engineering Report 2026: The AI Acceleration Whiplash - Ten TakeawaysWhat two years of telemetry data from 22,000 developers reveals about AI's real impact on developer productivity, code quality, and business risk in 2026.

Replying to @⁨drwhax@infosec.exchange⁩

@drwhax the problem is this works better for certain tasks (finding vulnerabilities) and much worse for other tasks (vibe-coding) because of the shape of these tasks.

"Human in the loop" is not the get-out-of-LLM-problems-free card people try to pretend it is.

Human in the loop works for vulnerability findings because there is a reliable way of verifying the finding. It clearly does not work well for vibe-coding at all because there is no such reliable way of verifying code correctness.

Replying to @⁨drwhax@infosec.exchange⁩

@drwhax I am very very doubtful we will in any meaningful way.

In the end coding is an exercise in translating intentions into machine-readable code, and also an exercise in communication between those whose intentions are enshrined in code, and those who then need to maintain it.

We will be able to automate some things slightly better, though. But then the question is: at what cost?

Replying to @⁨drwhax@infosec.exchange⁩

@drwhax oh I've been talking about smaller open-weights models for a long time now. A leaked Google memo ("we have no moat") mentioned them as a massive problem for them years ago. I have much less problem with using small, specialized, self-hosted, open-weights models.

In fact I know of at least one small company that already does this for vulnerability testing of their own code, avoiding most of the BS.

That said, it is still immensely expensive for them to run it on their own infra.

en