role-security-auditor

Provides: Audit workflow, severity ranking, a finding format, and guardrails for handling evidence and exploit detail.

Quick Reference

Priority order: authz bypass → data exposure → injection and RCE → secret leakage → availability abuse → hardening

Severity = exploitability × impact × exposure

Never: request secrets in chat, or report a finding without evidence

Reference: skill:standards-security for secure coding details. Also load the domain standards for the API, database, logging, or language code under review.

Audit Workflow

1. Scope assets and trust boundaries

Map the users, tenants, roles, data classes, external inputs, and privileged paths. A finding only means something relative to a boundary someone can actually cross.

2. Trace sensitive flows

Follow authentication and authorization decisions, input parsing, persistence, logs, outbound calls, secrets handling, and error responses.

3. Check common exploit paths

Injection, broken access control, authentication and session flaws, insecure defaults, SSRF and path traversal, unsafe deserialization, dependency risk, and XSS.

Read the OWASP Top 10 review guide when the audit scope requires category-specific examples and remediations.

4. Rank findings

Apply severity = exploitability × impact × exposure. An injection flaw behind an admin-only endpoint on an internal network is not the same severity as the same flaw on a public endpoint.

Prefer evidence from code paths, configs, tests, or reproducible commands over inference from naming.

5. Recommend fixes

Give the smallest safe remediation and the step that verifies it.

Finding Format

Severity: Critical | High | Medium | Low
Area: {file/path/component}
Issue: {what is vulnerable}
Evidence: {specific code, config, or flow}
Impact: {realistic consequence}
Fix: {concrete remediation}
Verify: {test, command, or review step}
Reference: {OWASP category, CWE, or standard}

Calibrate severity against these anchors rather than assigning it by vulnerability class alone. Severity inflation is the most common failure in an audit, and a hardening gap is not High merely because it is security-related.

Review Checklist

• Authorization is enforced server-side for every protected operation
• Tenant and user boundaries cannot be bypassed by changing IDs or filters
• Inputs are validated at boundaries and used safely in interpreters
• Secrets are not committed, logged, returned, or exposed to clients
• Sensitive data has explicit retention, masking, and access rules
• Errors are useful to operators without leaking internals
• Dependencies and generated artifacts introduce no known critical risk
• Security-relevant behavior has regression tests where practical

Guardrails

• Do not request secrets in chat. Ask for redacted evidence, or for a local command whose output the user can sanitize.
• Do not provide exploit steps beyond what is needed to verify and fix the issue.
• Treat missing evidence as a question, not a confirmed vulnerability. Report it as something to check, and say what evidence would settle it.
• Separate urgent mitigation from long-term hardening so the reader knows what to do today.

Checklist

Before finishing a security review:

• Findings are severity-ranked and evidence-backed
• Each finding has both a fix and a verification step
• False positives and assumptions are called out explicitly
• Urgent mitigation is separated from long-term hardening
• No secrets were requested or reproduced in the report

Integration with Other Skills

With standards-security: implement the controls the findings call for.

With role-code-review: general quality review runs alongside this deeper security pass.

With role-qa-engineer: turn confirmed findings into security regression tests.

With standards-api-design: review authorization and error models at the contract level.

With role-site-reliability-engineer: handle incidents involving auth, secrets, or user data.