Auditoría de Seguridad con Claude Code: Un Flujo Práctico para 2026

Los nombres de comandos y plugins de este artículo provienen de la documentación oficial de Anthropic (consultada en 08/2026); Claude Code se actualiza a menudo, así que vuelve a revisar el marketplace /plugin antes de auditar.

¿Qué es una auditoría de seguridad con Claude Code?

Una auditoría de seguridad con Claude Code es la práctica de usar Claude Code como un "revisor de seguridad de IA" - leyendo el significado de tu código para encontrar vulnerabilidades, en lugar de solo casar patrones como un linter tradicional. Como el modelo entiende el flujo de datos y la intención de una función, atrapa problemas que las herramientas basadas en regex suelen dejar pasar: entrada de usuario que fluye hacia una cadena SQL concatenada, un endpoint sin comprobación de autorización, o una clave de API metida directamente en el código fuente.

Las clases de vulnerabilidad que Claude Code tiende a atrapar incluyen: inyección (SQL, comando, NoSQL, XXE), autenticación y autorización rotas (IDOR, escalada de privilegios, sesiones débiles), exposición de datos (secretos hardcodeados, PII en logs), criptografía débil (RNG pobre, mala gestión de claves), configuración incorrecta (CORS, cabeceras de seguridad) y riesgo de cadena de suministro (dependencias con CVE conocidos).

Esta guía cubre cuatro enfoques:

• El /security-review nativo - un comando integrado de Claude Code más una GitHub Action oficial de Anthropic, lanzada en agosto de 2025 (anthropics/claude-code-security-review, consultada en 08/2026). Revisa los cambios pendientes, puntúa la severidad y sugiere correcciones, con un filtro de falsos positivos incorporado.
• El plugin claude-security - instálalo con /plugin install claude-security@claude-plugins-official, que añade un comando /claude-security que abre un menú de escaneo profundo multiagente (no un comando de escaneo simple): mapear la arquitectura → construir un modelo de amenazas → cazar vulnerabilidades → un agente independiente verifica antes de reportar. Gratis (cuenta en el uso de tu plan), requiere dynamic workflows. Consulta su propia sección más abajo.
• El plugin security-guidance - revisa automáticamente el código que Claude acaba de escribir en 3 capas (casado de patrones instantáneo, revisión en segundo plano al final del turno, revisión profunda en el commit/push) - complementa las auditorías periódicas con una capa de monitoreo continuo. Consulta nuestro artículo sobre buenas prácticas de seguridad para más detalles.
• La skill ak-security ya lista - un paquete de prompts que cubre STRIDE + OWASP A01-A10, auditoría de dependencias consciente del stack, red-teaming multipersona y un modo --fix, para que nunca tengas que escribir un prompt largo a mano. De pago, parte del AgentKit Engineer Kit.

La documentación oficial sobre el modelo de seguridad de Claude Code está en code.claude.com/docs/en/security (consultada en 08/2026) - vale la pena leerla antes de darle a la IA permiso para ejecutar comandos en tu repositorio.

Antes de auditar: preparación

Tres minutos de preparación mantienen la sesión limpia y reversible:

• Claude Code instalado y con sesión iniciada. Si todavía no llegaste ahí, sigue la guía de instalación de Claude Code.
• Un árbol de trabajo Git limpio (git status no muestra nada pendiente). Quieres un diff claro para distinguir lo que la IA propone, y para revertir con git restore si un parche rompe algo.
• Define el alcance desde el principio: una sola carpeta (src/api/**), los archivos que estás cambiando ahora, o el repositorio entero. Un alcance estrecho es más rápido y más barato en tokens.
• Audita solo código CONFIABLE. Esta es la advertencia importante que me gusta dar temprano: cuando dejas que la IA lea código del repositorio o PR de un desconocido, el contenido malicioso en ese código puede inyectar instrucciones (prompt injection) que engañan al modelo. Para código no confiable, revísalo manualmente o ejecútalo en un entorno aislado.
• ¿Auditando un repositorio desconocido/no confiable? Ejecútalo en un sandbox. Si tienes que auditar un repositorio que no conoces, ejecuta Claude Code dentro de /sandbox (Seatbelt en macOS, bubblewrap+socat en Linux/WSL2) para aislamiento a nivel de SO - una capa más fuerte que un modo de permisos normal. Consulta sandboxing de Claude Code.
• Revisa los permisos de comandos. Revisa permisos y ejecución segura en Claude Code para que la IA no pueda ejecutar un comando destructivo por su cuenta durante el escaneo. A fecha de 08/2026, el modo auto es el modo inicial predeterminado en Pro/Max/Team - un comando arriesgado que la auditoría pueda sugerir (digamos, un --fix que ejecuta npm install) pasa por el clasificador en lugar de un prompt manual cada vez, así que revisa igual tu allowlist antes de empezar.

El flujo de auditoría de Claude Code en 6 pasos

Esta es la columna vertebral de toda la sesión. Trabaja en secuencia de lo estrecho a lo amplio, para que los resultados sigan siendo legibles y no quemes tokens en vano.

Paso 1 - Define el alcance

Empieza nombrando exactamente lo que quieres que se revise. Para un cambio pequeño, deja que Claude se enfoque en el diff; para un repositorio grande, acótalo con globs de directorio sobre las áreas sensibles (auth, pagos, subidas, APIs públicas). Pídele a Claude que lea cada archivo dentro del alcance antes de analizar - de lo contrario el modelo tiende a adivinar por los nombres de las funciones. Un prompt de apertura:

Read all files in src/api/ and src/auth/ first.
Do not change anything yet. Just list the areas with an attack
surface (external input, DB access, auth handling) so I can pick a scope.

Paso 2 - Ejecuta /security-review en los cambios pendientes

Para los cambios que estás por commitear, ejecuta el comando nativo directamente en la sesión de Claude Code:

/security-review

Esto revisa el diff pendiente, clasifica la severidad y propone una corrección para cada hallazgo. Corre en el modelo Claude más potente disponible (configurable) - piénsalo como un revisor de seguridad que lee tu PR antes de que llegue un humano. Este es el lugar más rápido para "hacer shift left": atrapar problemas mientras el código todavía está tibio y no ha aterrizado en la rama principal.

Paso 3 - Escanea el repositorio entero con STRIDE + OWASP

Para excavar más hondo que el diff, dale a Claude un prompt estructurado de modelado de amenazas. STRIDE se mapea bastante limpio sobre el OWASP Top 10. Una plantilla para copiar y pegar:

Audit all in-scope code across the 6 STRIDE categories, mapped to the OWASP Top 10:
- Spoofing -> A07 (identification/authentication failures)
- Tampering -> A03 (injection), A08 (data/software integrity)
- Repudiation -> A09 (missing logging/monitoring)
- Info Disclosure -> A02 (crypto), A01 (access control)
- Denial of Service -> note it, but only report with clear impact
- Elevation of Priv -> A01 (broken access control)

For each finding, record: severity, category, file:line, a short description,
and a concrete fix. Do not report theoretical issues you cannot tie to real impact.

Paso 4 - Audita las dependencias

Las vulnerabilidades a menudo viven no en el código que escribiste, sino en las bibliotecas que incorporaste. Ejecuta la herramienta adecuada para tu stack y luego deja que Claude sintetice y priorice:

npm audit # Node.js
pip-audit # Python
govulncheck ./... # Go
bundle audit # Ruby

Luego pega la salida en Claude: "Clasifica estos CVE por explotabilidad real en mi proyecto, y omite cualquiera que solo esté en devDependencies y nunca llegue a producción." Claude ayuda a cortar el ruido - no todo CVE está en tu ruta de ejecución real.

Paso 5 - Caza secretos hardcodeados

Pídele a Claude que escanee claves de API, contraseñas, tokens y claves privadas incrustadas directamente en archivos de código y de configuración. Una nota sobre higiene de credenciales: al reportar, enmascara los valores reales a <REDACTED_TOKEN> antes de registrar en logs o commitear el informe - no dejes que un secreto se filtre justamente por el archivo que lo audita.

Scan the whole repo for hardcoded secrets (api keys, passwords, tokens,
private keys, DB connection strings). For each finding, record only file:line
and the TYPE of secret, and mask the value to <REDACTED>. Do not print real values.

Paso 6 - Clasifica la severidad y exporta el informe

Pídele a Claude que reúna todos los hallazgos en una sola tabla por severidad, con umbrales de acción claros:

Para conservar los resultados, pídele a Claude que exporte un informe en Markdown con un resumen del conteo por severidad arriba ("2 Críticos, 3 Altos...") - ese formato encaja limpiamente en un rastreador de issues o en una revisión para tu líder. Si ejecutas auditorías con regularidad, guarda informes fechados en una carpeta security/ (con las partes sensibles en gitignore) para poder comparar ejecuciones y detectar qué vulnerabilidades reaparecen o se escapan de la revisión.

Una sesión de auditoría real: cómo leer los hallazgos

Aquí está la parte que la mayoría de los competidores casi siempre se saltan: una tabla de hallazgos real, no una descripción de características. Abajo hay un resultado ilustrativo de un proyecto Node/TypeScript de ejemplo (API + auth) para que veas cómo luce la salida - ejecútalo en tu propio repositorio para obtener tu propia tabla:

Cómo leerla: ve de arriba abajo por severidad. El hallazgo #1 bloquea el release - sin discusión. El #2 y el #3 entran directo al sprint. El #4 (IDOR) suele subestimarse, pero es un fallo de escalada de acceso extremadamente común. Para cada fila, abre el file:line exacto, confirma que el problema es real (no un falso positivo), y solo entonces parchea - no parchees a ciegas siguiendo el informe.

Un truco rápido de verificación antes de parchear: pregúntale de vuelta a Claude, "Demuestra que el hallazgo #4 es explotable: escribe una petición concreta que el usuario A usaría para leer el pedido del usuario B." Si el modelo puede construir un escenario de explotación específico, es una vulnerabilidad real; si titubea o tiene que asumir condiciones poco realistas, probablemente es un falso positivo y puedes bajar su prioridad. Este paso adversarial filtra el ruido y te ayuda a explicar el riesgo al resto del equipo en lenguaje concreto de atacante, en vez de jerga abstracta.

Parcheando una vulnerabilidad - un antes/después real

Toma el hallazgo #1 (Crítico, inyección SQL) como ejemplo. Este es el tipo de código fácil de equivocar:

// BEFORE - vulnerable to SQL injection
export async function getUser(id: string) {
 const sql = "SELECT * FROM users WHERE id = '" + id + "'";
 return db.query(sql); // the id input flows straight into the SQL string
}

Y después de parchear con una consulta parametrizada:

// AFTER - parameterized, the driver escapes it
export async function getUser(id: string) {
 const sql = "SELECT * FROM users WHERE id = $1";
 return db.query(sql, [id]); // the id value travels through the parameter channel, not the SQL string
}

Por qué es más seguro: en la segunda versión, id ya no se concatena en la cadena SQL, sino que se pasa por un canal de parámetro separado. El driver de la base de datos lo trata como dato, no como comando - así que una cadena como ' OR '1'='1 ya no puede cambiar la estructura de la consulta.

Para un flujo automatizado, la skill ya lista ofrece --fix para parchear los hallazgos uno por uno, ejecutar una prueba de guarda contra regresiones después de cada parche, y luego commitear cada corrección por separado. Pero revisa siempre el diff antes de hacer merge - y cuando un parche rompe una prueba, no adivines. En cambio, depura con la IA una corrección que rompe pruebas para encontrar la causa real.

Automatización: revisión de seguridad en cada Pull Request

Para que cada PR se escanee automáticamente, usa la GitHub Action oficial. Añade un archivo .github/workflows/security.yml:

name: Security Review
on: [pull_request]
jobs:
 review:
 runs-on: ubuntu-latest
 permissions:
 pull-requests: write
 contents: read
 steps:
 - uses: actions/checkout@v4
 - uses: anthropics/claude-code-security-review@main
 with:
 claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

La Action comenta los hallazgos directamente en el PR, así el revisor los ve de inmediato.

Salvedad obligatoria: según Anthropic, esta Action todavía no está endurecida contra prompt injection. Ejecútala solo en PR confiables y habilita "Require approval for all external contributors" en la configuración de tus Actions - de lo contrario, un PR malicioso de un desconocido podría inyectar instrucciones que engañen el proceso de revisión.

Para redondear la capa defensiva, combínala con un flujo de trabajo Git seguro con Claude Code y considera añadir un pre-commit hook que escanee secretos antes de que el código llegue al remoto.

Escaneo profundo gratuito con el plugin claude-security

Esta es una capa de escaneo profundo multiagente, oficial y gratuita - bastante distinta del /security-review del Paso 2, que revisa un diff en una sola llamada al modelo. claude-security ejecuta todo un equipo de agentes en tu sesión: uno mapea la arquitectura del repositorio, uno construye un modelo de amenazas a partir de eso, un grupo caza vulnerabilidades contra el modelo de amenazas, y luego un agente independiente verifica cada hallazgo antes de que aterrice en el informe final - ese paso de verificación independiente es lo que hace que el informe sea más confiable que una sola pasada de escaneo.

Requisitos: Claude Code v2.1.154+ en un plan de pago, necesita dynamic workflows para orquestar sus agentes (en Pro tienes que activarlos tú misma desde la fila "Dynamic workflows" en /config); Python 3.9.6+ disponible en tu PATH como python3 (el instrumental del plugin solo usa la biblioteca estándar, no se instala nada extra); y Git para escaneos de cambios y para exportar parches (un escaneo del repositorio entero funciona igual sin Git).

Instala y ejecuta:

/plugin install claude-security@claude-plugins-official
/claude-security # opens the menu: Scan codebase / Scan changes / Suggest patches
/claude-security scan my branch # or call a job directly in plain language

El plugin lee tu repositorio primero, luego ofrece un escaneo completo o un área enfocada con una estimación de costo para cada opción - útil en un repositorio grande, ya que un escaneo completo puede usar una cantidad significativa de tokens y necesita Claude Code abierto hasta que termine. Nada se ejecuta hasta que confirmas.

Los resultados aterrizan en un directorio CLAUDE-SECURITY-<timestamp>/ con marca de tiempo, justo dentro de tu repositorio: CLAUDE-SECURITY-RESULTS.md (un informe legible, cada hallazgo con un ID como F1 más severidad, confianza y un escenario de explotación), una versión .jsonl legible por máquina, y un sello de revisión - un archivo que registra exactamente qué commit se escaneó, con cuánta profundidad y si se incluyeron cambios sin commitear, para que un informe siempre quede atado al código exacto que describe. Ese directorio lleva su propio .gitignore, así que un git add descuidado nunca lo arrastra dentro de un commit.

Para parchear: ejecuta /claude-security otra vez, elige "Suggest patches" y selecciona qué hallazgos abordar. Cada parche lo revisa un agente independiente del que lo escribió antes de entregarse, y nunca se aplica automáticamente - los parches aterrizan en patches/F<n>.patch, y tú misma ejecutas git apply después de revisar.

Frente a la skill ak-security: las dos realmente se solapan ahora, y no tiene sentido esquivarlo. La ventaja de claude-security: gratis, verificación independiente por un agente separado, y parches que puedes git apply de inmediato. La ventaja de ak-security: un framework empaquetado de STRIDE + OWASP + red-team de 4 personas + escaneo de secretos en un comando ordenadito, familiar si ya usas AgentKit para otras cosas. Ninguno reemplaza del todo al otro - si todavía no tienes AgentKit, claude-security es lo bastante fuerte para empezar gratis.

Red-team avanzado: auditando desde 4 personas de atacante

Una pasada de STRIDE está bien, pero las vulnerabilidades reales tienden a aflorar cuando piensas como un atacante específico. Ejecutar la auditoría desde 4 puntos de vista distintos rinde una clara ganancia de información:

• Adversario de Seguridad - busca bypass de auth, variantes de inyección, IDOR: "Si inicio sesión con una cuenta normal, ¿puedo leer o editar los datos de cualquier otra persona?"
• Cadena de Suministro - dependencias con CVE conocidos, CI/CD envenenado, typosquatting en paquetes.
• Interno (Insider) - escalada de privilegios horizontal/vertical, exportación masiva de datos, abuso de los permisos de una cuenta interna.
• Infraestructura - SSRF, secretos filtrándose en variables de entorno, configuraciones de contenedor/red mal ajustadas.

Escribir las 4 personas a mano da mucho trabajo, porque cada ángulo necesita su propio conjunto de prompts y su checklist. Aquí es exactamente donde el modelado de amenazas ya listo y estructurado te ahorra horas de escritura de prompts.

Ejecutar las 4 personas es una pasada periódica de escaneo profundo; para una capa continua que atrapa problemas en el momento en que Claude escribe código (en vez de esperar a tu próxima auditoría), consulta el plugin security-guidance en nuestro artículo sobre buenas prácticas de seguridad - las dos capas se complementan, no se reemplazan.

Usando la skill ak-security ya lista (sáltate la escritura de prompts)

En vez de escribir a mano el prompt de STRIDE, las 4 personas de red-team y el flujo --fix cada vez, el bundle de AgentKit — ahora $149 (desde $198) empaqueta todo eso en la skill ak-security (parte del Engineer Kit, $99; el sitio indica garantía de devolución del dinero y actualizaciones de por vida, y no menciona una tarifa recurrente). Cómo usarla:

/ak:security src/api/**/*.ts # scan a narrow scope
/ak:security full --red-team --fix # whole repo, 4 personas, auto-patch

Reúne STRIDE + OWASP A01-A10, auditoría de dependencias consciente del stack, detección de secretos, puntuación de severidad y parcheo secuencial con una prueba de guarda. Consulta qué skills de seguridad incluye el Engineer Kit para sopesarla frente a tus necesidades.

Para ser sincera: esta skill realmente se solapa con el plugin gratuito claude-security de arriba ahora - no esperes que "convierta a la IA en un pentester" más de lo que lo hace el plugin nativo. La ventaja de ak-security: reúne STRIDE + OWASP + red-team de 4 personas + escaneo de secretos/dependencias en un comando ordenadito, familiar si ya usas AgentKit en otros lados; la ventaja de claude-security: verificación independiente por un agente separado y parches que puedes git apply de inmediato, gratis. Ninguno reemplaza del todo al otro - el kit vale la pena cuando ya tienes AgentKit y quieres quedarte en un solo ecosistema, no porque sea "fundamentalmente más fuerte".

Una línea para desambiguar: AgentKit aquí es un kit para Claude Code (agentkit.best, la CLI ak), no el AgentKit de OpenAI (Agent Builder/ChatKit).

Límites reales, y cuándo NO confiar en la IA

La seguridad está cerca del territorio YMYL - ser honesta sobre los límites importa más que el hype:

• Prompt injection. No audites código desconocido a ciegas. El código no confiable puede inyectar instrucciones que llevan al modelo a ignorar vulnerabilidades o a ejecutar comandos no intencionados.
• Falsos positivos y falsos negativos. Por defecto, /security-review filtra las clases de DoS, rate-limiting, agotamiento de recursos, open-redirect y validación de entrada que no puede atar a un impacto demostrable - así que "escaneado limpio" no quiere decir "perfectamente seguro". A la inversa, la IA todavía deja pasar fallos sutiles de lógica de negocio (race conditions, TOCTOU, lógica de autorización compleja).
• No reemplaza un pentest profesional. Esta es una herramienta de shift-left para atrapar problemas temprano y barato, no una certificación de seguridad. SAST/DAST y el pentest manual siguen siendo necesarios para sistemas críticos.
• Costo de tokens. Escanear un repositorio grande consume tokens y tiempo considerables; acota el alcance a los directorios sensibles en vez de ejecutar full cada vez.

Preguntas frecuentes (FAQ)

¿El comando /security-review es gratis?

El comando y la GitHub Action son de código abierto de Anthropic, así que no hay una tarifa aparte por usarlos. El costo real es el token/uso de Claude Code bajo el plan en el que estés (Pro, Max o la API por token).

¿En qué se diferencia una auditoría de Claude Code del SAST tradicional?

El SAST en su mayoría casa patrones y reglas fijos, así que tiende a ser ruidoso. Claude Code lee semántica y flujo de datos, así que atrapa problemas dependientes del contexto (como IDOR o lógica de autorización) que el casado de patrones deja pasar - a costa de ser menos determinista y necesitar confirmación humana.

¿Puede la IA reemplazar un pentest profesional?

No. Es una capa de shift-left para atrapar problemas temprano y barato, no una certificación. Los sistemas críticos siguen necesitando pentest manual, junto con SAST/DAST en el pipeline.

¿Es seguro auditar el código de otra persona?

Hay un riesgo de prompt injection: el código no confiable puede inyectar instrucciones que engañan al modelo. Audita solo código confiable, o ejecútalo en un entorno aislado con aprobación manual habilitada para contribuidores externos.

¿Cuántos tokens y cuánto tiempo lleva una auditoría?

Depende del alcance. Revisar un diff pequeño lleva pocos minutos y pocos tokens; escanear un repositorio grande lleva bastantes más tokens y demora notablemente más. Acota el alcance a los directorios sensibles para ahorrar.

¿En qué se diferencia la skill ak-security de escribir mi propio prompt?

Empaqueta STRIDE + OWASP, 4 personas de red-team y el flujo --fix con prueba de guarda en un solo comando, ahorrando esfuerzo de escritura de prompts. En capacidad de detección es más o menos equivalente a escribir un buen prompt tú misma - la diferencia es la conveniencia y la consistencia, no ser "fundamentalmente más fuerte".

¿En qué se diferencia el plugin claude-security de la skill ak-security?

Las dos realmente se solapan ahora. claude-security es gratis, corre multiagente con un paso de verificación independiente y exporta parches que puedes git apply de inmediato. ak-security es de pago (parte de AgentKit), condensado en un comando con un framework ya listo de STRIDE + OWASP + 4 personas + escaneo de secretos/dependencias. Ninguno reemplaza del todo al otro - elige según si ya tienes AgentKit y si quieres el gratis o la opción más compacta.

¿El plugin security-guidance reemplaza las auditorías periódicas?

No. security-guidance es una capa de chequeo puntual continuo que corre en el momento en que Claude escribe código (casado de patrones instantáneo, revisión en segundo plano al final del turno, revisión profunda en el commit/push) - atrapa problemas temprano, pero no reemplaza una auditoría integral, periódica o bajo demanda, como claude-security o el flujo de 6 pasos de arriba. Las dos capas se complementan.

Conclusión y próximos pasos

Una auditoría de seguridad con Claude Code no reemplazará a un experto, pero convierte la caza de vulnerabilidades en un hábito barato y rápido - ejecuta /security-review antes de cada release, haz un escaneo STRIDE periódico o ejecuta claude-security para una pasada de escaneo profundo gratuita, activa security-guidance para revisión continua mientras escribes, y automatízalo en PR confiables. Después, expande hacia una revisión de código con IA integral y refuerza la base con buenas prácticas de seguridad para Claude Code. Y no olvides: una auditoría periódica antes de cada release vale más que un escaneo profundo que luego olvidas.