Adopting agile in your program comes with inherent benefits around transparency and delivery, but it also often requires changes to other business practices to align with a more iterative way of developing software. Threat modeling helps you determine where to focus your security testing efforts when building your app, so it’s a useful practice. But one of the questions I repeatedly get about threat modeling is, “How does this fit into my existing agile software development process?”
Here are three things you can do to integrate threat modeling into your agile workflow.
Start Early
Threat modeling provides the greatest value to an organization when it’s done early in the software lifecycle. It allows us to identify architectural deficiencies and bugs before they are identified in production. If you are just beginning a new agile project, integrate threat modeling into your kickoff by trying to understand the types of threats and assets that are important to your application.
This doesn’t mean you can’t apply it to an existing project. If you want to do that, make sure to dedicate some time with your stakeholders and team to build a threat model. Expect that you may uncover some technical debt to address during this process.
Reassess Iteratively
Each iteration, you should find yourself going back to your threat model at some point. Sometimes that may require significant changes or additions, and at times you may find yourself making no change at all.
As each iteration kicks off—particularly when you start a new epic or large feature—I find it helpful to ask yourself the following questions to drive the discussion about whether change is needed to your model:
- Do any of these stories change the architecture in any way?
- Do any of these stories handle sensitive assets our model wants to protect?
- Do any of these stories provide a new attack surface to exploit?
Validate Continuously
It’s important to understand what threats exist with our apps, but it’s just as important to mitigate those vulnerabilities and validate that we haven’t left ourselves exposed by missing a potential threat or improperly implementing a mitigation.
Implementing continuous security testing along with other functional and nonfunctional tests is the way we can validate whether our assumptions are correct and that we haven’t left ourselves exposed. Using automation to run SAST or DAST tooling in addition to your functional security tests will help reduce manual testing burdens and ensure that you can validate your security posture continuously.
This a repost of my article on Techwell Insights.
