Last week NIST released a fairly lame whitepaper on Dramatically Reducing Software Vulnerabilities. The paper is a laundry list of “specific technical approaches that have the potential to make a dramatic difference in reducing vulnerabilities – by stopping them before they occur, by finding them before they are exploited or by reducing their impact.”

I don’t really have a problem with any of the technologies on their list (formal methods, containers, …) but an unordered list of recommended technologies isn’t going to make a “dramatic difference.” If you give a programmer this list they’d hardly know where to start.

It would be much, much better to say what NOT to do. And this is very simple: if you want to make a dramatic difference in reducing vulneratiblities you should STOP using unsafe languages like C and C++.

Once again, let’s pick the latest security bulletin of the week. This time it is Apple’s About the security content of iOS 10.2. This lists 48 separate issues, and fully half of them (24) are clearly due to bugs in unsafe language code (memory corruption, buffer overflow, type confusion, use-after-free, etc.). Furthermore, one of the issues lists 12 distinct memory corruption bugs!

Any introductory programming class will teach you to profile your code before you optimize it. That way, you know what parts of your code contribute most to its runtime, and what parts are barely executed. It makes no sense to improve the speed of parts that are barely used; you should focus your efforts on the parts that consume most of the running time. Otherwise, you have no hope of making a meaningful improvement.

Similarly, when trying to make a “dramatic difference in reducing software vulnerabilities,” you should look at the data to see what factors in your code are causing the most vulnerabilities. And the data repeatedly shows that unsafe languages are causing the most vulnerabilities.

This 58-page NIST report should be thrown in the trash and replaced by a simple bumper sticker:

Stop using unsafe languages like C and C++

(Previously: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23.)