I’ve spent a lot of time on this blog pointing out how C and C++ are to blame for most of the severe computer security failures we see on a daily basis. The evidence so overwhelming (and well known!) that in my experience even the most rabid C partisans do not challenge it.

And yet, in practice, this fact is completely ignored. Developers ignore it: they continue to use C without qualms. Teachers ignore it: they still teach C. Infosec professionals ignore it: they don’t mention it when they write about security incidents (e.g., Project Zero), or they blame the victims of C for the failures of C.

This is irresponsible—it is unethical! Our professional organizations have failed.

For example, the ACM publishes Curricula Recommendations for computer science education. The ACM knows very well that using C leads to catastrophic failures in security, but its curricula do not reflect this. Consider Computer Science 2013: Curriculum Guidelines for Undergraduate Programs in Computer Science. The strongest statement it includes on C is this:

Explain why you might choose to develop a program in a type-safe language like Java, in contrast to an unsafe programming language like C/C++.

Pretty weak. You might choose safety; or you might not. I doubt that anyone who follows this curriculum would come out of it understanding the magnitude of the risk they take by programming in C. And if they proceed to practice C programming by “industry best standards” then they aren’t taking sufficient precautions and they (and the rest of us) are going to get burned.

Those of us in positions of responsibility need to start being responsible and condemn the use of C/C++, and insist that if C is taught it must be taught as a security risk that requires extreme caution and programming discipline.

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