Hacker News new | past | comments | ask | show | jobs | submit login

Sounds about right because he is using the number of eliminated CVEs, not the number of remaining CVEs. Compare with 98% and 99.8%; even when we have been tracking all possible CVEs, 98% elimination will leave 10x remaining CVEs than 99.8% elimination. (Of course both are much better than 0% elimination, i.e. status quo.) I feel the true figure would be somewhere around 99.8% and 99.98%, especially when a massive undercount from existing C/C++ projects is accounted for.



He addresses this point in the article as well, discussing risks that that language community gets too fixated on one kind of safety while attackers shift to other concerns like supply chain, code injection, or leaked credentials.


That sounds like a situation I'd describe as "a good problem to have". Almost completely eliminating a comment attack vector and having to figure out how to pivot to stamp out another type is far better than just not making any significant progress at all. If the concern were that they were already making progress on some of those other security concerns and they were worried that switching focus would risk gains they expect to make soon in those areas, I think that would be reasonable, but that doesn't seem to be the case. Is there any evidence that this concern is anything other than hypothetical? It comes across more as an attempt to justify not spending effort improving memory safety rather than something that anyone is actually concerned about.


Of course, but memory unsafety is one of the biggest enabler for security vulnerabilities. Attackers have shifted to other concerns when PHP became widespread enough for example, but PHP alone cannot be used to create a vulnerability common in C/C++ because of its memory safety (which is not even that good!), you need some other systems to combine multiple issues into a single coherent attack, and it's likely that C/C++'s memory unsafety has played a great role somewhere in between. He doesn't fully acknowledge this multiplicative aspect of memory (un)safety.


That seems far fetched to me. The vast majority of zero-days are still memory safety issues, and it would be an absolute miracle if the C++ community can get that ship turned around in under 20 years. Even 50 seems unreasonable honestly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: