Security Audit
Esta habilidad realiza una auditoría de seguridad completa, detectando secretos, problemas de análisis estático y configuraciones incorrectas de Supabase Row-Level Security. Aplica correcciones de forma autónoma y re-ejecuta escaneos hasta resolver todos los hallazgos.
Qué hace
La habilidad usa Gitleaks para detectar secretos y Semgrep para el análisis estático. Inspecciona migraciones de Supabase para configuraciones correctas de Row-Level Security, verificando RLS habilitado y políticas para tablas. También comprueba archivos de entorno no rastreados y busca claves API codificadas. Al hallar vulnerabilidades, las remedia automáticamente, reemplazando secretos, eliminando archivos de configuración rastreados y generando políticas RLS. Luego, vuelve a escanear el proyecto, iterando correcciones hasta alcanzar un estado limpio.
Cuándo conviene
-
Al integrar código o dependencias nuevas, requiriendo verificaciones automáticas para vulnerabilidades de seguridad comunes.
-
Al preparar un proyecto para su despliegue, necesitando una verificación final sin secretos o configuraciones de seguridad erróneas.
-
Al mantener un proyecto Supabase, asegurando que la Row-Level Security esté correctamente implementada.
Configuración
-
Copiar el archivo de definición de la habilidad a
.claude/skills/security-audit/SKILL.mden el repositorio del proyecto. -
Invocar la habilidad en Claude Code introduciendo
/security-auditen la interfaz de chat.
El contenido
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 TABLEinpublicschema, verify RLS is enabled and at least one policy exists - Flag missing RLS
Step 3: Check Environment Files
- Verify
.envand.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.
Viene directamente del framework con el que se construye este sitio. Esta página muestra siempre la versión actual.