But that said, C++ is safer than C.
This is a result of large and complex software developing features that require a large amount of manual and error prone code, whereas C++ can do the work for the developer, and will do it correctly everytime. Are there bad things in C++? of course. But you can avoid the known "bad" features - we can acknowledge things we originally thought would be good were in fact bad, and also recognize they need to remain due to old code - without throwing out all the good features.
Hence you get the "modern C++" subset that all serious large c++ projects use, which is not some horrific wasteland of bad code. Most security bugs that have been in C++ have been as a result of errors inherited from C and, unlike C, can be engineered out.
My suspicion is that the over-representation of C++ in vulnerability statistics is a product of the size of the major C++ codebases, the value of those targets, and the complexity of the products.
What people often don't think about in the safe languages debate is that it's not about the skill of specific programmers. Yes, good programmers can write secure C or C++ code. That's not the problem.
The problem is what happens as code ages. What happens when bugs are fixed, refactors are done, code is ported to other platforms and OSes, multiple people work on it, and pull requests are merged. Bugs creep in when modifications are made without the full context, hastily, and by people who did not write the original code or when it was written so long ago that they've forgotten the deep details of it.
Safe languages will prevent, catch, or at least "nerf" the most dangerous sorts of bugs such as memory errors. Rust is very good at catching most of them at compile time. Unsafe languages won't and it's easy for bugs to creep in later and then result in catastrophic security failures long after they're released. Look at OpenSSL, a hoary old code base that continues to produce ugly security bugs.
MSFT, Google, Apple, Facebook all have a gazillion lines of C++ and it's not going away any time soon. "Don't use C++" is not practical advice for them and many other companies.
1 - Use a managed language like C#, Java, Go if automatic memory management is ok
2 - Use a systems language like Rust if automatic memory management is not an option
3- Use C++ alongside Core Guidelines tooling.
Granted, not all Microsoft projects care about those guidelines.
As a former C++ developer, errors leading to crashes (be it due to memory or otherwise) were always more preferable to me than logic errors or race conditions (which can still happen in Rust) that go unnoticed for months/years. I guess 'danger' here is subjective, but thats my view.
In any case we're talking about security here where many crash bugs can in fact be catastrophic security vulnerabilities. If it crashes there's a distinct possibility that the bug is exploitable.
For each of these types there are some mitigations available at both the OS and hardware level, but I was making a general point about logic vs crashing bugs.
> If it crashes there's a distinct possibility that the bug is exploitable.
What I mean by crashing is that the program stops executing. Are you saying that crashing bugs make it easier to plant resident code? I'm nota security expert, so I don't quite know what you're referring to.
Understand that there are no safety nets provided by the compiler or runtime while coding in C++.
I mean, another reading of this article is that it's a list of the sharpest edges to watch out for in the C++ language, not a list of secure coding practices. The advice presented here boils down to "avoid these common bear traps and foot guns that are unhelpfully provided for you as part of you C++ starterpack." I think many reasonable people could easily conclude the same as the OP after reading this piece.