Security bugs are just a quality defect. Quality defects have many causes, but they all roll up to three root causes: 1) lack of a process to ensure quality, 2) a process which does not address the defect, and 3) inability to follow the process.

If there is no process to eliminate the defects, then they will always appear. Based on my knowledge and experience of this kind of software development, I have noticed that a majority of the time, there is no process applied to the development which would eliminate these defects. We just expect, or hope, that the developers are smart enough and rigorous enough to do it by themselves without anyone asking. Well, in the real world, you can't just hope for quality. The results speak for themselves.

Even when there is a process applied to eliminate the defect, it is often not effective. Either the process doesn't go far enough (many still don't even use Valgrind), or the people applying the process either don't follow it, or not well enough.

Many in the industry have decided that the solution to these defect issues is to use a new system [programming language] which avoids the need for the process to begin with. That's not a bad idea in principle. But they've only done that for a single class of quality defect. The rest of the security bugs, and every other kind of defect imaginable, is still there. And new ones will appear over time.

So rather than play whack-a-mole very slowly designing brand new systems to eliminate one single class of defect at a time, my proposal is we change the way we do development fundamentally. Regardless of the system in use, we should be able to define processes, ensure they are applied correctly, and continuously improve them, to eliminate quality defects.

This would not only solve security issues, but all kinds of bugs. If this method was standard practice (and mandatory), the Crowdstrike issue never would have happened, because they would have been required to be looking for quality defects and eliminating them.

Security bugs are a distinct kind of defect and can't be reasoned about the same was as ordinary bugs, because ordinary bugs don't have intentional adversaries driving them. It makes sense to accept the risk of some kinds of bugs in ways you generally can't with security bugs (without some other mitigation in place).

I fully agree that if you want the highest quality outcomes, you have to consider the whole process.

However, I don't see that as being in conflict with using tools that can also help you achieve higher quality within a certain stage of that process.

The problem isn't the new tool, it's wasting an opportunity to have a more significant impact. The same amount of time, money, and resources that's going to be invested in this, could have been invested in a larger solution that still would have solved the immediate goals, as well as many others. We're pissing away the chance to improve not only more security but reliability of software as a whole. This is going to distract people for years away from other issues, and the result will be real world harm that could have been prevented. All because one class of bug is meme-worthy.