The only way it might hold here is if no one with access to the cutting edge models bothers to run your code through one while an adversary does. That seems highly unlikely, particularly for any well funded organization.
That said I agree that monoculture is bad. Vulnerabilities like heartbleed or spectre are so devastating precisely because they apply to approximately everyone.
> The only way it might hold here is if no one with access to the cutting edge models bothers to run your code through one while an adversary does. That seems highly unlikely, particularly for any well funded organization.
But since AI models are non-deterministic and the harness matters a lot, simply "running your code through one" doesn't guarantee you'll find all the zero days. An attacker can simply run a few more iterations or use a slightly more advanced harness, or increase the temperature level and they are likely to find zero days which the maintainers didn't.
The exact same line of reasoning applies to human security researchers and pen testers as well. The only difference is that automated testing via frontier models is affordable even for individuals.
The VM comment is total nonsense. That's only going to be the case for an extremely short period here until the major projects all adapt their release procedures to include automated security audits. I imagine the kernel as a whole and KVM in particular will begin receiving a huge amount of such attention. I also expect increasing amounts of such load bearing code to be formally verified as the primary barrier to that has always been the amount of human time required.
its been very sad for me to see standardization get ignored, and the implementation become the point of reference. for a long time the only way to implement QUIC was to try to extract it from the Chromium code base - a pointless waste of time. but they spec for years was a couple of pages of meeting notes and a sample compression dictionary.
if we continue down this road we are impeding our own ability to evolve. if compatibility is defined by the implementation then were left with nasty balls of antiquated source that we carefully move around and try to plumb into our new environments, but no one really understands.
at the core, things like IP are very straightforward. we can and should specify the semantics of every bit, and have a wide variety of other implementations to test against. this provides a path for us to build new techniques and environments that are still useful in the world that exists today.