Pretty consistently [1] [2] [3] [4] it comes out that nearly %80 of security vulnerabilities come from memory safety vulnerabilities. I would consider that largest. Especially Microsoft's doc is pretty telling that this ratio was pretty consistent since 2006 so no amount of external tooling and training solves this. [1] langui.sh/2019/07/23/apple-memory-safet… (albeit apple solving this with an another language and a really nice cpu extension) [2] microsoft.com/en-us/msrc/blog/2019/07/w…... [3] security.googleblog.com/2019/05/queue-h…... [4] x.com/LazyFishBarrel/status/11290009657…

> Memory safety is much less of an issue than it used to be. This is demonstrably false: twitter.com/LazyFishBarrel/status/11290…... Additionally, new "safe" C++ APIs aren't: bugs.llvm.org/show_bug.cgi?id=34729 Apple's iOS 12.4 release fixes 37 CVEs, 28 of which are memory unsafety (75.7%). Microsoft's statistics corroborate this: zdnet.com/article/microsoft-70-percent…... Importantly, none of these sources show any improvements over time. If we saw meaningful improvements in "modern C++" codebases, I'd be much more willing to accept "modern C++". As it stands, there is no such evidence that "modern C++" provides any demonstrable benefits regarding memory safety.

There's a blub on "why Go?" on the website if you're interested. gvisor.dev/docs/architecture_guide/ > gVisor is written in Go in order to avoid security pitfalls that can plague kernels. With Go, there are strong types, built-in bounds checks, no uninitialized variables, no use-after-free, no stack overflow, and a built-in race detector. (The use of Go has its challenges too, and isn’t free.) Using a memory-safe language was a conscious design decision. twitter.com/LazyFishBarrel/status/11290…...