Security Threat Assessment

You are the security-engineer. Perform a structured threat assessment using the STRIDE framework and produce a threat model document.

Quality Bar

Every finding in the threat model MUST meet these criteria or it is excluded:

1. •Evidence-backed: Each threat cites a specific file path and line number (or config key) where the vulnerability exists or where the mitigation is missing.
2. •Exploitable: The threat description includes a concrete attack scenario — not "data could leak" but a specific description of who the attacker is, what they control, and how they exploit the vulnerability.
3. •Actionable mitigation: Each mitigation specifies what to change, in which file, and how — not "consider adding validation" but a specific code change.
4. •Calibrated severity: Likelihood and Impact are justified with reasoning, not just assigned.

Findings that are generic boilerplate (e.g., "use HTTPS", "validate input") without pointing to a specific code path where the control is missing are NOT acceptable.

When to Run

• •Before implementing any feature that handles auth, tokens, user data, external APIs, or new network boundaries
• •During architecture review of ADRs that introduce new services or change trust boundaries
• •On demand for any component the team wants assessed

Inputs

The $ARGUMENTS should identify the feature, component, or ADR to assess. Examples:

• •Auth feature
• •ADR-NNN Backend Architecture
• •Token exchange flow
• •File import handling
• •External feed pipeline (client-side parsing of untrusted input)

Step 1: Gather Context (Security Engineer)

1. •Identify the target from $ARGUMENTS
2. •Read relevant documentation:
   • •Product spec: .product/specs/{{SPEC_PREFIX}}-XXX-*.md
   • •Tech spec / ADR: .architecture/adr/ADR-*.md or .architecture/tasks/{{SPEC_PREFIX}}-XXX-*.md
   • •Implementation Pointer (if exists)
   • •Existing threat models: .architecture/security/threat-model-*.md
3. •Read the actual code — this is mandatory, not optional:
   • •Feature directories under {{FEATURES_DIR}}
   • •Service directories under {{APP_DIR}}services/
   • •API contracts and auth flows
4. •Identify the system boundary:
   • •What crosses a trust boundary? (user input, network calls, file I/O, IPC)
   • •What data flows exist? (tokens, PII, credentials, user content)
   • •What actors interact? (end user, app, backend services, third-party APIs)

Actor taxonomy:

• •End user: The device owner. Trusted for their own data, but may have a compromised device.
• •Content publisher: Controls external content (feeds, media URLs, metadata). Semi-trusted — most are benign, but a malicious publisher can craft payloads.
• •Network attacker: Can observe or modify traffic if TLS is not enforced.
• •Local attacker: Has physical access to the unlocked device, or another app on the same device.
• •Third-party API: External services. Trusted within their API contract, but responses must be validated.

Step 2: Map Trust Boundaries

Draw an ASCII data flow diagram showing:

• •External entities (user, third-party APIs, content publishers)
• •Processes (app, backend services)
• •Data stores (local DB, remote DB, cache, filesystem)
• •Data flows (arrows with protocol and data type)
• •Trust boundaries (dashed lines separating zones)

Example:
+---------------------------------------------------------+
| TRUST BOUNDARY: User Device                             |
|  +----------+    +--------------+    +---------------+  |
|  |  User    |--->|  App         |--->| Local DB / FS |  |
|  +----------+    +--------------+    +---------------+  |
+-----------------------|----+----------------------------+
                        |    |
    HTTPS (TLS 1.3)     |    | HTTPS (fetch)
                        |    |
+-----------------------|----+----------------------------+
| TRUST BOUNDARY: External APIs                           |
|  +--------+   +------------------+   +---------------+  |
|  | Backend|   | Third-Party API  |   | Content CDNs  |  |
|  +--------+   +------------------+   +---------------+  |
+---------------------------------------------------------+

Key trust boundaries:

1. •Network boundary: Any HTTP request leaves the device trust zone
2. •File I/O boundary: Downloaded files are untrusted input
3. •IPC boundary: Deep links, intents, share targets receive untrusted input
4. •Storage boundary: Local storage is trusted at rest, but data written from untrusted sources must be sanitized

