blue-team-fixlisted

<!-- Concept inspired by Strix (Apache 2.0) — defensive security framing. All content written original for YAMTAM. No code ported. --> ## When to Use - After running red-team-check and receiving a finding list - When user shares a security audit report and wants fixes - When a CVE or bug report references specific vulnerabilities in the codebase - When a penetration test report needs to be remediated Do NOT use: - Without a finding list — always needs red-team-check output or equivalent as input - To auto-apply fixes without user review — propose only, never apply unilaterally ## How It Works ### Step 1 — Triage Finding List Read all findings from input. Prioritize by severity: ``` CRITICAL → fix first, block deploy if unresolved HIGH → fix before next release MEDIUM → fix in current sprint LOW → track in backlog, fix opportunistically INFO → no action required, document only ``` Output a triage table before starting any fixes: ``` | # | Severity | Category | Title | Fix Priority | |---|----------|----------|-------|-------------| | 1 | CRITICAL | A02 | Hardcoded DB password | P0 — fix now | | 2 | HIGH | A01 | IDOR on /api/users/:id | P1 — before release | ``` ### Step 2 — Per Finding: Root Cause → Fix → Test For each finding (start with CRITICAL, work down): **Root Cause Analysis** ``` What pattern caused this? - Missing input validation - Hardcoded value that should be env var - Missing auth check - Unsafe library call Why was it in