claude-code-workflow 7.2.26 → 7.2.28

package/.claude/skills/security-audit/phases/03-threat-modeling.md

@@ -0,0 +1,180 @@
+# Phase 3: Threat Modeling (STRIDE)
+
+Map STRIDE threat categories to architecture components, identify trust boundaries, and assess attack surface.
+
+## Objective
+
+- Apply the STRIDE threat model to the project architecture
+- Identify trust boundaries between system components
+- Assess attack surface area per component
+- Cross-reference with Phase 1 and Phase 2 findings
+
+## STRIDE Categories
+
+| Category | Threat | Question | Typical Targets |
+|----------|--------|----------|-----------------|
+| **S** - Spoofing | Identity impersonation | Can an attacker pretend to be someone else? | Auth endpoints, API keys, session tokens |
+| **T** - Tampering | Data modification | Can data be modified in transit or at rest? | Request bodies, database records, config files |
+| **R** - Repudiation | Deniable actions | Can a user deny performing an action? | Audit logs, transaction records, user actions |
+| **I** - Information Disclosure | Data leakage | Can sensitive data be exposed? | Error messages, logs, API responses, storage |
+| **D** - Denial of Service | Availability disruption | Can the system be made unavailable? | API endpoints, resource-intensive operations |
+| **E** - Elevation of Privilege | Unauthorized access | Can a user gain higher privileges? | Role checks, admin routes, permission logic |
+
+## Execution Steps
+
+### Step 1: Architecture Component Discovery
+
+Identify major system components by scanning project structure.
+
+```bash
+# Identify entry points (API routes, CLI commands, event handlers)
+grep -rlE '(app\.(get|post|put|delete|patch|use)|router\.|@app\.route|@router\.)' \
+  --include='*.ts' --include='*.js' --include='*.py' . || true
+
+# Identify data stores (database connections, file storage)
+grep -rlE '(createConnection|mongoose\.connect|sqlite|redis|S3|createClient)' \
+  --include='*.ts' --include='*.js' --include='*.py' . || true
+
+# Identify external service integrations
+grep -rlE '(fetch|axios|http\.request|requests\.(get|post)|urllib)' \
+  --include='*.ts' --include='*.js' --include='*.py' . || true
+
+# Identify auth/session components
+grep -rlE '(jwt|passport|session|oauth|bcrypt|argon2|crypto)' \
+  --include='*.ts' --include='*.js' --include='*.py' . || true
+```
+
+### Step 2: Trust Boundary Identification
+
+Map trust boundaries in the system:
+
+1. **External boundary**: User/browser <-> Application server
+2. **Service boundary**: Application <-> External APIs/services
+3. **Data boundary**: Application <-> Database/storage
+4. **Internal boundary**: Public routes <-> Authenticated routes <-> Admin routes
+5. **Process boundary**: Main process <-> Worker/subprocess
+
+For each boundary, document:
+- What crosses the boundary (data types, credentials)
+- How the boundary is enforced (middleware, TLS, auth)
+- What happens when enforcement fails
+
+### Step 3: STRIDE per Component
+
+For each discovered component, systematically evaluate all 6 STRIDE categories:
+
+**Spoofing Analysis**:
+- Are authentication mechanisms in place at all entry points?
+- Can API keys or tokens be forged or replayed?
+- Are session tokens properly validated and rotated?
+
+**Tampering Analysis**:
+- Is input validation applied before processing?
+- Are database queries parameterized?
+- Can request bodies or headers be manipulated to alter behavior?
+- Are file uploads validated for type and content?
+
+**Repudiation Analysis**:
+- Are user actions logged with sufficient detail (who, what, when)?
+- Are logs tamper-proof or centralized?
+- Can critical operations (payments, deletions) be traced to a user?
+
+**Information Disclosure Analysis**:
+- Do error responses leak stack traces or internal paths?
+- Are sensitive fields (passwords, tokens) excluded from logs and API responses?
+- Is PII properly handled (encryption at rest, masking in logs)?
+- Do debug endpoints or verbose modes expose internals?
+
+**Denial of Service Analysis**:
+- Are rate limits applied to public endpoints?
+- Can resource-intensive operations be triggered without limits?
+- Are file upload sizes bounded?
+- Are database queries bounded (pagination, timeouts)?
+
+**Elevation of Privilege Analysis**:
+- Are role/permission checks applied consistently?
+- Can horizontal privilege escalation occur (accessing other users' data)?
+- Can vertical escalation occur (user -> admin)?
+- Are admin/debug routes properly protected?
+
+### Step 4: Attack Surface Assessment
+
+Quantify the attack surface:
+
+```
+Attack Surface = Sum of:
+  - Number of public API endpoints
+  - Number of external service integrations
+  - Number of user-controllable input points
+  - Number of privileged operations
+  - Number of data stores with sensitive content
+```
+
+Rate each component:
+- **High exposure**: Public-facing, handles sensitive data, complex logic
+- **Medium exposure**: Authenticated access, moderate data sensitivity
+- **Low exposure**: Internal only, no sensitive data, simple operations
+
+## Output
+
+- **File**: `threat-model.json`
+- **Location**: `${WORK_DIR}/threat-model.json`
+- **Format**: JSON
+
+```json
+{
+  "phase": "threat-modeling",
+  "timestamp": "ISO-8601",
+  "framework": "STRIDE",
+  "components": [
+    {
+      "name": "Component name",
+      "type": "api_endpoint|data_store|external_service|auth_module|worker",
+      "files": ["path/to/file.ts"],
+      "exposure": "high|medium|low",
+      "trust_boundaries": ["external", "data"],
+      "threats": {
+        "spoofing": {
+          "applicable": true,
+          "findings": ["Description of threat"],
+          "mitigations": ["Existing mitigation"],
+          "gaps": ["Missing mitigation"]
+        },
+        "tampering": { "applicable": true, "findings": [], "mitigations": [], "gaps": [] },
+        "repudiation": { "applicable": true, "findings": [], "mitigations": [], "gaps": [] },
+        "information_disclosure": { "applicable": true, "findings": [], "mitigations": [], "gaps": [] },
+        "denial_of_service": { "applicable": true, "findings": [], "mitigations": [], "gaps": [] },
+        "elevation_of_privilege": { "applicable": true, "findings": [], "mitigations": [], "gaps": [] }
+      }
+    }
+  ],
+  "trust_boundaries": [
+    {
+      "name": "Boundary name",
+      "from": "Component A",
+      "to": "Component B",
+      "enforcement": "TLS|auth_middleware|API_key",
+      "data_crossing": ["request bodies", "credentials"],
+      "risk_level": "high|medium|low"
+    }
+  ],
+  "attack_surface": {
+    "public_endpoints": 0,
+    "external_integrations": 0,
+    "input_points": 0,
+    "privileged_operations": 0,
+    "sensitive_data_stores": 0,
+    "total_score": 0
+  },
+  "summary": {
+    "components_analyzed": 0,
+    "threats_identified": 0,
+    "by_stride": { "S": 0, "T": 0, "R": 0, "I": 0, "D": 0, "E": 0 },
+    "high_exposure_components": 0
+  }
+}
+```
+
+## Next Phase
+
+Proceed to [Phase 4: Report & Tracking](04-report-tracking.md) with the threat model to generate the final scored audit report.

package/.claude/skills/security-audit/phases/04-report-tracking.md

@@ -0,0 +1,177 @@
+# Phase 4: Report & Tracking
+
+Generate scored audit report, compare with previous audits, and track trends.
+
+## Objective
+
+- Calculate security score from all phase findings
+- Compare with previous audit results (if available)
+- Generate date-stamped report in `.workflow/.security/`
+- Track improvement or regression trends
+
+## Prerequisites
+
+- Phase 1: `supply-chain-report.json`
+- Phase 2: `owasp-findings.json`
+- Phase 3: `threat-model.json`
+- Previous audit: `.workflow/.security/audit-report-*.json` (optional)
+
+## Execution Steps
+
+### Step 1: Aggregate Findings
+
+Collect all findings from phases 1-3 and classify by severity.
+
+```
+All findings =
+  supply-chain-report.findings
+  + owasp-findings.findings
+  + threat-model threats (where gaps exist)
+```
+
+### Step 2: Calculate Score
+
+Apply scoring formula from [specs/scoring-gates.md](../specs/scoring-gates.md):
+
+```
+Base score = 10.0
+
+For each finding:
+  penalty = severity_weight / total_files_scanned
+  - Critical: weight = 10  (each critical finding has outsized impact)
+  - High:     weight = 7
+  - Medium:   weight = 4
+  - Low:      weight = 1
+
+Weighted penalty = SUM(finding_weight * count_per_severity) / normalization_factor
+Final score = max(0, 10.0 - weighted_penalty)
+
+Normalization factor = max(10, total_files_scanned)
+```
+
+**Score interpretation**:
+
+| Score | Rating | Meaning |
+|-------|--------|---------|
+| 9-10 | Excellent | Minimal risk, production-ready |
+| 7-8 | Good | Acceptable risk, minor improvements needed |
+| 5-6 | Fair | Notable risks, remediation recommended |
+| 3-4 | Poor | Significant risks, remediation required |
+| 0-2 | Critical | Severe vulnerabilities, immediate action needed |
+
+### Step 3: Gate Evaluation
+
+**Daily quick-scan gate** (Phase 1 only):
+- PASS: score >= 8/10
+- FAIL: score < 8/10 -- block deployment or flag for review
+
+**Comprehensive audit gate** (all phases):
+- For initial/baseline: PASS if score >= 2/10 (establishes baseline)
+- For subsequent: PASS if score >= previous_score (no regression)
+- Target: score >= 7/10 for production readiness
+
+### Step 4: Trend Comparison
+
+```bash
+# Find previous audit reports
+ls -t .workflow/.security/audit-report-*.json 2>/dev/null | head -5
+```
+
+Compare current vs. previous:
+- Delta per OWASP category
+- Delta per STRIDE category
+- New findings vs. resolved findings
+- Overall score trend
+
+### Step 5: Generate Report
+
+Write the final report with all consolidated data.
+
+## Output
+
+- **File**: `audit-report-{YYYY-MM-DD}.json`
+- **Location**: `.workflow/.security/audit-report-{YYYY-MM-DD}.json`
+- **Format**: JSON
+
+```json
+{
+  "report": "security-audit",
+  "version": "1.0",
+  "timestamp": "ISO-8601",
+  "date": "YYYY-MM-DD",
+  "mode": "comprehensive|quick-scan",
+  "score": {
+    "overall": 7.5,
+    "rating": "Good",
+    "gate": "PASS|FAIL",
+    "gate_threshold": 8
+  },
+  "findings_summary": {
+    "total": 0,
+    "by_severity": { "critical": 0, "high": 0, "medium": 0, "low": 0 },
+    "by_phase": {
+      "supply_chain": 0,
+      "owasp": 0,
+      "stride": 0
+    },
+    "by_owasp": {
+      "A01": 0, "A02": 0, "A03": 0, "A04": 0, "A05": 0,
+      "A06": 0, "A07": 0, "A08": 0, "A09": 0, "A10": 0
+    },
+    "by_stride": { "S": 0, "T": 0, "R": 0, "I": 0, "D": 0, "E": 0 }
+  },
+  "top_risks": [
+    {
+      "rank": 1,
+      "title": "Most critical finding",
+      "severity": "critical",
+      "source_phase": "owasp",
+      "remediation": "How to fix",
+      "effort": "low|medium|high"
+    }
+  ],
+  "trend": {
+    "previous_date": "YYYY-MM-DD or null",
+    "previous_score": 0,
+    "score_delta": 0,
+    "new_findings": 0,
+    "resolved_findings": 0,
+    "direction": "improving|stable|regressing|baseline"
+  },
+  "phases_completed": ["supply-chain-scan", "owasp-review", "threat-modeling", "report-tracking"],
+  "files_scanned": 0,
+  "remediation_priority": [
+    {
+      "priority": 1,
+      "finding": "Finding title",
+      "effort": "low",
+      "impact": "high",
+      "recommendation": "Specific action"
+    }
+  ]
+}
+```
+
+## Report Storage
+
+```bash
+# Ensure directory exists
+mkdir -p .workflow/.security
+
+# Write report with date stamp
+DATE=$(date +%Y-%m-%d)
+cp "${WORK_DIR}/audit-report.json" ".workflow/.security/audit-report-${DATE}.json"
+
+# Also maintain latest copies of phase outputs
+cp "${WORK_DIR}/supply-chain-report.json" ".workflow/.security/" 2>/dev/null || true
+cp "${WORK_DIR}/owasp-findings.json" ".workflow/.security/" 2>/dev/null || true
+cp "${WORK_DIR}/threat-model.json" ".workflow/.security/" 2>/dev/null || true
+```
+
+## Completion
+
+After report generation, output skill completion status per the Completion Status Protocol:
+
+- **DONE**: All phases completed, report generated, score calculated
+- **DONE_WITH_CONCERNS**: Report generated but score below target or regression detected
+- **BLOCKED**: Phase data missing or corrupted