Security Audit
When to use
Use this skill when the user wants a full security review of a repository, service, or application slice.
Default behavior
- stay in read-first mode unless the user explicitly asks for a patch
- reason from framework and architecture conventions
- flag likely vulnerabilities and insecure defaults
- explain exploitability in safe, non-weaponized language
- ask for missing deployment or authorization context when needed
Coverage map
- broken access control and IDOR
- authentication, session, cookie, token, and reset flaws
- business logic abuse paths
- XSS, CSRF, SSRF, injection, unsafe deserialization
- file upload and document processing risks
- unsafe crypto and secret management
- headers, rate limiting, logging, admin paths, background jobs, webhooks, queues, migrations
- ORM misuse, N+1, authorization-after-fetch, tenant scope gaps
Workflow
- Identify the app surface, trust boundaries, and privileged workflows.
- Map authn/authz, tenant, and data-access patterns.
- Review request handling, storage, jobs, webhooks, and admin paths.
- Prioritize only findings with meaningful evidence.
- Return findings in the standard Patchman format.
Findings format
Title:Severity:Confidence:CWE / OWASP mapping:Affected area:Why this matters:Evidence:Exploitability notes:Recommended fix:Safer example patch:Follow-up checks:
Safety constraints
Refuse requests for unauthorized access, persistence, evasion, credential theft, destructive actions, or exploit weaponization.
1---2name: security-audit3description: Conduct authorized defensive security audits of codebases and web applications. Use for broad appsec review across OWASP, authz, business logic, SSRF, XSS, CSRF, injection, file upload, secrets, logging, and tenant isolation. Produces structured findings with severity, confidence, evidence, and safe remediation guidance.4---56# Security Audit78## When to use910Use this skill when the user wants a full security review of a repository, service, or application slice.1112## Default behavior1314- stay in read-first mode unless the user explicitly asks for a patch15- reason from framework and architecture conventions16- flag likely vulnerabilities and insecure defaults17- explain exploitability in safe, non-weaponized language18- ask for missing deployment or authorization context when needed1920## Coverage map2122- broken access control and IDOR23- authentication, session, cookie, token, and reset flaws24- business logic abuse paths25- XSS, CSRF, SSRF, injection, unsafe deserialization26- file upload and document processing risks27- unsafe crypto and secret management28- headers, rate limiting, logging, admin paths, background jobs, webhooks, queues, migrations29- ORM misuse, N+1, authorization-after-fetch, tenant scope gaps3031## Workflow32331. Identify the app surface, trust boundaries, and privileged workflows.342. Map authn/authz, tenant, and data-access patterns.353. Review request handling, storage, jobs, webhooks, and admin paths.364. Prioritize only findings with meaningful evidence.375. Return findings in the standard Patchman format.3839## Findings format4041- `Title:`42- `Severity:`43- `Confidence:`44- `CWE / OWASP mapping:`45- `Affected area:`46- `Why this matters:`47- `Evidence:`48- `Exploitability notes:`49- `Recommended fix:`50- `Safer example patch:`51- `Follow-up checks:`5253## Safety constraints5455Refuse requests for unauthorized access, persistence, evasion, credential theft, destructive actions, or exploit weaponization.
MuhammedZohaib