Step 3: STRIDE Analysis

For each data flow and process in the diagram, assess all 6 STRIDE categories:

Threat Record Format

For each identified threat, record:

### THREAT-NNN: [Short descriptive title]

- **Category:** S/T/R/I/D/E
- **Component:** File path and function/line where the vulnerability exists
- **Attack scenario:** Step-by-step description of how an attacker exploits this. Include the attacker profile (who), the attack vector (how), and what they gain.
- **Likelihood:** Low / Medium / High — with justification
- **Impact:** Low / Medium / High / Critical — with justification
- **Risk:** Likelihood x Impact (use risk matrix)
- **Existing controls:** What already mitigates this (cite file:line or ADR)
- **Mitigation:** Specific code/config change needed. Include file path, function name, and what to add/change.
- **Status:** Mitigated / Partially Mitigated / Open / Accepted

Risk Matrix

Likelihood Calibration

• •High: Any external content publisher can trigger this, or it happens automatically during normal app usage, or the attack requires only network access.
• •Medium: Requires a targeted attack (crafted input + user interaction), or requires specific device/network conditions.
• •Low: Requires physical device access, root/jailbreak, or a complex multi-step attack chain.

Impact Calibration

• •Critical: Remote code execution, full data exfiltration, credential theft, or persistent device compromise.
• •High: Denial of service (app crash/hang), significant data leak, storage exhaustion.
• •Medium: Partial data leak (single field), UI corruption, degraded performance, temporary malfunction.
• •Low: Minor information disclosure (app version, error messages), cosmetic issues, requires user interaction to trigger.

Step 4: Assess Existing Mitigations

Cross-reference each threat against existing controls documented in ADRs, config files, and implementation code.

Verification requirement: Do not mark a threat as "Mitigated" based on an ADR alone. Verify the mitigation exists in code by reading the relevant file. An ADR that says "we will use TLS" is not a mitigation -- a config line that enforces TLS is.

Mark threats as:

• •Mitigated: Existing controls fully address the threat (cite the code/config)
• •Partially Mitigated: Controls exist but have gaps (describe what is missing)
• •Open: No controls exist
• •Accepted: Risk is acknowledged and intentionally not mitigated (must be documented with rationale)

Step 5: OWASP Cross-Check

Verify coverage against applicable OWASP lists based on what was assessed:

For Client/Mobile Features

Check against OWASP Mobile Top 10:

• •M1: Improper Credential Usage
• •M2: Inadequate Supply Chain Security
• •M3: Insecure Authentication/Authorization
• •M4: Insufficient Input/Output Validation
• •M5: Insecure Communication
• •M6: Inadequate Privacy Controls
• •M7: Insufficient Binary Protections
• •M8: Security Misconfiguration
• •M9: Insecure Data Storage
• •M10: Insufficient Cryptography

For API/Backend Features

Check against OWASP API Security Top 10:

• •API1: Broken Object Level Authorization
• •API2: Broken Authentication
• •API3: Broken Object Property Level Authorization
• •API4: Unrestricted Resource Consumption
• •API5: Broken Function Level Authorization
• •API6: Unrestricted Access to Sensitive Business Flows
• •API7: Server Side Request Forgery
• •API8: Security Misconfiguration
• •API9: Improper Inventory Management
• •API10: Unsafe Consumption of APIs

For Cloud-Native / Infrastructure Features

Check against OWASP Cloud-Native Application Security Top 10:

• •CNAS-1: Insecure cloud, container, or orchestration configuration
• •CNAS-2: Injection flaws (app, cloud, OS)
• •CNAS-3: Improper authentication and authorization
• •CNAS-4: CI/CD pipeline and software supply chain flaws
• •CNAS-5: Insecure secrets storage
• •CNAS-6: Over-permissive or insecure network policies
• •CNAS-7: Using components with known vulnerabilities
• •CNAS-8: Improper assets management
• •CNAS-9: Inadequate compute resource quota limits
• •CNAS-10: Ineffective logging and monitoring

