When it comes to developing software, everyone pretty much agrees it’s a good idea to know where the vulnerabilities are in the software BEFORE you deploy it. And using threat modeling is certainly a good option for identifying those vulnerabilities.
In the years before agile, software development typically used the waterfall methodology. “The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks.” With waterfall, software development can be thought of as a left-to-right sequential process.
Shifting Left
This idea of linear software development, coupled with wanting to do things as soon as possible in the process, lead to the notion of “shifting left” when it came to testing. Developers thought it was a good idea to test the software sooner rather than later. But as Devopedia is quick to point out, “Shift Left as a principle started with testing but it’s beginning to be employed in other disciplines such as security and deployment.” In other words, when it comes to using threat modeling, you should also “shift left” and do it sooner in the development process.
There’s just one problem with the idea of shifting left when it comes to threat modeling (or testing or deployment). Hardly anyone uses the linear waterfall method anymore for development and instead uses one of the agile methodologies which is better described visually by a circle, rather than a straight line. Circular software development enables faster feedback and therefore faster iterations. This is, after all, the reason behind agile development.
The CI/CD Pipeline
As the software world shifted from software development to DevOps, the philosophy of “circular” development manifested itself in the form of the CI/CD (continuous integration/continuous deployment) pipeline. You can think of CI/CD as a circle with four stages: 1) Source; 2) Build; 3) Test; and 4) Deploy. And naturally, stage 4 from one deployment leads directly to stage 1 of the next deployment.
This still leaves us with the “shift left” problem when it comes to doing threat modeling in a CI/CD pipeline. There’s nowhere to shift left. Maybe shift counterclockwise? Even with that, if you do it enough you end up back where you started.
We know we want to do threat modeling as early in the development cycle as possible. And even though development is now circular, threat modeling makes the most sense during the Source stage of development.
The Source stage (or Commit stage) is where new features and new code are integrated with the base code. It’s also the stage where the CI/CD pipeline gets triggered by a number of things including changes to the code repository, user-initiated workflows, and automated schedules. There’s really no other stage in the circle that makes sense.
If you’re wondering when’s the best time to do threat modeling in DevOps, now you know. If you’re wondering what’s the best threat modeling tool to integrate with your CI/CD pipeline, it’s ThreatModeler. Now you know that too.