It’s well established that software vulnerabilities (or any bug) found later in the development life cycle 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 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, developers can fix the bug and 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 Developer’s Dilemma: Speed vs. Safety
Slow and safe
When development teams think about finding bugs early in the development life cycle, 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 these will find security problems, they also generate a high number of false positives.
In short, running software scans to find bugs slows down the development process.
Fast and risky
Customers want new features or updates 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. But it’s difficult to ensure product security while releasing software fast unless security is built-in from the beginning.
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 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. Using this approach, organizations can ensure if security controls were implemented or not rather than finding vulnerabilities later.
But traditional threat modeling can take weeks to complete.
On the other hand, automated threat modeling takes significantly less time and translates secure development guidelines into actionable, consistent activities. This allows organizations to meet the timelines for the rapid delivery of new software while maintaining security. In addition, as manual security processes are taken care of by automation, security experts can focus on critical applications.
Download our whitepaper to learn how automation can improve product security and time to market.