This is an interesting read by Niklas Gogge. He has a theory about why Bitcoin seems to be getting hit so hard right now:

Why are we only now seeing these exploits? My theory is that Bitcoin software (Bitcoin Core, Lightning, Liquid, …) has historically not been on the radar of threat actors, or not their priority, because the surface area of the wider cryptocurrency industry is much larger, and the cost of discovering vulnerabilities there was lower. Why invest in breaking a hardened codebase like Bitcoin Core when there is an ever-growing supply of less mature smart contracts to attack instead? I think this theory is supported by the amount of money stolen (from e.g. EVM bridges alone), as well as the scale of the smart contract auditing industry. Looking at recent examples, the game has obviously changed, a model pointed at hardware wallet firmware may quickly uncover something as consequential as a flaw in seed generation. The costs have clearly fallen dramatically.

And he has a caution:

What has been bugging me is a growing sense that software correctness now hinges on having access to the latest frontier model. That is not a sustainable security model. I think that LLM scanning should obviously be part of any serious project’s security efforts, but making it the primary strategy for a project’s security/correctness will result in a new wave of exploits each time the latest model drops. Projects should use the LLMs but, more importantly, work towards getting ahead of the LLMs, by investing in engineering practices that persist across model generations.

He speculates that the reason Bitcoin Core and the libsec256k1 library have both held rather better than not is that they have had intense developer scrutiny in their processes and lots and lots of testing:

I am obviously biased given my work, but in my opinion one of (there are obviously more) the biggest contributing factors to the robustness of these projects is their exhaustive, continuous, and automated testing. Fuzzing/property-based testing, in particular, provides a level of assurance you can not achieve with example based testing, or code review alone (human or LLM). Bitcoin Core has spent more than a century of CPU time fuzzing individual functions and critical components (though oss-fuzz, Fuzzor, bitcoinfuzz and individual contributors), and decades of CPU time simulating small networks of full nodes under test (Antithesis, Fuzzamoto). I can’t establish causality from this alone, but my strong suspicion is that the sustained testing effort is an important reason these projects have become so robust.