security-report

name	security-report
description	Aggregate findings from all security skills (/security-code-review, /security-infra-review, /security-pentest) into a professional penetration testing report with executive summary, OWASP matrix, vulnerability chains, deduplication strategy, and actionable remediation roadmap with effort estimates.
argument-hint	[project name]
model	claude-opus-4-6
context	fork

ultrathink

CORE RULES

• Only include verified findings from actual audits in this conversation.
• Deduplicate findings with the same root cause into a single entry.
• Every finding: location (file:line or endpoint) + CWE + severity + exploit scenario + remediation.
• No fabricated CVEs or inflated severity scores.
• Clearly distinguish confirmed (fully traced/exploited) from probable (pattern match).
• Cross-reference code findings with infrastructure findings to identify vulnerability chains.

---

WHAT YOU DO

Compile findings from all security skills into a structured, professional-grade report suitable for dev teams, security officers, and compliance auditors.

Your role: aggregate, deduplicate, score, identify chains, prioritize, and format findings into an actionable remediation roadmap.

Target: $ARGUMENTS — project name for report header. Defaults to current directory name.

---

WORKFLOW

1. COLLECTION & DEDUPLICATION

Collect all findings from security skill outputs in this conversation. For each finding, extract:

• Location (file:line, endpoint, infrastructure component)
• CWE identifier
• Initial severity claim
• Evidence (code snippet, log, config, exploit proof)
• Status: confirmed vs probable

Deduplicate findings with the same root cause:

• Merge into a single entry listing ALL affected locations
• Example: SQL injection in 3 endpoints = 1 finding, 3 locations
• Keep counts: "affects 7 API endpoints across authentication module"

---

2. CROSS-REFERENCE & VULNERABILITY CHAINS

Identify vulnerability chains by combining findings across code, infrastructure, and external attack surface.

Chain Scoring Logic

Severity escalation when conditions combine:

Base Finding 1	Base Finding 2	Chain Result	Rationale
LOW: Exposed debug endpoint	MEDIUM: Default credentials	CRITICAL	Attacker chains to full admin access
MEDIUM: XSS in comments	MEDIUM: Missing CSP header	CRITICAL	XSS is undefended; becomes session theft
LOW: Info disclosure (version)	MEDIUM: Known CVE in version	CRITICAL	Version + CVE = direct RCE
MEDIUM: Weak password policy	MEDIUM: No 2FA	HIGH	Both defenses missing; auth bypass likely
LOW: SQL error in logs	MEDIUM: SQL injection vector	CRITICAL	Confirmed exploitability + info leak
MEDIUM: API key in comments	MEDIUM: Public repository	CRITICAL	Key exposure + no rotation detected
MEDIUM: Client-submitted price/amount	LOW: No server-side price lookup	CRITICAL	Free or arbitrary-price purchases possible
MEDIUM: Client-submitted role/isPro	LOW: Missing auth middleware	CRITICAL	Privilege escalation with a single HTTP field change
MEDIUM: Supabase/Firebase open rules	LOW: No audit logging	CRITICAL	Any user reads/writes all data, undetected
MEDIUM: Missing Stripe webhook signature check	LOW: Predictable webhook URL	CRITICAL	Attacker forges payment completion events

How to Identify Chains

1. For each code vulnerability, ask: "What infrastructure weakness amplifies this?"
2. For each infra weakness, ask: "What code flaw can exploit it?"
3. For each external finding (open port, leaked credential), ask: "Can we chain this to code/infra?"
4. Document the chain: "Finding A + Finding B = Chain C (CRITICAL)"

---

3. DEDUPLICATION STRATEGY

Step-by-step deduplication:

1. Group by root cause, not by location

   • Root cause: "SQL injection in user input validation"
   • Affected locations: auth.js:45, users.js:120, api/profile:GET
   • Single entry: 1 finding, 3 locations

2. Merge severity

   • Use the highest severity across all instances
   • Document why: "CRITICAL because 1 of 3 instances is unauthenticated endpoint"

3. Consolidate remediation

   • One fix that covers all instances
   • Example: "Add parameterized queries to all user input handlers"

4. List all affected locations explicitly

   • Don't hide instances; enumerate them
   • Helps dev team verify the fix

Deduplication Red Flags

• Don't merge findings with different root causes (even if similar symptom)
• Don't merge across different severity levels without justification
• Don't hide instances; enumerate all affected locations

---

4. SEVERITY SCORING: LIKELIHOOD × IMPACT MATRIX

Score each finding using the grid below. Severity = Likelihood + Impact weighted equally.

Likelihood (Attacker Perspective)

• CERTAIN (100%): Directly exposed, no auth, weaponized exploit
• HIGH (70%): Minor auth/auth required, some effort needed
• MEDIUM (40%): Specific conditions, social engineering, or complex exploit chain
• LOW (10%): Highly constrained, requires insider knowledge or multiple failures

Impact (Business Perspective)

• CRITICAL: Data breach, RCE, full authentication bypass, financial loss > $100k
• HIGH: Partial data access, privilege escalation, service downtime 1-4 hours
• MEDIUM: Limited data access, temporary DoS, information disclosure, compliance violation
• LOW: Hardening opportunity, defense-in-depth gap, minimal user impact

