|
Countless studies and analyst recommendations suggest the value of improving security during the software development life cycle (SDLC) rather than trying to address vulnerabilities in software discovered after widespread adoption and deployment. The justification is clear. For software vendors, costs are incurred both directly and indirectly from security flaws found in their products. Reassigning development resources to create and distribute patches can often cost software vendors millions of dollars, while successful exploits of even a single vulnerability have in some cases caused billions of dollars in losses to businesses worldwide. Vendors blamed for vulnerabilities in their product’s source code face losses in credibility, brand image, and competitive advantage. A study in 2005 by Carnegie-Mellon found that the stock price of vendors declined an average of .63 percent compared to the NASDAQ after a vulnerability is discovered in their software.2 Studies with this level of detail are not available for flaws found in custom enterprise software developed in-house or outsourced, but in all cases there is agreement that the earlier in the life cycle that flaws are discovered, the cheaper they are to address. As shown in the chart below, research published by B. Boehm and V. Basali in IEEE Computer found that fixing a software defect after deployment costs more than 100 times what it would have cost to fix it at the first stages of the development life cycle.3 For security defects, late-stage costs are often much higher, because in addition to having to remediate the flaws, successful exploits may lead to data theft, sabotage, or other attacks.
Automated source code analysis is widely recognized as the most effective method of security testing early in the life cycle, because it allows assessments of any piece of code without requiring a completed application. The best of these technologies provide the most valuable results by pinpointing each vulnerability at the precise line of code and detailing information about the type of flaw, degree of criticality, and how to fix it. Penetration testing is also an important element of software security, but its value comes later in the life cycle, when it can be used on a completed application with a functional interface.
Roadblocks to Building Security In
Among the hurdles that may impede security testing in the SDLC, the largest is typically the gap between development and security. The skill-sets themselves are rarely present in the same individual or even group, and organizationally, there is very little inherent synergy. While development goals focus on product functionality and on-schedule delivery, security staff is often tasked with eliminating vulnerabilities and implementing security controls only after the applications are completed and deployed. To effectively decrease vulnerabilities created during the development process, cooperation must be achieved between these two groups, and in all cases, higher-level management support for improving security during development is essential.
In addition to organizational impediments, a general hesitancy to change or revise an existing SDLC process may delay implementation of security testing, however a simple understanding of the business-level benefits to be gained is usually enough incentive to move things forward. Similar to this conceptual roadblock, there are many misconceptions about integrating security analysis during development that must be overcome before an initiative can move forward.
Fiction:
The development schedule cannot afford to be stretched any further, not even to address security issues.
Fact:
There may be initial lapses in the development cycle, especially as individuals learn the new system. However, this is the most time-efficient method for reducing software risk, and the process eventually reduces development time by instilling good secure coding practices among developers. The only faster alternative is to do nothing to improve software security, an option that most organizations certainly cannot afford in the long term.
Fiction:
We are already doing peer review; therefore we don’t need additional “security” code review.
Fact:
Peer review is not a substitute for security review. Peer review is typically used to find functional bugs, so unless the review is targeted to find security defects and, more importantly, the reviewers have a deep understanding of application security, many of the more critical security vulnerabilities and design flaws will be missed. In many cases the best-intentioned user requirement implemented without functional error can lead to the greatest security risk.
|
