Threat modeling in DevSecOps means asking four questions about a system as it changes: what are we working on, what can go wrong, what will we do about it, and did we do enough. Keep it small, tie it to pull requests that change trust boundaries, and store the output next to the code.
Why does threat modeling keep failing in fast teams?
The usual failure is size. A two-day workshop produces a diagram and a long list, and then the system changes the next sprint. The model goes stale and nobody trusts it.
The Threat Modeling Manifesto describes threat modeling as analyzing representations of a system to highlight concerns about security and privacy, and says it should happen early and keep happening through the life of the system. It also says the manifesto is methodology agnostic. That is the useful part for pipeline work: you are free to shrink the method until it fits a sprint.
NIST's Secure Software Development Framework (SP 800-218) lists risk modeling, such as threat modeling, attack modeling or attack surface mapping, as a practice for the design stage. It asks for it. It does not ask for a particular ceremony.
What is the smallest useful version?
Run the four questions on one change, not the whole product. A constructed example: a team adds a "share report by link" feature to an internal analytics tool.
- What are we working on? A simple sketch in the pull request: browser, API, report store, link service, recipient.
- What can go wrong? Links that never expire. Links that can be guessed. A report that includes rows the recipient should not see. A link forwarded to someone outside the company.
- What are we going to do? Random 128 bit tokens, 7 day expiry by default, a check that the report is filtered by the creator's permissions at view time, and an audit event on every open.
- Did we do a good enough job? A test that tries an expired token, a test that tries another tenant's token, and a reviewer who was not the author.
That took perhaps thirty minutes, and it produced four tests and two design decisions. A model that does that is working.
When should a pull request trigger a model?
Do not model everything. Pick triggers that signal a changed trust boundary. Reasonable ones:
- A new external integration or a new inbound endpoint.
- A new data store, or new data classes in an existing one.
- A change to authentication, session or authorization logic.
- A new way for untrusted input to reach a parser, a query, a file path or a template.
- A new privileged service account or a widened cloud role.
Put the list in the pull request template as checkboxes. If any box is ticked, the author adds a short threat note to the description or a threats.md file in the service folder. If none is ticked, nothing is needed.
How do the results get into the pipeline?
A model that lives only in a document does not change what ships. Convert each accepted mitigation into something a pipeline can see: a ticket with an owner, a test, a policy check, or a scanner rule. Convert each accepted risk into a dated entry that someone reviews again.
OWASP's Threat Modeling Cheat Sheet makes a related point for cloud systems. It notes that classic techniques such as STRIDE and data flow diagrams need adaptation for shared responsibility, managed services, multi-tenant identity and infrastructure defined as code. So include the infrastructure files in the scope of the model, not just the application code.
How do you know it is working?
Count outcomes, not diagrams. How many design changes came out of models? How many tests were added? How many incidents or pen test findings were in an area with no model? Those numbers tell you where to spend the next hour.
How to check or apply this
- Pick one service with a recent security finding and model its newest feature using the four questions.
- Write the trigger list and add it to the pull request template.
- Store threat notes in the repository, beside the code they describe.
- Turn every mitigation into a test, a ticket or a policy rule with an owner.
- Review accepted risks on a fixed date each quarter.
- After a quarter, compare findings in modeled and unmodeled areas.
Quick check
Do we need a special tool to start?
No. A diagram, the four questions and a pull request template are enough to begin. Tools help later with consistency and reporting.
Who should be in the room?
The author, a reviewer who did not write the change, and someone who knows how the system is deployed. Security staff help most as coaches, not as the only people who model.
Sources
- Threat Modeling Manifesto
- OWASP Threat Modeling Cheat Sheet
- NIST SP 800-218, Secure Software Development Framework
Last reviewed: 18 October 2026.
