It's still the case that two thirds of critical CVEs are due to memory safety errors. That ratio has held constant for several decades. Those CVEs aren't in har

It's still the case that two thirds of critical CVEs are due to memory safety errors. That ratio has held constant for several decades. Those CVEs aren't in hardware drivers, but in mundane things like JPEG decoders and mail processing programs. That is directly due to them being implemented in unsafe languages. > Security isn't boolean, and the closer to "security = 1" you get the more non-functional the system. Security isn't one-dimensional. Security can be phrased in functional requirements like "does not allow remote code execution attacks", which is of course a boolean requirement. You can slice that finer and finer such as "does not allow remote execution attacks through X, Y, or Z mechanisms" and start adding other, higher-level requirements such as "does not leak user data through APIs", etc. Security isn't boolean, but it is absolutely chock-full of boolean requirements one can pose. > I believe we need to be better at: Detection, mitigation, response -- all things traditionally sysadmins dealt with. I don't disagree with that, but this is the last-line-of-defense, the-horse-has-left-the-barn stage, which is basically admitting defeat because of how absolutely riddled with vulnerabilities existing software is.