← Back

Security Audit

This skill performs a comprehensive security audit on your project, including secret scanning, static analysis (SAST), and Supabase Row-Level Security checks. It autonomously fixes identified issues and re-runs checks until the project is clean.

What it does

This skill conducts a thorough security audit of your codebase. It scans for secrets using gitleaks, performs static application security testing (SAST) with semgrep, verifies Supabase Row-Level Security configurations, and checks for incorrectly tracked environment files. The skill then attempts to fix all identified vulnerabilities and re-runs the audit until no issues remain.

When to use it

Use this skill when you need to ensure the security posture of your project before deployment or as part of a continuous integration pipeline. It's ideal for quickly identifying and remediating common security pitfalls, especially when dealing with secrets, SAST findings, or Supabase RLS. You can run it on demand to get a clean project state.

How to set it up

To use this skill, copy the file to .claude/skills/security-audit/SKILL.md in your repository. Once the file is in place, you can invoke it directly in Claude Code using /security-audit. Claude Code will execute the audit steps and provide a summary of findings and fixes.

The content

Security Audit

Run a comprehensive security audit on this project. Fix all findings autonomously.

Current git status: !git status --short Supabase project: !ls supabase/migrations/ 2>/dev/null | tail -5 || echo "No supabase directory"

Step 1: Run Scanners

Run all applicable scanners:

# Secret scanning
gitleaks detect --source . --no-git --report-format json --report-path /tmp/gitleaks-report.json 2>&1 || true

# SAST
semgrep --config=auto --json --output /tmp/semgrep-report.json . 2>&1 || true

Read both report files and understand all findings.

Step 2: Check Supabase RLS

If supabase/migrations/ exists:

  • Read all migration files
  • For every CREATE TABLE in public schema, verify RLS is enabled and at least one policy exists
  • Flag missing RLS

Step 3: Check Environment Files

  • Verify .env and .env.* (except .env.example) are in .gitignore
  • Run git ls-files | grep '\.env' to find tracked env files (exclude .env.example and vite-env.d.ts)
  • Scan src/ for hardcoded API keys or tokens

Step 4: Fix All Findings

For each finding:

  • Secrets in code: Replace with env var reference, add to .env.example
  • Tracked .env files: git rm --cached
  • SAST issues: Apply semgrep's recommended fix
  • Missing RLS: Generate migration file with RLS + basic policy

Step 5: Re-run Until Clean

Re-run all scanners from Step 1. If findings remain, fix and repeat. Stop after 3 cycles or when clean.

Step 6: Summary

Output what was found, what was fixed, and final scan status.

Served straight from the framework this site runs on. This page always shows the current version.

Want something like this for you?

It starts with a conversation: 30 minutes, no strings attached.

Book a call