| > I don't find the defence in depth approach appealing, because it's never going to get you to 100% reliability. Rather than adding six swiss-cheese layers and hoping the holes don't line up, it would be better to spend more time and effort on a single really solid layer. But those layers are not part of your own work, they are external tools. Yes, it would be great if one of those would just catch all the bugs, but that's not happening. So you have to choose either one single slice of Swiss cheese, or you work a bit on your plate to be able to add additional safeguards. > Sure, a lot of the bugs in that C code are findable. But so what? However many bugs you uncover, you're unlikely to find them all, and even if you did then how would you know? So isn't fixing bugs in existing C codebases just throwing good money after bad? Bug free is not achievable, in no language. But good enough, secure enough, functional enough are achievable goals. For many existing code bases (especially for projects with clearly defined scope) good enough is easier achieved by fixing up C code compared to a rewite in a different language. Was it a different language from the beginning it might have been cheaper overall, but at some point the rewrite will just consume more money to reach the same state. |
I feel like this is because our standards for "good enough" are so low, partly because languages like C and C++ make it so hard to do any better. It's true that there is a high cost to switching languages for an existing project, but the cost we are paying for all of foundational tools and libraries being built in a shaky unsafe way is also huge.
Studies I've seen suggest that ~70% of security vulnerabilities in C and C++ codebases are bugs (memory safety, thread safety, undefined behaviour) that would be caught by static checks in other languages. Think how much time and effort goes into ensuring basic safety invariants in C codebases. Then think how many of the remaining logic bugs we could catch if that effort was spent entirely on finding them.