Two new on-demand courses, fully recorded and ready:
🔎 Web Security Code Review
🐹 Secure Coding for Go Developers, beyond the OWASP Top 10
Learn at your own pace. Launch discounts available now:
https://t.co/eqlUSylVXD
In 2008, Debian disclosed that a change intended to silence Valgrind warnings had broken OpenSSL's random number generator.
The change removed code that mixed entropy into its internal state, leaving the process ID as the only meaningful source of variability. Attackers could precompute the possible keys instead of breaking the cryptography.
In 2026, eight of eMudhra's intermediate CA private keys turned out to be:
4, 56, 66, 115, 155, 156, 230, 237.
Assumptions are at the root of so many security issues. When testing an application or reviewing code, always ask yourself: "What assumptions did the developer make? What assumptions am I making when I say this is secure?"
Maybe you're assuming that an input has already been validated, that a route requires authentication, or that a framework handles a security check for you.
Each of those assumptions deserves to be verified.
Questioning the developer's assumptions is part of the job, but questioning your own is just as important.
Getting a CVE is easy when you're the one writing the vulnerabilities.
Just make sure you clarify what you mean by "responsible for 30 CVEs" on your resume... 😉