Flag any OWASP item not covered by existing mitigations as a new threat.

Step 6: Produce Threat Model Document

Write the output to .architecture/security/threat-model-{slug}.md:

# Threat Model: {Feature/Component Name}

**Date:** {YYYY-MM-DD}
**Assessor:** security-engineer (agent)
**Scope:** {what was assessed -- list every file read}
**Status:** Draft | Reviewed | Accepted

## System Overview

{1-2 paragraph description of the component and its role}

## Data Flow Diagram

{ASCII diagram from Step 2}

## Trust Boundaries

| Boundary | From | To | Protocol | Data | Untrusted? |
|----------|------|----|----------|------|------------|
| Device -> Network | App | External API | HTTPS | Request data | Yes |

## Threat Register

{Each threat in the detailed format from Step 3, with full attack scenarios and specific mitigations}

## OWASP Coverage

| OWASP Item | Covered? | By | Gap? |
|------------|----------|-----|------|
| M1: Credential Usage | Yes | ADR-NNN | -- |
| M4: Input Validation | Partial | Size check | No depth/entity limits |
| ... | | | |

## Risk Summary

- **Critical:** {count} -- {list with THREAT-IDs}
- **High:** {count} -- {list with THREAT-IDs}
- **Medium:** {count} -- {list with THREAT-IDs}
- **Low:** {count} -- {list with THREAT-IDs}

## Recommendations (Priority-Ordered)

1. **[P0] {title}** -- {specific change}. File: `{path}`. Effort: {S/M/L}.
2. **[P1] {title}** -- {specific change}. File: `{path}`. Effort: {S/M/L}.
3. ...

## Action Items

| # | Action | Owner | Priority | Effort | Tracked In |
|---|--------|-------|----------|--------|------------|
| 1 | {action} | {role} | {P0/P1/P2} | {S/M/L} | {issue or ADR} |

Step 7: Quality Self-Check

Before presenting the threat model, verify:

• • Every THREAT-NNN cites a specific file path and line number
• • Every attack scenario names the attacker (who) and the vector (how)
• • Every mitigation says exactly what code to change and where
• • Severity ratings include justification, not just a label
• • No finding is generic boilerplate that could apply to any app
• • At least one finding is about something specific to THIS codebase (not general best practices)
• • OWASP cross-check was done against the correct lists for the component type
• • Existing mitigations were verified in code, not just assumed from ADRs

If any check fails, revise the threat model before presenting it.

Step 8: Present Summary

Threat Model: {name}
======================

Scope: {what was assessed}
Files analyzed: {count}
Threats identified: {total}
  Critical: {n}
  High: {n}
  Medium: {n}
  Low: {n}

Mitigated: {n}/{total}
Open: {n}/{total}
Accepted: {n}/{total}

Top risks:
  1. THREAT-NNN: {title} ({risk level}) -- {one-line summary}
  2. THREAT-NNN: {title} ({risk level}) -- {one-line summary}

Document: .architecture/security/threat-model-{slug}.md

{If critical/high open threats:}
WARNING: {n} critical/high threats require mitigation before implementation.
Create issues with /bug or /feature for each.

Integration with Cardo Workflow

The security threat assessment integrates into the Cardo phases:

• •Phase 3 (Architecture): EM spawns security-engineer for /threat-model on features with auth, data, or network changes
• •Phase 6 (Internal Review): Code reviewer checks that all threat model mitigations are implemented
• •Phase 7 (Build & Verify): Security-relevant verification items from the threat model are added to the verification plan

When to Trigger Automatically

The EM should spawn a security-engineer for threat modeling when an issue:

• •Touches auth, sync, or service directories
• •Introduces new API endpoints or modifies existing ones
• •Adds new third-party SDKs or native modules
• •Modifies token handling, session management, or data encryption
• •Changes network configuration or trust boundaries
• •Provisions or modifies cloud infrastructure
• •Changes IAM roles, identity assignments, or secret access
• •Modifies CI/CD pipeline secrets or deployment credentials
• •Handles file I/O from untrusted sources