STRIDE category reference (notes)

• Treat supply-chain and postinstall script execution as high-risk Tampering/Info-Disclosure vectors when modelling package registries and build systems (see Snyk Axios advisory, Mar 2026).
• Model AI/agent capabilities explicitly as assets and privileged actors: agents that can run tools, access files, or automate CI pipelines create new Spoofing, Info Disclosure, and Tampering pathways (Krebs, Mar 2026).

Workflow

Follow a repeatable, light-weight process aligned to the OWASP Threat Modeling Cheat Sheet: decompose the application, identify threats, rank and document mitigations, and validate controls. (OWASP Threat Modeling Cheat Sheet)

Step 1: Enumerate trust boundaries

Identify every point where trust changes, including modern additions:

1. Browser → CDN/Edge — public internet, untrusted
2. Edge → API Routes — authenticated via JWT/OAuth
3. API Routes → Database — service role key, privileged
4. API Routes → External APIs — outbound, mixed trust
5. CI/CD → Package Registry — build-time trust (pinning, lockfiles)
6. Developer Workstation → Registry — local installs can introduce malicious postinstall hooks
7. AI Agent → Local System / Services — agents with filesystem, network, or automation permissions
8. Webhook Ingress → API Routes — inbound, signature-verified

Step 2: Build an asset inventory

Include traditional assets plus supply-chain and AI-specific assets:

Step 3: Apply STRIDE analysis

Systematically check each trust boundary. Example additions and explicit mitigations follow.

Boundary: CI/CD → Package Registry

Boundary: AI Agent → Local System

Step 4: Map abuse paths

Add modern abuse-path patterns discovered in recent research (use as modeling prompts):

• Parser differentials & interpretation bugs: mismatches between parsers or libraries leading to spoofing or tampering (PortSwigger Top 10 Web Hacking Techniques of 2025).
• Protocol misuses (HTTP/2 CONNECT) and cache/chaining attacks: model edge caches and framework-level caching as attack surfaces (PortSwigger).
• Supply-chain dropper via postinstall hooks: attacker publishes malicious package or dependency that executes on npm install (Snyk, Mar 30 2026).
• AI-assisted automation abuse: agent configured to open PRs, run CI, or touch production without adequate approval logs (Krebs, Mar 8 2026).

Example abuse path — supply-chain RAT via dependency:

1. Attacker compromises maintainer account and publishes new package version with malicious dependency
2. CI or developer runs fresh install; postinstall executes dropper
3. Dropper pulls second-stage payload and obtains C2, exfiltrates secrets or implants backdoor

Mitigation chain:

• Lockfile pinning + commit-provenance verification
• CI SCA scanning and alerting for novel/untrusted dependencies
• Short-lived build credentials and secret scanning in builds
• Post-deployment integrity checks and host EDR

Step 5: Prioritize and plan mitigations

Prioritize high-impact, low-effort mitigations first (lockfiles, SCA, RLS, webhook signing). Add CI and developer workflow controls for supply-chain and agent risks.

Examples

Example 1: STRIDE worksheet for a new API endpoint

Threat Model: POST /api/skills/copy

Trust boundary: Authenticated user → API → Database

Example 2: Data flow diagram template

Include CI/CD and agent flows explicitly:

Browser CI/CD Package Registry Developer Workstation AI Agent | | | | | |-- Submit PR ------------>|-- Run tests/installs --->|-- Registry fetch ----->|-- Dev installs libs ------->|-- Agent reads repo ----------> | | |<-- Serve package -------| | |<-- Deploy artifact -------|<-- Build verified -------| | |

Trust boundaries: [Browser ↔ CI/CD] [CI/CD ↔ Registry] [Developer ↔ Registry] [Agent ↔ Local System]

Decision tree

• New feature or endpoint → run STRIDE worksheet before implementation
• Third-party integration or dependency update → map trust boundaries, verify signature scheme, run SCA and lockfile checks
• Introducing an AI agent or automation → model agent as an actor with explicit privileges and audit trails
• Incident response → trace the abuse path, check mitigations, update threat model
• Compliance audit → export threat model as evidence of design process
• If unsure about risk level → rate it higher and mitigate first

Edge cases and gotchas (updated)

1. Trust boundary confusion in serverless — each function invocation is a separate trust context.
2. STRIDE for third-party APIs and registries — you control only your side of the boundary. Document provider guarantees and verify in CI.
3. Threat model drift — models go stale as features ship. Schedule quarterly reviews and re-run when CI, registry, or agent integrations change (OWASP guidance).
4. Supply-chain spike windows — short-lived malicious package versions (e.g., Axios compromise, Mar 2026) can impact any fresh install; prefer reproducible builds and lockfile verification (Snyk, Mar 30 2026).
5. AI-agent automation risk — agents that can run commands, open PRs, or touch CI require limited scopes, explicit operator approvals, and separate secrets stores (Krebs, Mar 8 2026).
6. Parser and protocol-induced edge cases — parser differentials, HTTP/2 CONNECT and cache-chaining attacks are recent research hotspots; model library-level parsing behavior and caches explicitly (PortSwigger Top 10, 2025).
7. Over-modeling low-risk features — apply depth proportional to data sensitivity and exposure.
8. Missing "Repudiation" analysis — audit logging gaps cause real compliance pain.

Evaluation criteria

• All trust boundaries identified and documented, including CI/CD and agents
• Asset inventory covers data at rest, in transit, in processing, and supply-chain artifacts
• STRIDE analysis completed for every trust boundary
• At least two concrete abuse paths documented with mitigation chains
• Mitigation plan prioritized with effort estimates and ownership
• Threat model is version-controlled alongside the codebase
• Quarterly review cadence established, and re-analysis triggered by dependency or agent changes
• Critical and high risks have mitigations in progress or completed
• Data flow diagrams show how data crosses trust boundaries
• Threat model covers both authenticated and unauthenticated attack surfaces