Mar 12, 2014
It may therefore come as a surprise (or not, if you are a software developer yourself) that most companies fail to invest in adequately training developers on security best practices, whilst throwing large amounts of money at advanced detection tools. Many large organisations have the latest firewalls, advanced malware detection systems and automated code testing tools, but skimp on even basic secure development training. This leads to a major, fundamental problem: most firms continue to develop insecure software.
According to a 2012 research report by the Ponemon Institute:
- 63% of security professionals and developers state that application security consumes 20 percent or less of their overall IT security budget.
- 71% of developers believe security is not adequately addressed during the software development lifecycle.
- 51% of developers believe security is only addressed in the launch and post-launch phase.
- Just 16% of developers believe security is addressed during the design and development phases, compared with 36% of security professionals.
- 47% of developers say their organisation has no mandate to remediate vulnerable code, compared with 29% of security professionals.
- Just 11% of developers think their organisation has a fully deployed application security training program, compared with 22% of security professionals.
These statistics identify two major problems:
Application security seems to be addressed late in the software development lifecycle, where it costs more to address vulnerabilities.
- Security professionals and developers have significantly differing opinions on how well security best practices are implemented in their organisation, implying that developers are inadequately trained.
Why Is This?
Perhaps one of the biggest reasons that companies continue to fail to invest in training is the perceived loss in developer time to training. Senior management calculate that to invest in X hours of training per year, for every developer in their organisation, they'd be spending, well... An astronomical amount of money.It's then challenging to measure the direct results of that investment. How do you know exactly how many vulnerabilities you prevented from reaching your applications?Let's consider the following assumptions for a second:
- It takes your development & quality assurance team 30 hours to remediate a critical security vulnerability.
- On average, 500 critical defects make it into your applications each year, and are detected.
That's a total of 15,000 hours of developer & QA team time to resolve those vulnerabilities. You can therefore consider that as an absolute "upper limit" for your total developer time investment in security training. So if you had a team of 500 developers, that would represent a maximum of 30 hours per year, per developer. To break-even, that 30 hour investment would have to stop all 500 critical defects from making it into your applications.Now, to make another assumption, let's assume that a developer who is given 5 hours of security training introduces one less security vulnerability into their software each year than one not trained in security. That means that for your developer's 5 hours of training, they saved 30 hours of development & QA time. A 6x return on investment.Now, these numbers are of course all speculative, but even if somehow your development team could eliminate vulnerabilities in half the time, that's still greater than a 3x return.Better still, what if you could provide your developers with computer-based training on-the-go? Software which helps them to improve their security knowledge during their downtime, whenever it's appropriate. This presents an opportunity to minimise lost development time, and let developers teach themselves on their own terms, without impacting productivity.Are the economics of developer training really even a question at this stage? Developers trained in security introduce less vulnerabilities into applications, which results in lower assessment and remediation costs. It also further decreases the chance of a critical vulnerability making it into your deployed application, and we've all seen what that can do.