The first thing to fix is bad tooling, yes, but it's not the whole picture.
Once all your queries are safe by default, your languages have memory safety, your templates XSS-encode by default etc etc (this is basically the situation at most sane workplaces) - there are still security issues.
There are fewer security issues left, but they're gnarlier. What we see now are "application logic" and business logic issues. Overflow and language-level sharp edges exist, but these are a small proportion of the mistakes developers (in particular, web application) seem to be making.
Situations where the server unintentionally signs user-controlled data, bad OAuth2 flows, missing or incorrect authorisation checks, accepting data from the client as "validated" - these are much more common in my experience.
The other interesting thing I've noticed is that when developers who are used to "safe by default" frameworks have to step outside the framework for any reason (e.g. front-end is 90% angular, but 10% "bespoke" JS) they will make mistakes with very high likelihood.
The solution is tooling yes, but also education and process.
First you fix and raise awareness about the biggest cause of problems. It takes a long time. Then you do it again with the remaining biggest cause of problems. Etc.
There are tools and methods to address the "first world problems" of application logic vulnerabilities too. Maybe in another 20 years those are at the forefront.
I think such security issues are similar to the ones author described. They require decent language-level abstractions to disappear as well. Some sort of lightweight processes to deal with trust boundaries explicitly and easily.
What you'd need is almost dynamic live proof checkers hooked to your IDE capable of tracking the effects of code changes / refactoring to do that, linked to test cases themselves carrying proofs of testing the spec completely.
How else will you be guaranteed to catch Goto Fail and similar?
What's worse is when you hit the issue of "composability" in cryptography - two servers run different algorithms making different assumptions, and when they interact the assumptions fail to translate and neither provide the guarantee they should. Like cross-protocol attacks, such as when one server becomes a signing oracle for another.
Edit: and beyond that, we have cross architecture disagreement on results of calculations intended to be deterministic. Like how SPARC Bitcoin Qt binaries previously would have had the Bitcoin reward schedule loop every 255 years and go back to 50 coins per block and restarting the countdown.
Once all your queries are safe by default, your languages have memory safety, your templates XSS-encode by default etc etc (this is basically the situation at most sane workplaces) - there are still security issues.
There are fewer security issues left, but they're gnarlier. What we see now are "application logic" and business logic issues. Overflow and language-level sharp edges exist, but these are a small proportion of the mistakes developers (in particular, web application) seem to be making.
Situations where the server unintentionally signs user-controlled data, bad OAuth2 flows, missing or incorrect authorisation checks, accepting data from the client as "validated" - these are much more common in my experience.
The other interesting thing I've noticed is that when developers who are used to "safe by default" frameworks have to step outside the framework for any reason (e.g. front-end is 90% angular, but 10% "bespoke" JS) they will make mistakes with very high likelihood.
The solution is tooling yes, but also education and process.