security-hardening— agent skill

Overview

Security vulnerabilities are almost always cheaper to prevent than to remediate. This skill embeds security review as a required gate in the development workflow — not a separate audit that happens later (and often never).

When to Use

• Before any code involving user input
• Before any code touching authentication, authorization, or sessions
• Before any API endpoint is created or modified
• Before any code that handles secrets, credentials, or PII
• Before any code that makes outbound network requests

Process

Step 1: Threat Model the Change

1. Ask: Who are the attackers? What are they trying to achieve?
2. Identify all trust boundaries in the code:

• Where does user-controlled data enter the system?
• Where does that data flow?
• Where is it stored or transmitted?

1. For each trust boundary, name the top 3 attack vectors.

Verify: You can name at least one realistic attack scenario for this code.

Step 2: Apply OWASP Top 10 Checklist

1. For each applicable item, confirm it is addressed:

Verify: Each applicable item is either addressed or explicitly accepted as a known risk.

Step 3: Secrets Management

1. No hardcoded secrets — ever. Not even in dev/test code.
2. Secrets are stored in: environment variables, secrets manager (Vault, AWS Secrets Manager, etc.), or encrypted config.
3. Secrets are never logged, printed, or included in error messages.
4. Secrets are never committed to git (check .gitignore and use pre-commit hooks).

Verify: git grep -i 'password\|secret\|key\|token' returns no hardcoded values in code.

Step 4: Input Validation

1. Every piece of external input is validated:

• Type check
• Length/size limits
• Allowlist of expected values (not blocklist)
• Reject and log unexpected input — never silently ignore

1. User-controlled data is never concatenated into SQL, shell commands, HTML, or file paths without proper escaping/parameterization.

Verify: All external input has explicit validation with reject-by-default behavior.

Step 5: Least Privilege

1. Database connections use the minimum required permissions.
2. API tokens have the minimum required scopes.
3. Service accounts cannot access resources they don't need.
4. Default deny — access must be explicitly granted, not implicitly inherited.

Verify: List every permission granted by this code. Is each one required?

Common Rationalizations (and Rebuttals)

Red Flags

• User input directly interpolated into queries or commands
• Authentication middleware that can be bypassed
• Error messages that include stack traces or SQL queries
• API keys or passwords in source code or comments
• Missing authorization check on any endpoint
• HTTP used instead of HTTPS for any sensitive data

Verification

• [ ] OWASP Top 10 checklist reviewed for applicable items
• [ ] No hardcoded secrets (git grep clean)
• [ ] All external input validated (type, length, allowlist)
• [ ] No raw SQL/shell from user input
• [ ] Least privilege applied to all credentials
• [ ] Security events are logged (but secrets are not)
• [ ] Dependency vulnerabilities checked

References

• OWASP Top 10
• prompt-injection-defense skill
• references/security-checklist.md