@crewpilot/agent 1.0.0 → 2.0.0

package/prompts/skills/assure-threat-model/SKILL.md

@@ -0,0 +1,182 @@
+# Threat Model — STRIDE
+
+> **Pillar**: Assure | **ID**: `assure-threat-model`
+
+## Purpose
+
+Systematic threat modeling using the STRIDE framework. Identifies threats across Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Produces a threat register with risk scores and mitigations that informs design decisions and security reviews.
+
+## Activation Triggers
+
+- "threat model", "stride", "threat analysis", "security architecture"
+- "what could go wrong", "attack vectors", "threat register"
+- Label-gated: automatically invoked by autopilot-worker Phase 2.5d when `needs-threat-model` or `security-sensitive` label detected
+- Routed from `security-auditor` subagent role for architecture-level security analysis
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph threat_model {
+    rankdir=TB;
+    node [shape=box];
+
+    scope [label="Phase 1\nScope & Data Flow"];
+    decompose [label="Phase 2\nComponent Decomposition"];
+    stride [label="Phase 3\nSTRIDE Analysis"];
+    risk [label="Phase 4\nRisk Assessment"];
+    mitigate [label="Phase 5\nMitigation Planning"];
+    register [label="Phase 6\nThreat Register", shape=doublecircle];
+
+    scope -> decompose;
+    decompose -> stride;
+    stride -> risk;
+    risk -> mitigate;
+    mitigate -> register;
+}
+```
+
+### Phase 1 — Scope & Data Flow
+
+1. Define the system boundary — what's being threat-modeled (entire system, single feature, or API surface)
+2. Identify actors: end users, admins, external services, background jobs
+3. Map data flows:
+   - User input → processing → storage → output
+   - Service-to-service communication
+   - External API calls
+4. Identify trust boundaries:
+   - Authenticated vs unauthenticated zones
+   - Internal vs external network
+   - Client-side vs server-side
+   - Different privilege levels
+5. **(Optional) Fetch security context from M365**: If `mcp_workiq_ask_work_iq` is available, query for relevant compliance and security context:
+   - Call `mcp_workiq_accept_eula` with `eulaUrl: "https://github.com/microsoft/work-iq-mcp"` (idempotent)
+   - **Compliance requirements**: `mcp_workiq_ask_work_iq` → "What compliance requirements, security policies, or regulatory constraints apply to {system/feature}? Check emails, docs, and Teams messages."
+   - **Past security discussions**: `mcp_workiq_ask_work_iq` → "What security concerns or vulnerabilities have been discussed about {system/feature} in recent emails and meetings?"
+   - **Architecture decisions**: `mcp_workiq_ask_work_iq` → "What architecture or security design decisions were made about {system/feature} in meetings or design docs?"
+   - Feed this context into the STRIDE analysis to ensure threats are evaluated against the organization's actual compliance posture and known security concerns.
+   - If unavailable, proceed without — the threat model works from code analysis alone.
+
+### Phase 2 — Component Decomposition
+
+1. List each component in the data flow:
+   - Frontend (SPA, mobile app, CLI)
+   - API gateway / load balancer
+   - Application server(s)
+   - Database(s)
+   - Cache layer
+   - Message queue / event bus
+   - External services / third-party APIs
+   - File storage / CDN
+2. For each component, note:
+   - Technology stack
+   - Authentication mechanism
+   - Data stored/processed
+   - Network exposure (public, internal, VPN)
+
+### Phase 3 — STRIDE Analysis
+
+For each component and each data flow crossing a trust boundary, evaluate all six STRIDE categories:
+
+| Category | Threat | Key Questions |
+|----------|--------|---------------|
+| **S**poofing | Identity impersonation | Can an attacker pretend to be another user/service? Is authentication enforced at every entry point? Are tokens/sessions properly validated? |
+| **T**ampering | Data modification | Can data be modified in transit or at rest? Are inputs validated? Is there integrity checking (HMAC, checksums)? Can request parameters be manipulated? |
+| **R**epudiation | Deniability of actions | Are actions logged with sufficient detail? Can a user deny performing an action? Are audit logs tamper-proof? |
+| **I**nformation Disclosure | Data exposure | Can sensitive data leak through error messages, logs, API responses, or side channels? Is PII/secrets encrypted at rest and in transit? |
+| **D**enial of Service | Availability threats | Are there rate limits? Can a single request exhaust resources (memory, CPU, disk)? Are there circuit breakers? Can an attacker trigger expensive operations? |
+| **E**levation of Privilege | Unauthorized access | Can a regular user access admin functions? Are authorization checks at every layer (not just frontend)? Can parameters be manipulated to bypass access controls? |
+
+### Phase 4 — Risk Assessment
+
+For each identified threat, assess:
+
+1. **Likelihood** (1-5): How easy is this to exploit?
+   - 1 = Requires deep insider knowledge + sophisticated tools
+   - 3 = Moderately skilled attacker with publicly available tools
+   - 5 = Trivial exploitation, automated scanners can find it
+2. **Impact** (1-5): What's the damage if exploited?
+   - 1 = Minor inconvenience, no data loss
+   - 3 = Service disruption, limited data exposure
+   - 5 = Full data breach, system compromise, regulatory impact
+3. **Risk Score** = Likelihood × Impact (1-25)
+   - 1-6: Low → Accept or monitor
+   - 7-14: Medium → Mitigate within normal development
+   - 15-25: High/Critical → Block release until mitigated
+
+### Phase 5 — Mitigation Planning
+
+For each threat with risk score ≥ 7:
+
+1. Propose a specific mitigation (not generic "add security")
+2. Classify the mitigation:
+   - **Prevent**: Eliminate the threat entirely (e.g., parameterized queries for SQLi)
+   - **Detect**: Monitor and alert (e.g., anomaly detection for DoS)
+   - **Respond**: Limit damage (e.g., circuit breakers, rate limits)
+   - **Transfer**: Shift risk (e.g., use managed service with SLA)
+3. Estimate implementation effort: Low / Medium / High
+4. Identify which phase of the worker pipeline should implement the mitigation:
+   - Phase 4 (Implementation): Code-level fixes
+   - Phase 5 (Change Mgmt): Configuration changes
+   - Phase 7 (Deploy Guard): Operational checks
+
+### Phase 6 — Threat Register
+
+Compile all findings into a structured threat register and:
+1. Store via `catalyst_knowledge_store` (type: `threat-model`) for future reference
+2. Write as artifact via `catalyst_artifact_write` (phase: `threat-model`)
+3. Feed high-risk items into the Phase 3 plan as mandatory implementation steps
+
+## Tools Required
+
+- `catalyst_knowledge_store` — Store threat model for future reference
+- `catalyst_knowledge_search` — Query past threat models and security findings
+- `catalyst_artifact_write` — Persist threat register as workflow artifact
+- `catalyst_artifact_read` — Read analysis/architecture artifacts for context
+- `catalyst_metrics_complexity` — Identify complex code that may have more attack surface
+- `mcp_workiq_accept_eula` — (optional) Accept Work IQ EULA before first query
+- `mcp_workiq_ask_work_iq` — (optional) Query M365 for compliance requirements, security discussions, and architecture decisions
+
+## Output Format
+
+```
+## [Catalyst → Threat Model (STRIDE)]
+
+### Scope
+**System**: {what's being modeled}
+**Actors**: {user types}
+**Trust Boundaries**: {boundary list}
+
+### Data Flow Diagram
+```
+{text-based data flow: Actor → Component → Data Store → Output}
+```
+
+### Threat Register
+
+| ID | STRIDE | Component | Threat | Likelihood | Impact | Risk | Mitigation | Effort |
+|----|--------|-----------|--------|------------|--------|------|------------|--------|
+| T1 | S      | Auth API  | ...    | 4          | 5      | 20   | ...        | Medium |
+| T2 | T      | ...       | ...    | 3          | 3      | 9    | ...        | Low    |
+| ...| ...    | ...       | ...    | ...        | ...    | ...  | ...        | ...    |
+
+### Risk Summary
+- **Critical** (15-25): {count} threats → Must mitigate before release
+- **Medium** (7-14): {count} threats → Mitigate within sprint
+- **Low** (1-6): {count} threats → Accept/monitor
+
+### Recommended Mitigations (Priority Order)
+1. {T-ID}: {mitigation} — {effort} — Phase {N}
+2. {T-ID}: {mitigation} — {effort} — Phase {N}
+3. ...
+
+### Confidence: {N}/10
+```
+
+## Chains To
+
+- `assure-vulnerability-scan` — Complements STRIDE with OWASP/CWE code-level scanning
+- `assure-review-functional` — Security pass covers code-level implementation of mitigations
+- `strategize-architecture-planner` — Architecture decisions should reference the threat model
+- `insights-knowledge-base` — Past threat models inform future analysis

package/prompts/skills/assure-vulnerability-scan/SKILL.md

@@ -1,146 +1,146 @@
-# Vulnerability Scan
-
-> **Pillar**: Assure | **ID**: `assure-vulnerability-scan`
-
-## Purpose
-
-Security-focused code analysis mapping findings to OWASP Top 10 and CWE Top 25. Provides actionable remediation with severity scoring, not just warnings.
-
-## Activation Triggers
-
-- "security review", "vulnerability scan", "is this secure", "owasp check"
-- "audit for security", "cwe check", "pentest this code"
-- Automatically chained when `code-quality` detects security-adjacent patterns
-
-## Methodology
-
-### Process Flow
-
-```dot
-digraph vulnerability_scan {
-    rankdir=TB;
-    node [shape=box];
-
-    surface [label="Phase 1\nAttack Surface Mapping"];
-    owasp [label="Phase 2\nOWASP Top 10 Scan"];
-    cwe [label="Phase 3\nCWE Pattern Matching"];
-    remediate [label="Phase 4\nRemediation"];
-    deps [label="Phase 5\nDependency Audit"];
-    report [label="Report", shape=doublecircle];
-
-    surface -> owasp;
-    owasp -> cwe;
-    cwe -> remediate;
-    remediate -> deps;
-    deps -> report;
-}
-```
-
-### Phase 1 — Attack Surface Mapping
-1. Identify all entry points: API endpoints, user inputs, file uploads, URL params
-2. Map data flow from input → processing → storage → output
-3. Identify trust boundaries (authenticated vs. unauthenticated, internal vs. external)
-4. List dependencies and their known vulnerability status
-
-### Phase 2 — OWASP Top 10 Scan
-Check each applicable category:
-
-| ID | Category | What to Look For |
-|---|---|---|
-| A01 | Broken Access Control | Missing auth checks, IDOR, privilege escalation |
-| A02 | Cryptographic Failures | Weak hashing, plaintext secrets, poor TLS config |
-| A03 | Injection | SQL/NoSQL/OS/LDAP injection, template injection |
-| A04 | Insecure Design | Missing rate limits, business logic flaws |
-| A05 | Security Misconfiguration | Default creds, verbose errors, unnecessary features |
-| A06 | Vulnerable Components | Known CVEs in dependencies |
-| A07 | Auth Failures | Weak passwords, missing MFA, session fixation |
-| A08 | Data Integrity Failures | Insecure deserialization, unsigned updates |
-| A09 | Logging Failures | Insufficient logging, log injection, PII in logs |
-| A10 | SSRF | Unvalidated URLs, internal network access |
-
-### Phase 3 — CWE Pattern Matching
-Map findings to specific CWE entries (e.g., CWE-79 for XSS, CWE-89 for SQL injection). Include CWE ID in every finding.
-
-### Phase 4 — Remediation
-For each finding:
-1. Explain the vulnerability in plain language
-2. Show the vulnerable code
-3. Provide the fixed code
-4. Explain why the fix works
-5. Rate exploitability: `trivial / moderate / complex`
-
-### Phase 5 — Dependency Audit
-1. Parse dependency manifests (package.json, requirements.txt, go.mod, etc.)
-2. Flag dependencies with known CVEs
-3. Suggest version upgrades with breaking change warnings
-
-## Tools Required
-
-- `codebase` — Read source code and dependency files
-- `terminal` — Run `npm audit`, `pip audit`, or equivalent
-- `fetch` — Check CVE databases for dependency vulnerabilities
-
-## Severity Scoring
-
-<HARD-GATE>
-Do NOT mark a scan as "clean" or "no issues" if any Critical or High severity findings exist.
-Do NOT downgrade severity to avoid blocking a deployment.
-Critical findings MUST be remediated before code is shipped.
-</HARD-GATE>
-
-| Level | Criteria |
-|---|---|
-| **Critical** | Remote code execution, auth bypass, data exfiltration — exploit is trivial |
-| **High** | Significant data exposure, privilege escalation — exploit is moderate |
-| **Medium** | Information disclosure, denial of service — exploit requires chaining |
-| **Low** | Best practice violation with no direct exploit path |
-
-## Output Format
-
-```
-## [Catalyst → Vulnerability Scan]
-
-### Attack Surface
-- Entry points: {N}
-- Trust boundaries: {list}
-- Dependencies: {N} total, {N} flagged
-
-### Findings
-
-#### [{severity}] {OWASP-ID} — {title} (CWE-{NNN})
-**File**: {path}:{line}
-**Vulnerability**: {plain language explanation}
-**Exploitability**: {trivial/moderate/complex}
-**Vulnerable code**:
-\`\`\`{lang}
-{code}
-\`\`\`
-**Remediation**:
-\`\`\`{lang}
-{fixed code}
-\`\`\`
-**Why this fixes it**: {explanation}
-
----
-(repeat per finding)
-
-### Dependency Alerts
-| Package | Current | Vulnerable | Fixed In | CVE |
-|---|---|---|---|---|
-| | | | | |
-
-### Summary
-{critical}/{high}/{medium}/{low} findings | Exploitability: {overall risk}
-```
-
-## Chains To
-
-- `code-quality` — For non-security improvements found during scan
-- `deploy-guard` — Security findings should block deployment
-
-## Anti-Patterns
-
-- Do NOT report theoretical vulnerabilities in unreachable code
-- Do NOT flag every dependency without checking actual CVE relevance
-- Do NOT provide fixes that break functionality to achieve security
-- Do NOT skip the "why this fixes it" explanation — it's educational
+# Vulnerability Scan
+
+> **Pillar**: Assure | **ID**: `assure-vulnerability-scan`
+
+## Purpose
+
+Security-focused code analysis mapping findings to OWASP Top 10 and CWE Top 25. Provides actionable remediation with severity scoring, not just warnings.
+
+## Activation Triggers
+
+- "security review", "vulnerability scan", "is this secure", "owasp check"
+- "audit for security", "cwe check", "pentest this code"
+- Automatically chained when `code-quality` detects security-adjacent patterns
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph vulnerability_scan {
+    rankdir=TB;
+    node [shape=box];
+
+    surface [label="Phase 1\nAttack Surface Mapping"];
+    owasp [label="Phase 2\nOWASP Top 10 Scan"];
+    cwe [label="Phase 3\nCWE Pattern Matching"];
+    remediate [label="Phase 4\nRemediation"];
+    deps [label="Phase 5\nDependency Audit"];
+    report [label="Report", shape=doublecircle];
+
+    surface -> owasp;
+    owasp -> cwe;
+    cwe -> remediate;
+    remediate -> deps;
+    deps -> report;
+}
+```
+
+### Phase 1 — Attack Surface Mapping
+1. Identify all entry points: API endpoints, user inputs, file uploads, URL params
+2. Map data flow from input → processing → storage → output
+3. Identify trust boundaries (authenticated vs. unauthenticated, internal vs. external)
+4. List dependencies and their known vulnerability status
+
+### Phase 2 — OWASP Top 10 Scan
+Check each applicable category:
+
+| ID | Category | What to Look For |
+|---|---|---|
+| A01 | Broken Access Control | Missing auth checks, IDOR, privilege escalation |
+| A02 | Cryptographic Failures | Weak hashing, plaintext secrets, poor TLS config |
+| A03 | Injection | SQL/NoSQL/OS/LDAP injection, template injection |
+| A04 | Insecure Design | Missing rate limits, business logic flaws |
+| A05 | Security Misconfiguration | Default creds, verbose errors, unnecessary features |
+| A06 | Vulnerable Components | Known CVEs in dependencies |
+| A07 | Auth Failures | Weak passwords, missing MFA, session fixation |
+| A08 | Data Integrity Failures | Insecure deserialization, unsigned updates |
+| A09 | Logging Failures | Insufficient logging, log injection, PII in logs |
+| A10 | SSRF | Unvalidated URLs, internal network access |
+
+### Phase 3 — CWE Pattern Matching
+Map findings to specific CWE entries (e.g., CWE-79 for XSS, CWE-89 for SQL injection). Include CWE ID in every finding.
+
+### Phase 4 — Remediation
+For each finding:
+1. Explain the vulnerability in plain language
+2. Show the vulnerable code
+3. Provide the fixed code
+4. Explain why the fix works
+5. Rate exploitability: `trivial / moderate / complex`
+
+### Phase 5 — Dependency Audit
+1. Parse dependency manifests (package.json, requirements.txt, go.mod, etc.)
+2. Flag dependencies with known CVEs
+3. Suggest version upgrades with breaking change warnings
+
+## Tools Required
+
+- `codebase` — Read source code and dependency files
+- `terminal` — Run `npm audit`, `pip audit`, or equivalent
+- `fetch` — Check CVE databases for dependency vulnerabilities
+
+## Severity Scoring
+
+<HARD-GATE>
+Do NOT mark a scan as "clean" or "no issues" if any Critical or High severity findings exist.
+Do NOT downgrade severity to avoid blocking a deployment.
+Critical findings MUST be remediated before code is shipped.
+</HARD-GATE>
+
+| Level | Criteria |
+|---|---|
+| **Critical** | Remote code execution, auth bypass, data exfiltration — exploit is trivial |
+| **High** | Significant data exposure, privilege escalation — exploit is moderate |
+| **Medium** | Information disclosure, denial of service — exploit requires chaining |
+| **Low** | Best practice violation with no direct exploit path |
+
+## Output Format
+
+```
+## [Catalyst → Vulnerability Scan]
+
+### Attack Surface
+- Entry points: {N}
+- Trust boundaries: {list}
+- Dependencies: {N} total, {N} flagged
+
+### Findings
+
+#### [{severity}] {OWASP-ID} — {title} (CWE-{NNN})
+**File**: {path}:{line}
+**Vulnerability**: {plain language explanation}
+**Exploitability**: {trivial/moderate/complex}
+**Vulnerable code**:
+\`\`\`{lang}
+{code}
+\`\`\`
+**Remediation**:
+\`\`\`{lang}
+{fixed code}
+\`\`\`
+**Why this fixes it**: {explanation}
+
+---
+(repeat per finding)
+
+### Dependency Alerts
+| Package | Current | Vulnerable | Fixed In | CVE |
+|---|---|---|---|---|
+| | | | | |
+
+### Summary
+{critical}/{high}/{medium}/{low} findings | Exploitability: {overall risk}
+```
+
+## Chains To
+
+- `code-quality` — For non-security improvements found during scan
+- `deploy-guard` — Security findings should block deployment
+
+## Anti-Patterns
+
+- Do NOT report theoretical vulnerabilities in unreachable code
+- Do NOT flag every dependency without checking actual CVE relevance
+- Do NOT provide fixes that break functionality to achieve security
+- Do NOT skip the "why this fixes it" explanation — it's educational