See Building Security In: An Ounce 4.0 Product Overview

Organizations should implement source code security scanning tools as part of the software development life cycle to find and fix the highest number of security issues early in the project. This will result in a higher-quality product and lower overall application life cycle costs.
Gartner Research

Countless studies and analyst recommendations suggest the value of improving the security of software as it is being developed, rather than trying to address vulnerabilities discovered after widespread adoption and deployment. The justification is clear.

For software vendors, costs are incurred both directly and indirectly from flaws found in their products. Oracle’s Chief Security Officer, Mary Ann Davidson, commented in May 2006 that fixing a single security flaw in their software has required as many as 78 individual patches at a cost of $1 million. Indirectly, 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 also 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.

Studies with this level of detail are not available for flaws found in custom software developed in-house or outsourced, but in all cases there is agreement that the earlier in the lifecycle flaws are discovered, the cheaper they are to address. 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 lifecycle. For security defects, the late-stage costs are often much higher due to successful exploits that lead to data theft, sabotage, or other attacks.

Implementation of security testing in the development lifecycle sometimes comes up against a hesitancy to change, but organizations that can overcome this typically realize the immediate cost benefits of identifying and removing vulnerabilities early. Automated source code analysis is the most effective method of security testing at this point, because it allows assessments of any piece of code without requiring a completed application. Most enterprises find it challenging to identify the most appropriate method and resources to implement source code analysis in their development lifecycle. The following three models represent common scenarios currently being used, with pros and cons highlighted to help inform the decision-making process.

Discrete Model:
In this model, developers are responsible for scanning their own individual pieces of code for vulnerabilities before checking it into the central code server or, for more accurate results, they scan the entire application and address the vulnerabilities found in their own code.

PROS:	This model allows developers to catch mistakes that would otherwise have passed through to the next stage of the lifecycle. Costs for quality assurance, maintenance, and security patching should all be reduced if the flaws are properly addressed.
CONS:	Organizations often find that this approach falls short of their requirements because it is difficult to measure results, enforce consistent policies among developers, or demonstrate improvement over time. In addition, the developers often lack the security expertise required to identify, triage, and remediate vulnerabilities effectively.

Distributed Model:
With this approach, a central QA or release engineering team is responsible for analyzing all application source code for vulnerabilities. The raw data from these assessments are then distributed to the programming team, where engineers individually investigate the results and make decisions of what to fix and how.

PROS:	Many organizations start at this level, because it offers a relatively simple method of introducing consistent security testing within existing development structures. The primary benefit of the distributed model over the discreet model is centralized control over the timing and configuration of assessments, as well as regular reporting to measure improvement and return on investment.
CONS:	Because this model relies on individual developers to determine which vulnerabilities are most critical and how best to eliminate them, it typically cannot scale beyond small development teams and small applications.

Centralized Model:
In this model, a central security review team scans the entire application and triages the results to determine a workflow for remediation efforts. They then assign the vulnerabilities in priority order to individual developers – ideally through an existing defect tracking system – for remediation.

PROS:	Leveraging the security expertise of a single review team allows developers to concentrate more on their programming requirements, while they are ultimately able to learn from assessment results and make fewer security errors in future projects. The review team is also in a better position to identify vulnerabilities due to design flaws and policy violations, because they analyze the entire application from a security perspective.
CONS:	The model can be a challenging one for organizations to implement when they are first introducing security into the software lifecycle. The skill set for this level of review may reside outside of the development team, and integrating those skills and necessary resources into the process often requires high-level support.

Although it often requires a higher level of commitment from the organization, the Centralized Model is the most effective and scalable approach for long-term improvement of security in applications during development.

Achieving success with any of these models requires a source code vulnerability analysis solution with extremely high levels of accuracy and broad reporting and management capabilities. Integration with defect tracking systems and development environments is also important to enable smooth implementation with existing procedures.

For information on how the new Ounce 4.0 solution addresses the requirements of security testing during the software development lifecycle, please see Building Security In: An Ounce 4.0 Product Overview.