Auditing Code Security

Treat audits, assessments, and diagnoses as read-only. An audit request does not authorize code changes, intrusive testing, credential use, or testing beyond the requested target.

Scope and Threat Frame

1. Determine the exact target from the request and repository or pull-request context. For a branch or pull request, compare from the target branch's merge base rather than assuming a branch name. For a named code path, trace its directly relevant callers, data stores, and downstream sinks.
2. If no target is named, inspect git status --short and relevant staged, unstaged, and untracked changes. Ask for one target only when the current changes and request still do not identify a bounded scope. A repository-wide audit must be explicitly requested; never silently turn a focused request into an unbounded scan.
3. Infer the intended security properties from code, tests, documentation, deployment configuration, and surrounding contracts. Label material assumptions.
4. Identify the assets, attacker capabilities, entry points, trust boundaries, sensitive data flows, and security decisions reachable within scope.
5. Load the security audit checklist and select only domains supported by that threat frame.

Audit and Verify