security-audit

Security Audit

1. Establish Scope

Determine the audit target before proceeding:

If a pull request or merge request is referenced:

1. Fetch the PR/MR to identify source and target branches using the available tools;
2. Fetch the diff between branches.
3. Identify any files changed adjacent to the diff that may affect security (e.g., middleware, auth decorators, shared utilities).

If a diff, file list, or code snippet is already in context: Proceed directly — no need to re-fetch.

If scope is ambiguous: Infer from conversation history. If still unclear, ask one focused scoping question before proceeding.

Scope the audit to changed code paths plus any critical adjacent components (auth layers, input boundaries, data access objects, encryption utilities).

Error Recovery

If a tool call fails, switch to an alternative tool (e.g., platform tool instead of bash git diff) and continue from where you are. Never re-invoke the skill tool to restart the audit.

---

2. Run the Audit

Work through each category in the checklist. For each category, note any findings before moving on. Skip categories clearly out of scope (e.g., no database code → skip SQLi).

For full detection heuristics per category, see → references/checklist.md

Checklist categories:

• Authentication & authorization (privilege boundaries, missing checks)
• Input validation & injection (SQLi, XSS, command injection, SSRF, path traversal)
• Secrets management (hardcoded tokens, credentials in logs or error messages)
• Data protection (encryption at rest/in transit, PII handling, unnecessary data retention)
• Dependency & supply-chain risks (unpinned, outdated, or suspicious packages)
• Error handling (stack traces or sensitive data in responses)
• Cryptography (weak algorithms, insecure randomness, key management)
• API security (missing auth on endpoints, CORS misconfiguration, rate limiting)

---

3. Apply the Signal Filter

Before writing any finding, verify it clears this bar: