I’ve spent twenty years in the software quality space and the last ten focusing on security (which interestingly, and core to the problem discussed herein, isn’t always considered or treated as part of software quality at most organizations).
While previously at Rational Software, I watched the plethora of test tools come out and I’ve witnessed how development teams have had to go through the changing dynamics of software quality and adjust. As an industry, we have not yet figured out how to integrate security activities into software development as we have done for performance, reliability and functionality. Why is that?
Before I talk about how we’ve mishandled it all, I will say that security is by far the most complicated aspect of software quality, and hackers get added joy (and sometimes profit) from exploiting software vulnerabilities. So you can’t compare it directly with the other aspects of software quality. However, let’s be honest – we can be doing a better job.
There are four systemic issues, which I provide in summary below, but will provide more details on in my upcoming blogs.
Over-reliance on tools
Tools are great, but operators must be trained on how to use them and developers need to know how to fix the problems found. They also need to be complimented with manual efforts to find the problems tools can’t – I don’t see this as the case today
Security efforts are driven outside of the development organization
How can we solve the insecure software application problem when those that are 100% responsible for create secure applications in the first place aren’t often the primary stakeholders and drivers?
We are obsessed with “Breaking” Applications and vulnerability counts
Although not easy to always do, finding problems is easier than preventing them. As an industry we get excited when we find all kinds of nasty vulnerabilities during testing because we caught them before customers/consumers paid the price. This really means that we aren’t doing things right in the earlier phases of development. Also – all vulnerabilities are not equal. We need to consider it in the overall context of risk: how likely/easy is it to exploit and what is the potential damage. Examining vulnerabilities in this light ensures those that are most impactful to the enterprise or customer are addressed first.
We refuse to accept that competent developers do not necessarily translate to good secure coding skills
Secure coding is about understanding the inherent threats to our applications and implementing defensive countermeasures to harden them from attack. Developers often don’t understand common attacks on the platform their application runs on, common vulnerabilities in the language they develop in, how/if certain frameworks they use can mitigate common security flaws, etc. It’s a completely different animal from writing functional code, folks.
If you’d like to hear me rant and rave a bit more about Why software is still insecure, I welcome you to watch our on-demand webcast, which I did with my good friend Charles Kolodgy, VP Research, Security Products, IDC.
