It’s 2023 and the world of application development is slowly but surely migrating from DevOps to DevSecOps. As you probably know, DevSecOps “automates the integration of security at every phase of the software development lifecycle, from initial design through integration, testing, deployment, and software delivery.”

If you haven’t already migrated from DevOps to DevSecOps, we can give you one more reason that now’s the time to do it.

The DoD Thinks it’s a Good Idea

The U.S. Department of Defense (DoD) thinks DevSecOps is a good idea. So much so that they published the DevSecOps Fundamentals Guidebook: DevSecOps Tools & Activities.

According to the guidebook’s introduction, “The goal of DevSecOps is to improve customer outcomes and mission value through the automation, monitoring, and application of security at every phase of the software lifecycle. Practicing DevSecOps requires an array of purpose-built tools and a wide range of activities that rely on those tools. This document conveys the relationship between each DevSecOps phase, a taxonomy of supporting tools for a given phase, and the set of activities that occur at each phase cross-referenced to the tool(s) that support the specific activity.”

The DoD, which has some of the highest security requirements for the software they use, is a big advocate for DevSecOps. What that means is if you want to sell software to the DoD, and by consequence, create the most secure software, you need to get on board with DevSecOps.

So, where does threat modeling come in?

Threat Modeling is a Key Component of DevSecOps

As things turn out, threat modeling is an ideal facilitator of DevSecOps as it offers the potential to automate security at every phase of the software development lifecycle. And the DoD knows it.

According to the guidebook, the DoD believes “Security is integrated into the core of the DevSecOps phases, weaved into the fabric that touches each phase. This integrated and wrapped approach to security facilitates automated risk characterization, monitoring, and risk mitigation across the totality of the application lifecycle.” Sure sounds like threat modeling to us.

What priority does the DoD place on threat modeling, compared to the other activities it recommends? It’s hard to say definitely, because the guidebook doesn’t say. What we know for sure is that in Table 1, Security Activities Summary and Cross-Reference, a table this is not published in alphabetical order, threat modeling is at the top of the activities list.

Interestingly, threat modeling is not listed in Table 2, Specific Security Tools Common to All DevSecOps Reference Designs. Or is it. If we look down the list of tools in the table, what we see, in essence, are tools that help enable threat modeling.

Here’s a sampling of the tools in the list. Let’s see which ones support threat modeling.

  • Runtime Defense, check
  • Vulnerability Management, check
  • Common Vulnerabilities and Exposures (CVE) Based Security, check
  • Behavior Prevention, check

The guidebook ultimately seems to fill in this gap in Table 3, Plan Phase Tools, where it specifically includes using a threat modeling tool to identify and mitigate specific security issues.

In summary, the DoD thinks DevSecOps is important and threat modeling plays an important role in DevSecOps.

Which Threat Modeling Tool to use?

If you’re not sure where to start your search for a threat modeling tool to use in your DevSecOps pipeline, we think you should consider ThreatModeler. ThreatModeler is a platform that automates almost every aspect of threat modeling in DevSecOps. If you’d like to learn how, please contact us here.