securelisted

# Secure — Security Review ## Iron Law NO DEPLOYMENT WITHOUT SECURITY REVIEW OF ALL CHANGED FILES. Every code change is a potential attack vector. ## Process ### Step 0: Load Engagement Context (Optional) Check for engagement scoping: ```bash cat .harness/engagement.md 2>/dev/null ``` If `.harness/engagement.md` exists: 1. Parse the **Scope**, **Constraints**, and **Exclusions** sections 2. Restrict security checks to in-scope components 3. Apply rules of engagement (method, rate limits, no-exfil rules) 4. Skip findings matching exclusion patterns 5. Include engagement reference in report header If not found: apply full OWASP Top 10 checklist (default behavior). No scope restrictions. See `references/engagement.md` for the engagement file format. ### Step 1: Identify Security-Relevant Changes Identify security-relevant changes from the diff (auth, DB, API, infra, secrets). ### Step 2: Run Checklist Run the Checklist below, marking each item as pass, fail, or N/A with reason. ### Step 3: Report For each failure, cite the file and line number with severity (CRITICAL/HIGH/MEDIUM). Report findings using the Evidence Required section. ## When to Trigger - Authentication or authorization code changed - Database queries written or modified - API endpoints added or changed - Environment variables or secrets referenced - File upload, user input parsing, or serialization code - Infrastructure config (Docker, K8s, CI/CD) ## Checklist ### Injection - [ ] All user input s