Threat Models
Purpose
This section contains threat models for the portfolio program’s systems (documentation platform, portfolio app, demo services, CI/CD pipeline surfaces, and integrations).
Threat models are used to:
- identify assets and trust boundaries
- enumerate realistic attack scenarios
- define enforceable controls (preferably automated in CI/CD)
- define validation procedures and evidence expectations
- drive operational readiness (monitoring, incident response, runbooks)
Threat models are a cornerstone of demonstrating enterprise-grade security discipline in a public portfolio.
Scope
In scope
- system-specific threat models (one model per system boundary)
- security controls tied to architecture and pipeline gates
- mitigations with validation steps and evidence expectations
- residual risk statements and review cadence
Out of scope
- generic security advice not tied to a concrete system
- operational “how-to” procedures (belongs in runbooks)
- incident retrospectives (belongs in postmortems)
Prereqs / Inputs
To create or update a threat model, you should have:
- a defined system boundary (what is in scope/out of scope)
- at least one architecture overview or ADR relevant to the system
- a basic understanding of:
- authentication and identity flows (if applicable)
- data flows and storage (even if minimal)
- deployment model and CI pipeline behavior
Recommended supporting artifacts:
- ADRs:
docs/10-architecture/adr/ - Ops runbooks:
docs/50-operations/runbooks/ - DevOps platform docs:
docs/30-devops-platform/
Procedure / Content
How to create a new threat model
-
Create a branch
- Suggested:
docs/threat-model-<system>
- Suggested:
-
Create the model file
- Naming convention:
<system>-threat-model.md
- Location:
docs/40-security/threat-models/
- Naming convention:
-
Author using the threat model template
- Template location (internal-only):
docs/_meta/templates/template-threat-model.md
- Requirements:
- assets, trust boundaries, and entry points are explicit
- each threat includes mitigations and validation steps
- define enforceable SDLC controls (prefer CI gates) where applicable
- Template location (internal-only):
-
Add references
- Reference relevant ADRs and runbooks by path (avoid links to non-existent pages)
-
Validate
pnpm buildmust pass prior to PR- ensure the model is public-safe (no sensitive endpoints, no secrets)
-
Open PR
- include what/why/evidence/no-secrets statement
Threat model review and maintenance
When to update
Update the relevant model when:
- trust boundaries change (new integrations, new hosting posture)
- auth/session behavior changes
- new data flows or storage are introduced
- CI permissions or build chain changes materially
- new externally reachable entry points are added
Residual risk discipline
Every model must include:
- explicit residual risk statements (or “none identified”)
- a review cadence (e.g., quarterly or on major changes)
Validation / Expected outcomes
Threat modeling is effective when:
- security controls are not merely described but enforced
- validation steps are reproducible
- changes to system boundaries trigger corresponding updates
- operational readiness improves (alerts/runbooks exist for key failure modes)
Failure modes / Troubleshooting
- Checklist theater: threats listed without mitigations or validation → require enforceable controls and evidence expectations.
- Overly theoretical: risks not tied to entry points/assets → reframe around concrete scenarios.
- Sensitive detail leakage: internal endpoints or logs included → sanitize, summarize, and remove sensitive details.
References
- Threat model template (internal-only):
docs/_meta/templates/template-threat-model.md - Documentation App threat model:
docs/40-security/threat-models/portfolio-docs-app-threat-model.md - Related domain artifacts:
- ADRs:
docs/10-architecture/adr/ - Runbooks:
docs/50-operations/runbooks/
- ADRs: