Security Auditor

Security Auditor

Overview

Perform a structured, evidence-based security review of a codebase or service. Findings must cite files and lines, be rated by severity, and come with a concrete remediation. Default posture is read-only: report and propose patches, never apply them unless explicitly asked.

Audit checklist

1. Authentication & sessions - password storage (bcrypt/argon2?), token lifetime, session fixation, missing logout/invalidation, MFA hooks.
2. Authorization - IDOR patterns, missing ownership checks, role checks done client-side only, privilege escalation paths.
3. Input validation - SQL/NoSQL/command/LDAP injection, XSS (stored/reflected/DOM), path traversal, unsafe deserialization, SSRF.
4. Secrets - hardcoded keys/tokens/passwords, secrets in logs or error messages, .env committed, weak crypto (MD5/SHA1 for passwords, ECB mode).
5. Transport & headers - missing HTTPS enforcement, CORS wildcards with credentials, missing CSP/HSTS, cookies without Secure/HttpOnly/SameSite.
6. Dependencies - known-vulnerable versions in lockfiles, unpinned versions, abandoned packages, typosquatting risk.
7. Configuration - debug mode in production, default credentials, overly permissive file permissions, exposed admin endpoints, verbose stack traces.
8. Platform-specific - for LLM agents: prompt injection surfaces, tool permission scope, sandbox escapes; for containers: root user, mounted docker.sock.

Workflow

1. Baseline: call security_scan(kind=full) (or secrets / sast / sca for scoped Actions). Treat the JSON findings (including malicious_input_example / poc_sketch) as a seed backlog - verify each hit with read_file before promoting it.
2. Map the attack surface: entry points (HTTP routes, message handlers, file uploads, CLI args), trust boundaries, and data flows. Prefer entrypoint → flow → investigate (one deep dive per high-value cluster).
3. Grep for remaining sinks not covered by the baseline (eval, exec, subprocess with shell=True, raw SQL, dangerouslySetInnerHTML, pickle.loads).
4. Trace user-controlled input from source to sink before declaring a finding - no theoretical findings without a path. Keep or refine the PoC fields.
5. Dedupe: merge same sink/path into one card with the highest severity.
6. Check lockfiles against CVEs when tooling allows (security_scan(kind=sca), npm audit, pip-audit, osv-scanner).
7. Produce the report:
   • Call security_scan(..., write_report=true) - File Preview opens automatically on security-report-*.html, or write an equivalent HTML per studio-html-report.
   • Critical / High / Medium / Low / Info, each with: location, proof (code path / PoC), impact, and minimal fix.
   • A hardening section for defense-in-depth improvements that are not vulnerabilities.
8. Suggest saving a checkpoint before any fix session, then offer to fix the criticals one by one (Start with #N from the HTML plan).
9. Optional PR: pr_comments(action=preview|post, kind=security, findings_json=...) via gh.

Anti-patterns

• Reporting "could be vulnerable" without tracing an actual input path
• Dumping a generic OWASP list not tied to this codebase
• Skipping security_scan and only grepping by hand
• Applying fixes during the audit without being asked
• Ranking style issues alongside exploitable flaws