Making the Business Case for a Software Security Requirements Program

We make certain assumptions based on the actual cost of finding, fixing, retesting, and validation of remediation of a high/critical vulnerability. Industry experts estimate that cost to be around $4,000 to patch each identified high/critical vulnerability. Some of our clients have quoted numbers closer to $7,000 based on their internal evaluation. In our formulas we will use $2,000 be conservative. Feel free to substitute your company’s own internal cost to fix a vulnerability. We have also developed an Excel spreadsheet to help you enter in your own company’s numbers: Supporting Formulas for Making the Business Case for a Software Security Requirements Program.

Method to validate potential cost savings on existing applications

A very simple method to quickly determine the potential savings of the use of SD Elements would be to select a random set of applications which have recently gone through a pen-test, static code scan or dynamic code scan and have some high/critical findings. Using your selected applications:

• count the number of applications;
• count the number of high/critical vulnerabilities testing identified that you would not have accepted into production without remediation;
• model the applications in your security requirements solution, such as SD Elements and identify how many of the vulnerabilities could have been prevented by correctly implementing the security requirements. Our empirical data suggests 97%-100% of vulnerabilities will be correctly identified by comprehensive security requirements. A more conservative figure would be 90% however you may want to substitute your own calculated number after implementing a software security requirements program on a pilot basis.

Next multiply your company’s average cost of finding, fixing, retesting and validating the fixes by the number of vulnerabilities that could have been prevented.

Real Client Example #1:

A real world example of this value prop comes from a company where our service organization ran a popular commercial dynamic scanner against 1200 applications. There were many findings. During the scanning all high/critical findings were compared to the SD Elements recommendations and 100% of them could have been avoided by using the product. Every single finding correlated to a recommendation.

Cost savings from avoidance of labor associated with cleaning reports from scanners

As a part of using commercial scanners there is a high labor associated with scrubbing through test results to manually validate whether or not each finding is real or a false positive. Normally this cost is unavoidable; however, this cost can be avoided by using software security requirements to prevent developers from introducing them into production from the beginning.

Select a set of applications you have scanned and divide the number of scanning findings by the number of applications. Multiply this number by the cost per minute for an average hand validation of the defect by an expert. This calculation gives you the average cost per application of scanner reports that could be avoided by using software security requirements from the beginning.

Real Client Example #2:

An example is a large medical company that is a client of ours who re-wrote two applications. They use SD Elements on one of them. After completion they ran a commercial dynamic scanner against both applications. The application written without SD Elements had over 800 findings while the application written with SD Elements had zero findings. We have had multiple customers that have created applications and then used code scanning products and/or dynamic scanning products against those applications with zero high or critical findings.

Cost savings from avoidance of remediation efforts associated with Testing findings

As a part of performing testing there is a high cost of remediation associated fixing the vulnerabilities that are found. Simply put, it is very expensive to introduce a vulnerability into production which could have been avoided. Industry analysis from NIST estimated this cost to be thirty three (33) times higher than finding a vulnerability in the design stage. Software requirements when introduced at the beginning of a project enable companies to avoid these costs by providing the appropriate requirements to prevent developers from introducing domain agnostic threats into production from the beginning.

Select a set of applications you have manually tested and determine your average hourly cost for developers to remediate applications; the average number of hours to remediate an application; your average hourly cost of Quality Assurance and Security testing of remediated applications and the average number of hours to validate remediation efforts. These added give you the total cost per application of remediation efforts. If you multiply that number by the likely percentage of avoidable remediation efforts (we use 90% here again) then you get the average cost per application that could be avoided by using software security requirements from the beginning.

Real Customer Example #3:

Multiple customers have created applications using SD Elements and then performed pen testing against those applications with zero high or critical findings and have purchased licenses of SD Elements because of this cost avoidance analysis. The costs can vary wildly for each company as well as the total number of applications in the portfolio which could benefit from the use of the product. We have several clients who have attempted to build something similar to SD Elements internally after identifying that the injection of security requirements into the SDLC would be a major security improvement resulting in significant cost avoidance. In each case, when they found out about SD Elements a pilot program was established followed by a full rollout plan.

Other possible cost savings to consider

There are several other areas where customers are report finding cost savings by implementing a software security requirements program but which are difficult to quantify based on varying project types and industries but you may also want to consider the following:

• The cost to an organization of not knowing what domain agnostic threats your application may be susceptible to and whether you have built in the compensating control
• The cost savings of having your security requirements controlled in one place and distributed to your whole organization (security, development and testing)
• The cost savings of being able to quickly determine if a new threat affects the applications in your organization
• The cost savings of having your pen testing teams focus on domain specific threats instead of domain agnostic threats. For example, your pen testers can focus on making sure the functionality of the application is secure. That a banking application cannot be tricked into processing a loan for someone who doesn’t qualify or that an online shopping application will not process an item for an incorrect price.