<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
<!-- NERF is a trademark of defconxt. -->
---
name: implementing-continuous-threat-modeling
description: >-
  Implement living threat models that evolve with system changes through change-triggered updates, automated drift detection, developer-friendly tooling, and integration with agile development workflows.
domain: cybersecurity
subdomain: threat-modeling
tags:
  - continuous
  - living-threat-model
  - agile
  - devops
  - change-triggered
  - shift-left
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: ["T1195", "T1190", "T1059"]
---

# Implementing Continuous Threat Modeling

## Overview

Continuous threat modeling transforms static threat models into living documents that evolve
with system changes. This technique covers change-triggered updates, developer-friendly
workflows, automated drift detection, and agile integration patterns.

Mode: `[MODE: ARCHITECT]` — Living threat models integrated with development workflows.

## Prerequisites

- Existing threat model baseline
- Version control system (Git)
- CI/CD pipeline (GitHub Actions, GitLab CI)
- Architecture-as-code tooling (pytm, Threagile)
- Python 3.10+

## Key Concepts

### Continuous Threat Modeling Principles

| Principle | Description |
|-----------|-------------|
| Living Documents | Threat models update as code changes |
| Change-Triggered | Architecture changes trigger re-analysis |
| Developer-Friendly | Integrated into existing dev workflows |
| Automated Baselines | Baseline captured and diffed automatically |
| Risk Budget | Teams have a risk budget to manage |

### Change Triggers

| Trigger | Action | Priority |
|---------|--------|----------|
| New external endpoint | Full STRIDE on new component | High |
| Data store change | Re-assess data flow security | High |
| Dependency update | Check for new threat patterns | Medium |
| Auth/authz change | Re-assess trust boundaries | Critical |
| Infrastructure change | Validate network segmentation | High |
| New third-party integration | Full threat analysis | High |

### Integration Points

1. **PR Review**: Threat model diff as PR comment
2. **Sprint Planning**: Risk items in backlog
3. **Architecture Review**: Threat model as input
4. **Incident Response**: Update model with lessons learned
5. **Quarterly Review**: Full model refresh with threat intel

## Workflow

### Step 1: Establish Baseline

```bash
node scripts/agent.js --action baseline --model tm.py --output baseline.json
```

### Step 2: Configure Change Detection

```bash
# Set up file watchers for architecture changes
node scripts/agent.js --action watch --paths "src/,infra/,docker-compose.yml" --output triggers.json
```

### Step 3: Run Incremental Analysis

```bash
# Analyze changes since baseline
node scripts/agent.js --action incremental --baseline baseline.json --changes changes.json
```

### Step 4: Generate Threat Model Diff

```bash
# Produce diff report for PR review
node scripts/agent.js --action diff --baseline baseline.json --current current.json --output diff.json
```

### Step 5: Update Baseline

```bash
node scripts/agent.js --action update-baseline --current current.json --output baseline.json
```

## Verification

- [ ] Baseline threat model captured and versioned
- [ ] Change triggers configured for architecture-significant files
- [ ] CI pipeline runs incremental threat analysis on PRs
- [ ] Threat model diffs posted as PR comments
- [ ] Risk items tracked in sprint backlog
- [ ] Quarterly full refresh scheduled with threat intel update
- [ ] Incident lessons learned feed back into threat model

## References

- [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/)
- [Continuous Threat Modeling — Autodesk](https://www.autodesk.com/trust/security)
- [OWASP Threat Modeling](https://owasp.org/www-community/Threat_Modeling)
- [Agile Threat Modeling](https://martinfowler.com/articles/agile-threat-modelling.html)
