One of the most important lessons I’ve learned in security, is that it’s always better to push security problems back to the source as much as possible. For example, a small number of experts (hopefully) make cryptography libraries, so it’s generally better if they put in checks to prevent things like invalid curve attacks rather…

NeilMadden's blog is a resource for developers and software engineers seeking to enhance the security and efficiency of their programs. Covering topics such as secure coding practices, encryption techniques, and vulnerability management strategies, it offers practical insights and actionable advice to mitigate security risks effectively. Through detailed tutorials, code examples, and expert commentary, the blog equips its audience with the knowledge and tools needed to build robust and resilient software solutions in today's digital landscape.

Neil Madden

Locking dependencies to specific versions creates a cascade of manual update work across the ecosystem, leaving many projects running vulnerable code for years. The author argues that always resolving the latest patch version by default would be healthier, with security problems fixed at source propagating automatically. To address supply chain and reproducibility concerns, the proposal includes built-in time delays before new versions are resolved, a mechanism to 'shun' problematic versions, and generating SBOMs at build time for retrospective reproducibility rather than commit-time lockfiles. This shift would also reduce the need for CVE-driven update pressure, since patches would flow automatically without requiring loud announcements to overcome inertia.

Maybe version ranges are a good idea after all?