> Shortening patch cycles will only help so much. It's funny that whenever an NPM supply chain attack is published, people recommend a cooldown before installing new versions, and then when a vulnerability is discovered, everybody jumps to patch. Clearly these two strategies collide at some point

It’s a good point. As things speed up it will be harder to tell which patches are actually urgent and need to skip the cool-off period.

I think the more robust way of doing this is to have code audits on each published release. Agents can do some of this (eg Github could offer this scanning service, and let external parties fund the scanning on trusted compute).

I think of this more as a “proof of work” problem than provable security; if I see that Mythos has run for N hours on the patch release I am considering upgrading to, then this might suffice.

The key thing here is you need a way to crowdsource the funding of scans, and make them shareable so that the cost can be shared across the community. The package owner obviously can’t control the prompt. And can Mythos-class models be hardened enough to scan hostile code?

To your point on blocking requests, there are programming models that make this easier, like capability-based programming, where code that doesn’t need internet cannot get it; this doesn’t solve things fully, but my general prediction is that adding new architectural patterns is now a lot cheaper and easier to reliably apply across a codebase, so we may see more of this too.