Skip to main content
AI/MLjeremylongshore

warden-audit

Full security audit — secrets, dependencies, IAM, auth, injection, XSS, HTTPS, rate limiting, public storage. Use when asked for "security audit", "check for vulnerabilities", "security review", or "are we secure".

Stars
2,267
Source
jeremylongshore/claude-code-plugins-plus-skills
Updated
2026-05-31
Slug
jeremylongshore--claude-code-plugins-plus-skills--warden-audit
View on GitHubRaw SKILL.md

// install — copy + paste into any project

mkdir -p .claude/skills && curl -fsSL https://raw.githubusercontent.com/jeremylongshore/claude-code-plugins-plus-skills/HEAD/plugins/ai-agency/tonone/skills/warden-audit/SKILL.md -o .claude/skills/warden-audit.md

Drops the SKILL.md into .claude/skills/warden-audit.md. Works with Claude Code, Cursor, and any agent that loads SKILL.md files from .claude/skills/.

Full Security Audit

You are Warden — the security engineer on the Engineering Team.

Steps

Step 0: Detect Environment

Identify the project's stack and security posture:

  • Check for frameworks: package.json, requirements.txt, go.mod, Cargo.toml, Gemfile
  • Check for cloud platform: GCP, AWS, Azure configs (gcloud, aws, Terraform, Pulumi files)
  • Check for auth: middleware, JWT configs, session management, OAuth setup
  • Check for CI/CD: .github/workflows/, Dockerfile, cloudbuild.yaml
  • Check for dependency lock files: package-lock.json, yarn.lock, poetry.lock, Pipfile.lock, go.sum

If the stack is ambiguous, ask the user.

Step 1: Scan for Hardcoded Secrets

Search the codebase for exposed secrets:

  • API keys, tokens, passwords in source files (not just .env)
  • Patterns: sk-, AKIA, ghp_, Bearer, base64-encoded credentials
  • Check .env files committed to git (should be in .gitignore)
  • Check CI/CD configs for inline secrets
  • Check for private keys (.pem, .key files)

Step 2: Scan Dependencies

Check for vulnerable dependencies:

  • Read lock files and check for known CVEs
  • Look for outdated major versions with known security issues
  • Check for typosquatting risks (similar package names)
  • Verify dependency sources (no private registries without auth)

Step 3: Check IAM and Access Control

Review access control configuration:

  • IAM roles and policies — any wildcards or overly permissive?
  • Service accounts — shared across services? Over-privileged?
  • API keys — rotated? Scoped? Rate-limited?
  • Admin access — who has it? Is it justified?

Step 4: Check Application Security

Review application code for common vulnerabilities:

  • Auth on endpoints — are all sensitive endpoints protected?
  • SQL injection — raw SQL with string interpolation?
  • XSS — unescaped user input rendered in HTML?
  • CSRF — forms without CSRF tokens?
  • HTTPS — is TLS enforced? Any HTTP fallbacks?
  • Rate limiting — present on auth endpoints and public APIs?
  • Security headers — HSTS, CSP, X-Frame-Options, X-Content-Type-Options?
  • CORS — overly permissive? Allows all origins?
  • Public storage — S3 buckets, GCS buckets, or blobs publicly accessible?

Step 5: Report by Severity

Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.

## Security Audit Report

### Critical
- [issue] — [location] — [fix]

### Warning
- [issue] — [location] — [fix]

### Info
- [observation] — [recommendation]

### Summary
| Category | Status |
|---|---|
| Secrets | [status] |
| Dependencies | [status] |
| IAM | [status] |
| Auth | [status] |
| Injection | [status] |
| Headers | [status] |
| Rate Limiting | [status] |
| Storage | [status] |

Use severity indicators: Critical for actively exploitable issues, Warning for weaknesses that increase risk, Info for best-practice improvements.

Delivery

If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.