It’s well established that vulnerabilities (or any bug) found later in the development lifecycle are more expensive to remediate. This isn’t simply because it takes the developer time to determine the best way to fix the bug; organizational costs come into play as well.
Think about what happens when a security vulnerability is identified in software already deployed in a customer’s environment. First, teams have to determine the bug’s severity and exploitability. This is followed by a series of meetings with engineering, product management, security, customer support, and business owners to determine corrective action. The choices are:
- Notify customers and, if possible, issue a patch.
- If a simple patch isn’t possible, prioritize fixing the bug in a new release, perhaps by eliminating other desired features from the release.
- Remain silent, schedule the fix for a future release, and hope customers aren’t hacked in the interim.
Once the corrective action is determined, then development can fix the bug, run the refactored code through QA and security testing to ensure the fix didn’t break anything.
IBM (among others) has studied this and determined that a vulnerability discovered in released software costs organizations 100 times more than if the bug was found and fixed during the design phase.
The Development Devil’s Choice
Slow and Safe
When development teams think about finding bugs earlier in the development lifecycle, security testing and scanning tools come to mind. Application Security Testing (AST) tools like static analysis work by building a model of the application’s source code then running rules against the model to identify coding errors that result in security issues. While they will find security problems, they also generate high numbers of false positives. In short, running scans to find bugs slows down the development process.
Fast and Risky
Customers want new features quickly, and the ability to deliver new functionality faster than competitors can win an organization additional revenue and market share. Rapid development methodologies like agile and CI/CD allow organizations to push out multiple builds each day. Adding traditional security scanning to this defeats the purpose of rapid development.
Go Fast. Stay Safe
There is a third way. Security teams know that it is possible to anticipate security issues during the design phase of the development process and avoid security vulnerabilities. Threat modeling exercises identify issues based on the technical stack of the application and provide engineering and operations with guidance and controls to mitigate the risks. This turns required security testing from an exercise of finding vulnerabilities to one of validating that controls were implemented correctly.
Traditional threat modeling can take weeks to complete. Automated threat modeling takes minutes, and translates threats and secure development guidelines into actionable, consistent activities that can be assigned to developers, security, and IT. This allows organizations to meet the requirements of rapid delivery of new software while maintaining secure software.
Learn more in our white paper – The Development Devil’s Choice