If you are doing security of all things - why wouldn't you verify the provenance of your tooling and libs?

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.

Please tell your people about 2FA SMS delivery issues to certain West African countries. I'd rather have it via email or have the option of WhatsApp

I was fine before 2FA and I'm willing to pay to go without. Same username

Can't scan my code if I can't access my account

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 many small companies (e.g. startups), the attackers are far more experienced and skilled than are the defenders. For attacking specific targets, they also have the leisure of choosing the timing of the attack - maybe the CTO just boarded a four hour flight?

> I'm optimistic that it's easier to find/solve vulnerabilities via auto pen-testing / patching, and other security measures, than it will be to find/exploit vulnerabilities after - ie defense is easier in an auto-security world.

I somewhat share the feeling that this is where it's going, but not sure if fixing will be easier. In "meatbag" red vs. blue teams, reds have it easier as they only have to make it once, blue has to always be right.

I do imagine something adversarial being the new standard, though. We'll have red vs blue agents that constantly work on owning the other side.

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.

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.

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

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.