secure

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:

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 sanitized/escaped before use in queries — unsanitized input is the #1 attack vector for SQL injection, XSS, and command injection
• Parameterized queries used (no string concatenation in SQL) — string concatenation enables SQL injection even with escaping; parameterized queries are the only safe default
• No eval(), exec(), or template injection vectors — these functions execute arbitrary code and bypass all input validation

Authentication & Authorization

• Auth checks on every protected endpoint — missing checks on a single endpoint exposes the entire system
• Tokens validated and not just decoded — decoding without signature verification lets attackers forge any token
• Session expiry and refresh logic correct — stale sessions allow account takeover; refresh token rotation prevents replay attacks
• No hardcoded credentials or secrets in code — hardcoded secrets end up in version control and are impossible to rotate