If you can compromise an employee desktop and put a too-cheap-to-meter intelligence equivalent to a medium-skilled software developer in there to handcraft an attack on whatever internal applications they have access to, it's kind of over. This kind of stuff isn’t normally hardened against custom or creative attacks. Cybersecurity rests on bot attacks having known signatures, and sophisticated human attackers having better things to do with their time.

In open source codebases perhaps, either because big tech would be generous enough to run and generate PRs(if they are welcome ) for those issues.

In proprietary/closed source it depends on ability to spend the money these tools would end up costing.

As there is more and more vibe coded apps there will be more security bugs because app owners just don’t know better or don’t care to fix them .

This happened when rise of Wordpress and other cmses and their plugin ecosystem or languages like early PHP or for that matter even C opened up software development to wider communities.

On average we will see more issues not less.

In general, most modern vulnerabilities are initially identified with fuzzing systems under abnormal conditions. Whether these issues may be consistently exploited can be probabilistic in nature, and thus repeatability with a POC dataset is already difficult.

That being said, most modern exploits are already auto-generated though brute-force, as nothing more complex is required.

>Does anyone disagree?

CVE agents already pose a serious threat vector in and of itself.

1. Models can't currently be made inherently trustworthy, and the people claiming otherwise are selling something.

"Sleeper Agents in Large Language Models - Computerphile"

https://www.youtube.com/watch?v=wL22URoMZjo

2. LLMs can negatively impact logical function in human users. However, people feel 20% more productive, and that makes their contributed work dangerous.

3. People are already bad at reconciling their instincts and rational evaluation. Adding additional logical impairments is not wise:

https://www.youtube.com/watch?v=-Pc3IuVNuO0

4. Auto merging vulnerabilities into opensource is already a concern, as it falls into the ambiguous "Malicious sabotage" or "Incompetent noob" classifications. How do we know someone or some models intent? We can't, and thus the code base could turn into an incoherent mess for human readers.

Mitigating risk:

i. Offline agents should only have read-access to advise on identified problem patterns.

ii. Code should never be cut-and-pasted, but rather evaluated for its meaning.

iii. Assume a system is already compromised, and consider how to handle the situation. In this line of reasoning, the policy choices should become clear.

Best of luck, =3

I've also thought this for scam perpetration vs mitigation. An AI listening to grandma's call would surely detect most confidence or pig butchering scams (or suggest how to verify), and be able to cast doubt on the caller's intentions or inform a trusted relative before the scammer can build up rapport. Security and surveillance concerns notwithstanding.

Why would it be like that instead of the way we already handle low-trust environments?

Projects that get a lot of attention already put up barriers to new contributions, and the ones that get less attention will continue to get less attention.

The review process cannot be left to AI because it will introduce uncertainty nobody wants to be held responsible for.

If anything, the people who have always seen code as a mere means to an end will finally come to a forced decision: either stop fucking around or get out of the way.

An adversarial web is ultimately good for software quality, but less open than it used to be. I'm not even sure if that's a bad thing.

That's how I read it at first too, but I think the more probable interpretation is that it was a fix to a project that has 4.5M lines of code.

It's lost its charm.