Scoring Formula

Likelihood	CRITICAL Impact	HIGH Impact	MEDIUM Impact	LOW Impact
CERTAIN	CRITICAL	CRITICAL	HIGH	MEDIUM
HIGH	CRITICAL	HIGH	HIGH	MEDIUM
MEDIUM	HIGH	HIGH	MEDIUM	LOW
LOW	MEDIUM	MEDIUM	LOW	LOW

---

5. CODE-TO-INFRASTRUCTURE CROSS-REFERENCE

For each code vulnerability, document its infrastructure dependencies:

Template:

Finding: [Code Issue]
Root Cause: [CWE]
Severity: [CRITICAL/HIGH/MEDIUM/LOW]

Confirmed Locations:
- src/auth.js:45 (SQL injection in login)
- api/users.py:120 (SQL injection in profile query)

Infrastructure Amplifiers:
- ❌ No WAF blocking SQL patterns
- ❌ Database user has full schema permissions
- ❌ No query logging or alerting
- ❌ Unencrypted database connection from app server

Interdependency Chain:
Code flaw (injection) + Infra gap (no WAF/logging) = CRITICAL severity
  → Code fix: Parameterized queries
  → Infra fix: Deploy WAF rules + enable slow query log

Effort: Code 2hrs, Infrastructure 1hr, Testing 3hrs

---

6. GENERATE REPORT

Output using report-template.md format. Structure:

1. Executive Summary

   • Total findings by severity
   • Vulnerability chains identified
   • Top 3 priority fixes
   • Estimated remediation effort

2. OWASP Coverage Matrix

   • Tested categories
   • Coverage gaps

3. Detailed Findings

   • Grouped by severity (CRITICAL → LOW)
   • Within each severity, ordered by impact
   • For each: location, CWE, confirmed/probable, exploit scenario, remediation steps

4. Vulnerability Chains (separate section)

   • Each chain: A + B = C
   • Why it matters
   • Joint remediation strategy

5. Remediation Roadmap

   • P0 (fix within 24 hours): CRITICAL + exploitable chains
   • P1 (fix within 1 week): HIGH
   • P2 (fix within 1 month): MEDIUM
   • P3 (fix within 3 months): LOW
   • Effort estimates: [code hrs] + [infra hrs] + [test hrs]

6. Quality Checks (checklist below)

7. Next Steps for Dev Team

   • Minimum 5 actionable items
   • Clear ownership (code team vs infra team)

---

7. QUALITY CHECKS

Before delivering, verify all items below:

• Every finding has explicit location (file:line or endpoint)
• Every finding has CWE identifier (cwe.mitre.org link)
• Every finding has concrete exploit scenario (not "could be exploited")
• Every finding has copy-pasteable remediation (code + config examples)
• Every finding labeled: confirmed or probable
• No fabricated CVE numbers anywhere
• Executive summary totals match detailed findings count
• Effort estimates realistic (not all "5 min")
• OWASP coverage table accurately reflects what was tested
• Remediation roadmap has clear P0/P1/P2/P3 priorities with timeline
• Vulnerability chains identified where applicable (at least 2-3 expected)
• Cross-references document code-to-infra dependencies
• Deduplication: no duplicate root causes with different phrasings
• All affected locations enumerated for deduplicated findings
• Minimum 5 actionable next steps for dev team
• Report is self-contained — readable without prior conversation context
• No sensitive data (API keys, tokens, credentials) in report
• Client-trust violations checked: prices, roles, subscription status — any server-side enforcement gap flagged
• BaaS security rules reviewed: Supabase RLS, Firebase rules, Clerk middleware — open rules escalated to CRITICAL chain
• Payment integrity checked: webhook signature verification, server-side price lookup — missing checks flagged as CRITICAL

---

EXAMPLE: VULNERABILITY CHAIN ANALYSIS

Scenario: You find:

1. XSS in comment field (MEDIUM)
2. Missing Content-Security-Policy header (LOW)
3. No session timeout (LOW)

Deduplication: 3 separate findings (different root causes)

Chain identification:

• Finding 1 + Finding 2 = CRITICAL (XSS + no CSP = undefended session theft)
• Finding 1 + Finding 3 = HIGH (XSS + no timeout = longer exploitation window)
• Finding 2 + Finding 3 = MEDIUM (defense-in-depth gap)

Report entry:

⚠️ CRITICAL CHAIN: Session Hijacking via XSS
Consists of:
- MEDIUM: XSS in comments (CWE-79) → src/comments.js:120
- LOW: Missing CSP header (CWE-693) → server.js:45
- LOW: No session timeout (CWE-613) → auth.js:200

Why CRITICAL: Attacker injects JavaScript, steals session, maintains access indefinitely.

Joint remediation:
1. Sanitize comment input (code)
2. Add CSP header (infrastructure)
3. Implement 30-min session timeout (code)
Effort: 4 hrs code + 1 hr infra + 2 hrs test

---

NOTES FOR EXECUTION

• ultrathink mode: Use deep reasoning to identify non-obvious chains
• Cross-domain thinking: Code + infra + network = full picture
• Conservative scoring: When in doubt, escalate severity; don't inflate findings
• Evidence first: Every claim must reference actual audit data