4 ms·

Here is the data from Microsoft Security Response Center on this [1]. Slide 5 shows double as many CVEs as 4-5 years prior, triple as many as 6-8 years prior. F

Here is the data from Microsoft Security Response Center on this [1]. Slide 5 shows double as many CVEs as 4-5 years prior, triple as many as 6-8 years prior. Further, slide 10 shows 70% of CVEs are memory safety and that ratio has been constant since 2006. It follows that the absolute number of CVEs which are memory safety is double 4-5 years prior and triple 6-8 years prior, which is inconsistent with a massive reduction. The magnitudes here are in the many hundreds of CVEs per year from Microsoft (and growing), not "one CVE in 2021". 70% there is not a negligible number. [1] https://github.com/microsoft/MSRC-Security-Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf https://github.com/microsoft/MSRC-Security-Research/blob/mas...

fourcommas 6y ago
Now divide the number of CVEs in each year by the LoC maintained. You're again looking at completely the wrong number. Line-for-line, C/C++ written today at MSFT/Goog has less memory errors than 10 years ago, and even less exploitation of memory errors. Anyone who lived through the rise and fall of Internet Explorer intuitively knows this.
- dtolnay 6y ago
  Dividing by the LoC is a mistaken way of looking at this data. Regardless of the amount of code in a browser or in Windows, an attacker may only need ONE exploitable bug to cause mischief. If the amount of code in Windows grows by a factor X from year to year, the CVEs per LoC better be shrinking by at least factor X (this is where Rust comes in) or else the system is getting less secure. Thus the absolute number is the relevant metric, and indeed is the number reported by Microsoft Security Response Center.
  - fourcommas 6y ago
    > the CVEs per LoC better be shrinking by at least factor X (this is where Rust comes in) or else the system is getting less secure Do you really think windows 95 was more secure than win 10? Or that IE6 was more secure than the latest IE? The newer versions are way more secure, it's not even close. Your data is giving you incorrect conclusions, because you're combining and cutting the data in ways that don't make sense.

fourcommas 6y ago

Now divide the number of CVEs in each year by the LoC maintained. You're again looking at completely the wrong number. Line-for-line, C/C++ written today at MSFT/Goog has less memory errors than 10 years ago, and even less exploitation of memory errors. Anyone who lived through the rise and fall of Internet Explorer intuitively knows this.

dtolnay 6y ago
Dividing by the LoC is a mistaken way of looking at this data. Regardless of the amount of code in a browser or in Windows, an attacker may only need ONE exploitable bug to cause mischief. If the amount of code in Windows grows by a factor X from year to year, the CVEs per LoC better be shrinking by at least factor X (this is where Rust comes in) or else the system is getting less secure. Thus the absolute number is the relevant metric, and indeed is the number reported by Microsoft Security Response Center.
- fourcommas 6y ago
  > the CVEs per LoC better be shrinking by at least factor X (this is where Rust comes in) or else the system is getting less secure Do you really think windows 95 was more secure than win 10? Or that IE6 was more secure than the latest IE? The newer versions are way more secure, it's not even close. Your data is giving you incorrect conclusions, because you're combining and cutting the data in ways that don't make sense.