Imported from danielvm-git/bigpowers (.copilot/skills/security-review/SKILL.md). Install upstream with npx skills add danielvm-git/bigpowers --skill security-review. Copyright stays with the author.

story: e45s41

story: e26s01

story: e26s02

story: e26s03

story: e26s04

story: e26s05

story: e26s06

story: e26s07

story: e45s26

Security Review

HARD GATE — Requires git context (branch with merge-base or diff). Never writes files outside specs/security/. Findings below confidence 8/10 are suppressed. Pre-flight: git rev-parse HEAD >/dev/null 2>&1

Parallel worktree mode (e45s18)

When running alongside audit-code, use isolated worktrees so scans do not race on the same index:

bash scripts/lib/parallel-review-worktrees.sh security-review

Each check gets a detached worktree at .bigpowers/worktrees/review-<name>/; reports still write only under specs/security/.

5-phase scan

Categories

Covered: SQLi, XSS, SSRF, command injection, auth bypass, unsafe deserialization, path traversal, IDOR, crypto flaws, secrets exposure, template injection, NoSQLi

CWE mapping mandate (e45s26)

Every new detection rule added to this skill MUST:

1. Map to a CWE ID in REFERENCE-vuln-categories.md (e.g. SQLi → CWE-89, XSS → CWE-79).
2. Ship two fixture pairs under skills/security-review/fixtures/:
   • Positive — minimal code the rule MUST flag (vulnerable pattern present).
   • Negative — structurally similar code the rule MUST NOT flag (safe pattern / false-positive guard).

Before merging a new category, run both fixtures through the detection guidance and confirm positive flags / negative passes.

SQL-safety doctrine (e45s41 — proven authorship)

Formal rule for SQL injection classification:

Provenance test: If the agent cannot prove the query string was authored entirely by the developer (no attacker-reachable interpolation), treat as vulnerable. Hardcoded SQL in migrations, seeds, and admin scripts is safe; anything reachable from HTTP/CLI/user input is not.

BCP Plus Integration

This skill maps to BCP Plus dimension 12 (Security & Compliance). When BCP Plus sizing is active, the threat model categories above correspond to sub-elements within dimension 12. The NFR Gate rule applies: standard-expectation items (e.g., "use HTTPS", "hash passwords") score 0 with a one-line rationale; only above-standard security requirements contribute to the dimension 12 count. See docs/references/bcp-plus.md for the full 13-dimension framework and NFR Gate pattern.

Integration points

Report format

Each finding: File:Line — Severity — Category

• Description: how the vulnerability manifests
• Exploit scenario: concrete attack path
• Recommendation: fix with code example

Reference files

• Vuln categories — detection guidance per vuln type
• False positives — hard exclusions + precedent
• Confidence rubric — scoring methodology (0–10)

Verify

→ verify: test -d specs/security && test -f scripts/lib/parallel-review-worktrees.sh && bash scripts/verify-cwe-fixture-sync.sh >/dev/null && git rev-parse HEAD >/dev/null 2>&1

Confidence Scoring Rubric

Every finding that survives Phase 4 false-positive filtering receives a confidence score from 1 (speculative) to 10 (certain). Only findings ≥ 8 are reported.

Score 9–10: Certain Exploit Path

Criteria:

• Concrete, testable exploit with clear reproduction steps
• No assumptions about uncommon configurations
• No chain of multiple unlikely conditions
• Attacker has full control over the input vector

Examples:

• User-supplied SQL in a SELECT statement with no parameterization
• os.system(f"rm {user_path}") where user controls the path
• Pickle deserialization of user-supplied data without any wrapping

Severity: HIGH

Score 8: Clear Vulnerability Pattern

Criteria:

• Well-known vulnerability pattern with standard exploitation method
• Requires specific conditions but conditions are commonly met
• Exploitability is well-documented in OWASP / CVE databases

Examples:

• JWT without signature verification in authentication middleware
• SSRF where attacker controls the full URL including host
• Hardcoded AWS secret key in source code

Severity: HIGH or MEDIUM

Score 7: Suspicious Pattern

Criteria:

• Unusual code that may indicate a vulnerability
• Requires specific conditions that may not be present
• Alternative secure interpretation is equally likely
• Defense-in-depth concern rather than direct exploit

Examples:

• A function accepting user input that passes through multiple layers before reaching a sink (unclear if sanitized)
• Custom encryption implementation (likely weak, but may not process sensitive data)
• Path construction that looks safe but has a subtle bypass

Severity: LOW or suppress

Score < 7: Do Not Report

Criteria:

• Theoretical concern without exploit path
• Requires unrealistic attacker capabilities
• Violates one or more hard exclusion rules
• Better handled by separate tooling (dependency scanner, SAST, secret scanner)
• Purely stylistic or best-practice concern without security impact

Examples:

• "This function doesn't validate all inputs" without proving the validated input is the attack surface
• "This uses MD5" where the hash is not used for security (e.g., cache key)
• "This function could consume too much memory" (DOS exclusion)

Action: Suppress entirely. Do not include in report.

Severity Mapping

Once confidence ≥ 8 is confirmed, map to severity:

Quality Gate

The confidence rubric double-checks each finding against three lenses:

False-Positive Exclusion Rules

Applied during Phase 4 of the scan. Findings matching any hard exclusion are automatically suppressed. Precedents from prior reviews guide borderline cases.

Hard Exclusions

Automatically exclude findings matching these patterns:

Precedent Rules

These guide borderline cases based on prior human review decisions:

Confidence Scoring

Findings that survive exclusions get a confidence score (1–10):

Hard threshold: Only report findings with confidence ≥ 8.

Signal Quality Criteria

For remaining findings, assess:

1. Is there a concrete, exploitable vulnerability with a clear attack path?
2. Does this represent a real security risk (vs theoretical best practice)?
3. Are there specific code locations and reproduction steps?
4. Would this finding be actionable for a security team?

Vulnerability Categories — Detection Guidance

Each category: vulnerable pattern → safe pattern → code example.

SQL Injection

Cross-Site Scripting (XSS)

Server-Side Request Forgery (SSRF)

Command Injection

Authentication/Authorization Bypass

Unsafe Deserialization

Path Traversal

Insecure Direct Object Reference (IDOR)

Weak Cryptography

Secrets Exposure

Template Injection (SSTI)

NoSQL Injection