We have all seen the famous metrics on how the cost to correct a defect goes up by as much as 100 times if you fix it in operations instead of requirements, development or quality assurance (Q.A.) stages.
So the same principles can be applied for security testing as well. And, that all makes sense. But, there are some hard facts that we need to keep in mind for all the other applications that are not in development or Q.A.
With about 99 percent of a company's applications in production at any given point of time, it's extremely critical that these applications are tested on a continuous basis. If you wait for these applications to come back in development, it might be a year or more.
And, we are discovering 300 to 500 new application vulnerabilities every month. Testing in development and at the Q.A. stage is just not enough.
Can you afford to be exposed with the majority of your deployed applications for months or years?
AGAINST, by Michael Sutton, security evangelist, SPI Dynamics
Enterprises have been reactive when it comes to identifying application vulnerabilities. Security has been an afterthought. This needs to change.
Security must be “baked in” throughout the software development lifecycle, not “brushed on” at the end. Empowering developers to write secure code is an essential component in this revolution.
Developers must be provided with appropriate training, tools and processes in order to be checking for security defects as they develop applications. This requires that we establish appropriate educational initiatives and security tools that are designed specifically for developers. The goal is to provide developers with knowledge to avoid common programming mistakes and to leverage automated scanning tools, which integrate transparently into the environments that they're already comfortable working in.
Testing for security defects during development is not a replacement for security testing at later phases of the development lifecycle, but it is an essential and often overlooked step.