Is threat modeling compatible with Agile and DevSecOps?

Is threat modeling compatible with Agile and DevSecOps?

Bryan Sullivan, a Security Program Manager at Microsoft, called threat modeling a “cornerstone of the SDL” during a Black Hat Conference presentation. He calls it a ‘cornerstone’ because a properly executed threat model:

  • Finds architectural and design flaws that are difficult or impossible to detect through other methods.
  • Identifies the most ‘at-risk’ components.
  • Helps stakeholders prioritize security remediation.
  • Gets people thinking about the application attack surface.
  • Drives fuzz testing.
  • Provides the basis for abuse cases as it encourages people to think like an attacker.

In this post, I’ll discuss some common pushback when it comes to conducting threat modeling in the continuous integration / continuous deployment (CI/CD) environment. I’ll then provide advice for integrating threat modeling properly into the CI/CD pipeline, also known as the DevSecOps pipeline.

If you’re not familiar with threat modeling, here’s a YouTube presentation on the Synopsys threat modeling method.

Threat modeling documentation

Yes, threat modeling requires documentation, but that’s not a bad thing.

When teaching threat modeling, a surprisingly common question I hear is “threat modeling requires documentation?” That question is often followed by an explanation that since moving to SAFe and CI/CD processes, firms have disposed of documentation.

This persistent ‘zero documentation in Agile’ myth is based on a misunderstanding of the Agile Manifesto. It is true that the Agile methodology does prioritize working software over written documentation. However, there are a number of design, architecture, and user story artifacts needed to properly communicate commitments and other project parameters to stakeholders.

If the application is mission critical and/or it handles sensitive data, then the project or application threat model is one of the most important artifacts. Architecture diagrams involving the inputs to the threat model are also highly valuable artifacts. The process of creating and maintaining these artifacts—usually a team exercise—is never automatable. This is known as an out-of-band activity.

Learn more about in-line vs. out-of-band activities

Performing threat modeling as an out-of-band activity

There are a number of security activities, including tool-driven static application security testing (SAST) and software composition analysis (SCA). These testing approaches are amenable to automation and fit nicely within an always-deployable paradigm. Threat modeling doesn’t fit into this approach.

Think of threat modeling as you would any other manual process or activity such as sprint planning or bug wash sessions. Threat modeling is a team exercise. Conduct it as an out-of-band activity either before the first development sprint, or as part of ‘sprint 0.’

Maintaining threat modeling artifacts

As with any critical documentation, update the threat model as facts that form its basis change or are clarified during a development activity. The artifact you’ll need to maintain largely depends on the threat model method in use.

4 threat modeling questions to ask before your next Agile sprint

Keep threat modeling artifact(s) in a repository available for team editing (e.g., a wiki or SharePoint site). Ensure that changes are tracked.

Finding issues during threat modeling

Prioritize issues found during threat modeling within the backlog.

Remember, in a continuous development model (Agile or CI/CD), you’re going to be threat modeling as an out-of-band process. Thus, issues found may show up at any time during the threat modeling process. This may mean after development sprints are underway. Write up these issues as user stories and prioritize them on the backlog during a bug wash or sprint planning session—just as any other user story or defect.

It may be necessary to ‘pull the chain and stop the train’ to fix a serious issue found in a threat model.

I was once involved in a threat modeling exercise where we identified that the authentication module in a system handling protected health information (PHI) was seriously broken. The development team was in the middle of one of the last sprints in a release commitment. The current sprint was cancelled and priorities were rearranged.

Since threat modeling involves at least some of the Principals on the development team, it shouldn’t be a surprise to the team if there’s a disruption to resolve a serious security flaw identified through threat modeling.

The bottom line

Threat modeling needs to be a part of CI/CD and Agile processes. There are too many benefits to threat modeling not to conduct this activity on mission critical applications—regardless of the methodology in use for development.

Dig deeper into threat modeling

David Harvey

Posted by

David Harvey

David Harvey

David Harvey, CISSP, is a former principal consultant with Synopsys. David evaluated agile practices, led code reviews, and trained developers on defensive coding and threat modeling. Before joining Synopsys, he worked for UnitedHealth Group, where he co-founded and led a developer-facing software security initiative. David has also worked as an architect and developer at Siemens, Boeing, and Unisys. He learned about software security when the “information superhighway” was just becoming a thing and Fortune 20 companies were starting to bear the brunt of unsanitary design and coding practices that had been de rigueur in the old, segregated, safe “client-server” or “feudal” deployment models.

More from Managing security risks