For decades, software security organizations and those that assure security have built processes and procedures around waterfall software development practices. This has often led to security testing being “bolted on” at the end of the process.
In addition, many organizations have seen the rise of mindless information security assurance, whereby engineers avoid assessing, understanding, or dealing with the actual security issues with an application and instead rely on checklist items only.
These tactics mean defects aren’t caught until later stages, which leads to release delays and misappropriating resources to secure low-priority items on the checklist or not identifying application-specific vulnerabilities not covered under the checklist. Sure, plenty of good security testing still happens at the end of the process, but security testing can be completed much more efficiently, effectively, and inexpensively by having security testers adopt agile best practices.
Strong development organizations need to coach their security programs and testers to prioritize analysis and risk, much like we do stories on an agile storyboard, and avoid falling into the trap of everything being a top priority. This allows our development teams to better incorporate security defects with other feature work.
Threat models can be one of the most helpful tools in a tester’s kit when getting started. Threat modeling enables security teams to better understand the actual threats and potential risks that are unique to that application. This allows prioritization and decision-making to be made rationally, with all the information on the table—the alternative being knee-jerk security with no support.
Security testers should avoid attempts to “boil the ocean” and break down security testing, assessment, and validation incrementally. Building a secure application is a moving target. With new tools and vulnerabilities being identified every day, our goal should not be about having a perfect solution, but rather a solution that’s adopted using continuous security principles and is continually improving its security posture over time.
The idea of test automation and “shifting left” has been a recurring theme of the testing community over the past year, yet those in the security testing community have not yet jumped on board. We should adopt automation and integrate security testing into our DevOps pipelines to ensure our security-based nonfunctional requirements are validated in the same way we analyze our functional ones. By shifting security left, developers and security testers can have conversations about security far earlier in the development lifecycle and reduce costly late-stage remediation.
Development teams have fully adopted agile, and now it’s time to bring our security testers along for the ride so they can enable faster delivery, too.
