appsec-advisory

AppSec advisory

Use this skill for a scoped security review of a repo or PR, with prioritized findings and safe verification advice. It is a read-only source review, not a penetration test or certification. Use $security-review for pre-commit scans, $security-owasp for vulnerability patterns, and $threat-model or @security-champion-agent for architecture and trust boundaries.

Scope and evidence

1. Identify repo, revision, scope and exclusions; read repo instructions and resolve the diff base. For worktree reviews include committed, staged, unstaged and untracked changes, reading untracked files directly. Never work around denied access.
2. Map relevant entry points, data flows, assets and trust boundaries. Trace candidates through callers, auth, ownership, dependencies and deployment controls. Check defaults and effective policies, not only individual fragments, including config edge cases such as blank, relative or symlinked paths and optional values set to empty strings. Treat log statements as sinks: follow credentials, tokens, authorization codes and request bodies that carry them into logs at every level, including DEBUG. Verify third-party behavior against the versioned dependency or mark it unverified.
3. Run useful read-only checks and record commands, results and scope. Treat existing alerts (Dependabot, code scanning, secret scanning) as leads, not findings; record tool, ruleset, revision, scanned paths and exclusions before validating each claim. Existing GitHub alerts read through gh api are cheap evidence. Do not install tools, start services, contact targets, read credentials, dump secrets or run active probes. Do not create files, even in the session workspace, unless requested. Record tools needing writes or unavailable tools as unperformed, not clean scans.
4. Try to disprove each candidate: attacker control, reachability, upstream auth, deny policies, compensating controls and plausible impact. Check benign paths. Drop unsupported claims; state unresolved ones as questions with a way to settle them.
5. For a PR, report only issues the change introduces or makes reachable; list existing issues separately as context. Check git history for reverted or previously fixed code, and treat changed security code without tests as higher risk.
6. Prioritize by plausible impact and exposure, not scanner labels. Separate observed code defect, conditional risk and verified exploit: source review cannot establish the last. Rate code evidence and deployment exposure separately; do not infer reachability from an egress-only policy or a single config fragment.