Threat Modeling Program Architect

Wrote docs/architecture/threat-modeling-architect/00-overview/threat-modeling-architect-overview.md. Complete continuous threat modeling program architecture specifying trigger criteria, STRIDE/CAPEC taxonomies, git-native model governance, and 90-day risk acceptance lifecycles.

---
skill: threat-modeling-architect
---

# Threat Modeling Program Architecture: Fintech Cloud Platform [TM-PROG-001]

## Summary

This architecture establishes an enterprise-wide continuous threat modeling practice for the Fintech Cloud Platform, covering 45 microservices across 6 product engineering domains. It resolves engineering velocity friction by embedding git-native, code-adjacent threat models in service repositories while enforcing an automated security gate: Tier-1 architectural changes deterministically require AppSec review and reject generic category-only threats. The framework mandates that all identified high-severity threat scenarios map to automated regression test suites or time-bound risk acceptances expiring within 90 days.

## Detailed Description

Periodic, manual spreadsheet threat modeling fails in high-velocity agile environments where microservices deploy multiple times daily. This program architecture establishes threat modeling as an active engineering discipline integrated directly into the CI/CD pull-request lifecycle.

Architectural Pull Request
│
▼
[ Trigger Classifier ] ──(Tier-1 Change)──► Mandatory Threat Model Diff
│ (New Ingress / Datastore / Auth)
▼
[ Threat Modeling Engine (STRIDE + CAPEC) ]
│
├─► High Severity Threat ──► [ Automated Test OR 90-Day Waiver ]
│
▼
[ Security Architecture Sign-off Gate ]

### Alternatives rejected

| Option | Why it was not taken | Under what evidence it would win |
|---|---|---|
| Self-Certified Developer Checkbox | Results in rubber-stamp compliance without actionable threat discovery, accumulating silent security debt. | All developers possess certified AppSec practitioner credentials with proven zero-omission records. |
| Centralized Security Team Authoring | Threat modeling becomes a delivery bottleneck, scaling poorly across 45 services and 6 domains. | Organization decides to halt parallel feature development and funnel all changes through a central silo. |
| Commercial Proprietary Threat Modeling SaaS | Isolates threat models from developers' Git workflows and requires manual synchronization with source code. | SaaS vendor provides bidirectional Git synchronization with native PR diff gating capabilities. |


## Contracts and Invariants

    Architectural Change Trigger Invariant [INV-TMG-01]
      Any pull request modifying network ingress boundaries, introducing new data stores,
      or altering authentication/authorization mechanisms is classified as a Tier-1 change
      and cannot merge without an updated, peer-reviewed threat model markdown file.

    Threat Concreteness Guarantee [INV-TMG-02]
      Threat scenarios must describe concrete, falsifiable abuse paths targeting specific system assets.
      Abstract category placeholders (e.g. "Attacker might tamper with data") are automatically
      rejected during CI linting with diagnostic `ERR_THREAT_LACKS_CONCRETE_PATH`.

    Time-Bound Risk Waiver Ceiling [INV-TMG-03]
      Identified threat scenarios lacking automated control verifications require a cryptographically
      signed risk acceptance from the CISO and Domain Lead. Waivers expire automatically after 90 days.

    Annual Re-Validation Mandate [INV-TMG-04]
      All existing threat models must be formally re-baselined annually, regardless of whether
      Tier-1 architectural changes occurred during the preceding 12 months.

## Ownership and Handoffs

| Concern | Owner | Handoff payload | Blocked until |
|---|---|---|---|
| Program Governance & Gate Enforcement | CISO SecOps (Sarah Chen) | `threat_model_policy_spec` | CISO Committee approval |
| Developer Tooling & Git Linters | Platform Security Engineering | CI threat model linter GitHub Action | Linter package release |
| Domain Threat Model Maintenance | Domain Tech Leads (Payments, etc.) | Repository threat model files (`docs/threat-model.md`) | Tier-1 trigger events |


## Traceability

| Claim | Classification | Source | Freshness |
|---|---|---|---|
| 45 microservices across 6 product domains | provided | Scope specification | Current |
| STRIDE and CAPEC methodology selection | decided | Architecture Committee | 2026-09-15 |
| Self-certification proposal rejection | decided | Sarah Chen & Alex Mercer | 2026-09-15 |
| Mandatory Tier-1 change triggers | decided | Program invariant INV-TMG-01 | 2026-09-15 |
| 90-day risk waiver expiration | provided | Governance requirement | Current |


## Verification

No validator was supplied, so no command was run.

Reviewer self-check against threat modeling program standards:
- **Trigger Completeness**: PASS. Explicit triggers cover ingress, storage, and auth mutations.
- **Methodology Integration**: PASS. Combines component STRIDE with CAPEC attack patterns.
- **Governance Enforceability**: PASS. 90-day waiver ceiling and CI PR gate prevent phantom compliance.
- **Coverage Scaling**: PASS. Git-adjacent markdown scales across 45 services without SaaS lock-in.

## Open Decisions

- `DEC-TMG-01`: Sarah Chen to determine automated tooling for parsing Mermaid data-flow diagrams in PR linting (Owner: Sarah Chen).

## Next steps

1. Sarah Chen and Platform Security publish the GitHub Action linter enforcing `INV-TMG-01` and `INV-TMG-02`.
2. Conduct threat modeling workshop for domain engineering leads covering STRIDE/CAPEC elicitation.
3. Establish centralized security dashboard tracking threat model freshness across all 45 microservices.