If I had to guess, I’d say that a lot more people spend a lot more time trying to test security into software than those that try to write secure code in the first place. Every other “engineering” discipline has long ago given up such madness. Deming said “Cease dependence on inspection to achieve quality” which I’d paraphrase as “Cease dependence on inspection to achieve security“.
And yet most organizations that are doing anything at all for security are doing some kind of late-cycle full-system test like penetration testing. Something that I’d call DevTestOpsSec or DevTestSecOps. Static code analysis (SAST) is the right way to get ahead of the security curve. We’ve simply got to begin building software that can handle the insecure environment of today’s connected applications and devices.
I’ve written an article on this topic you can find at Info Security titled “SAST: Beginning at the End” and it explains the whats and whys of static code analysis as a security tool and how you can avoid the problem of noisy tools. (Something I call SOOT for “Straight out of the Tool” static analysis. Processing and analytics required. More on that later.) Getting this right moves us from a “test-security-in” mindset to a “build-security-in” one. Or better yet, to secure-by-design. Give it a read and let me know what you think here, twitter, etc.