Un equipo de hackers contra tu app

Qué es y por qué importa

Antes de lanzar una app hecha con IA, la pregunta es siempre la misma: ¿hay un agujero que no veo? Tú usas la app desde dentro, con tu cuenta, y funciona. Quien quiere romperla la mira desde fuera.

Claude Security es un plugin oficial de Claude Code, y no es un control único: es un equipo de agentes. Uno dibuja el mapa de tu arquitectura, otro construye el modelo de amenazas, es decir, quién atacaría tu app, desde dónde y para llevarse qué, y otros buscan vulnerabilidades. Cada fallo encontrado lo analizan agentes verificadores independientes antes de que entre en el informe, así el informe queda corto y sin falsas alarmas. Al final te prepara las correcciones como parches, y los aplicas tú.

Los hackers son falsos en el buen sentido: el plugin lee tu código, en tu sesión, y no ataca la app en producción ni la base de datos real. Sirve a quien está a punto de lanzar una app con datos de personas.

Su estado, comprobado en la documentación oficial de Claude Code el 22 de octubre de 2026: la página del plugin no lo marca como vista previa ni beta, y se instala desde el marketplace oficial de Anthropic. No lo confundas con el servicio gestionado del mismo nombre que vigila los repositorios de forma continua: ese es un producto aparte, para el plan Enterprise.

1. Qué necesitas

• Un plan de pago de Claude, la API de Anthropic o un proveedor como Amazon Bedrock, Google Cloud o Microsoft Foundry. El escaneo usa los workflows dinámicos de Claude Code, un script que coordina muchos agentes a la vez. En el plan Pro los activas desde /config, en la fila Dynamic workflows.
• Python 3 accesible como python3 (prueba con python3 --version). El plugin solo usa la biblioteca estándar, no instala nada, y si tu versión es demasiado antigua su menú te lo dice.
• Git, para escanear solo los cambios y para los parches. El escaneo completo funciona también sin él. Vale Mac, Linux o Windows.

No hay una clave aparte: el plugin no llama a modelos por su cuenta, usa tu sesión, y los agentes funcionan con el modelo que elegiste con /model. Cada escaneo cuenta en tu consumo, puede usar muchos tokens y necesita Claude Code abierto hasta que termine.

2. Instala el plugin

En la carpeta del proyecto, arranca Claude Code con claude y escribe:

/plugin install claude-security@claude-plugins-official

Se abre la ficha del plugin, donde eliges para quién instalarlo: para ti en todos los proyectos, para todos los del repositorio o solo para ti en este repositorio. Si el resumen dice «Run /reload-plugins to apply.», escribe /reload-plugins. Si en cambio te dice que el plugin no está en el marketplace, actualiza el catálogo con /plugin marketplace update claude-plugins-official y vuelve a intentarlo.

3. Lanza el escaneo

1. Escribe /claude-security y elige Scan codebase.
2. El plugin lee el repositorio y te propone todo o una parte, por ejemplo la API o el login, con el número de archivos y el coste relativo de cada opción. Si no lo sabes, responde «I don't know» y elige él.
3. Confirma: antes no arranca nada. Luego deja Claude Code abierto. El detalle, agente por agente y con los tokens de cada uno, lo ves con /workflows, y desde ahí también puedes pararlo todo.

Rinde mejor en modo auto, donde un segundo modelo revisa las acciones en tu lugar y los agentes no te piden permiso en cada paso. En un proyecto grande ve zona por zona: login, pagos, API.

Solo los cambios, antes de fusionar

Si trabajas en una rama, el menú te ofrece escanear solo lo que cambia respecto a la base; también puedes pedir un solo commit o una de tus pull requests abiertas. Solo cuenta lo que ya está en un commit. También se puede pedir con palabras:

/claude-security escanea solo los cambios de mi rama

4. Lee el informe

Cada escaneo escribe en el repositorio una carpeta CLAUDE-SECURITY-<fecha y hora>. Es lo único que cambia en el proyecto, y tiene su propio .gitignore, para que no acabe en un commit por error. Dentro:

• CLAUDE-SECURITY-RESULTS.md, el informe que hay que leer: cada fallo tiene un código (F1, F2…), el impacto, un escenario de ataque, la gravedad, cuánta confianza hay en él y qué hacer.
• Los mismos fallos en .jsonl para programas y en .sarif, el formato estándar que leen GitHub code scanning y otras herramientas de seguridad, con la categoría CWE de cada fallo.
• Un sello, CLAUDE-SECURITY-REVISION-<commit>.json, que dice qué commit se escaneó y con qué esfuerzo, así cada informe queda ligado al código que describe.

Empieza por los fallos más graves y con confianza alta, y antes de corregir haz que te expliquen el escenario:

Abre el informe de Claude Security y explícame el fallo F1 como si no supiera nada de seguridad: quién puede aprovecharlo, qué consigue, por qué pantalla o dirección de la app pasa y qué probabilidad hay. Dime si toca datos de usuarios reales. No modifiques nada.

5. Las correcciones las aplicas tú

Escribe otra vez /claude-security, elige Suggest patches y luego los fallos. Cada parche nace en una copia aparte del repositorio y lo revisa otro agente, que ejecuta los tests si los hay. Solo llega si cierra ese fallo, no abre otros y no cambia nada más; si no, recibes una nota que explica por qué.

Los parches van a patches/ dentro del informe, uno por fallo (F1.patch, F2.patch…), y nunca se aplican solos. Uno se aplica desde el terminal así:

git apply CLAUDE-SECURITY-<timestamp>/patches/F1.patch

Un parche por pull request, así cada uno se revisa y se prueba por separado. O haz que lo haga Claude:

Aplica el parche F1 del informe de Claude Security en una rama nueva, ejecuta los tests y abre una pull request solo con ese cambio. En la descripción escribe el fallo, la corrección y cómo la has probado.

Si el código tocado no tiene tests, la nota del parche lo dice: pruébalo a mano antes de fusionar. Y si ese código ha cambiado mientras tanto, el fallo se salta y el plugin te propone un escaneo nuevo.

6. Los cuatro agujeros típicos de las apps hechas con IA

• La base de datos abierta. Supabase quiere Row Level Security en cada tabla expuesta: sin ella, la clave pública que está en la app puede bastar para leer y escribir. En Firebase busca allow read, write: if true, que la documentación dice que nunca se use en producción. La prueba en vivo: guía PORTA (strikt.fit/porta).
• La clave secreta en el código de la app. La de Supabase (secret, o service_role) nunca en el navegador, en una app publicada ni en GitHub. Y las variables VITE_, NEXT_PUBLIC_ y EXPO_PUBLIC_ acaban en el código que llega al navegador o a la app: ahí nada de claves. Guía CHIAVI (strikt.fit/chiavi).
• El endpoint que no comprueba quién pide. Un endpoint es una dirección del servidor, como /api/pedidos/123. El caso clásico: comprueba el login, pero no que el pedido 123 sea tuyo, así que cambias el número y lees el de otro. Es el primer riesgo del OWASP API Security Top 10 de 2023. El control va en el servidor, no en un botón escondido.
• Ningún límite de peticiones. Si un endpoint llama a una IA o manda emails o SMS, cualquiera lo llama mil veces y la factura te llega a ti: es el cuarto riesgo de la misma lista. Guía LIMITE (strikt.fit/limite).

Para un primer vistazo rápido, antes del escaneo de verdad:

Revisa en el código de esta app los cuatro agujeros clásicos de las apps hechas con IA y para cada uno dime archivo, línea y gravedad: 1) tablas de la base de datos sin reglas de acceso (Row Level Security en Supabase, reglas de seguridad en Firebase) o con reglas que dejan leer todo a cualquiera que haya iniciado sesión; 2) claves secretas en el código que llega al navegador o a la app, incluidas las variables NEXT_PUBLIC_, VITE_ y EXPO_PUBLIC_; 3) endpoints que no comprueban quién hace la petición y si el objeto pedido es suyo; 4) endpoints sin límite de peticiones, sobre todo los que cuestan dinero (IA, email, SMS). No modifiques nada y no imprimas nunca el valor de las claves.

Es una sola pasada, sin los verificadores del plugin. Y las reglas de la base de datos creadas desde el panel, y no en el código, no las ven ni este control ni el plugin: para esas hace falta la prueba en vivo.

Errores comunes

• Empezar con todo un repositorio grande. La primera vez elige una zona, como el login o la API, y mira cuánto consume en /workflows.
• Pedir el escaneo de cambios con el trabajo todavía sin commit. Ese solo mira los commits.
• Aplicar todos los parches a la vez. Uno por pull request, cada uno revisado y probado.
• Tomar un escaneo limpio por una app segura. Los escaneos cambian de una ejecución a otra y leen el código, no la configuración en producción: repítelos y haz también las pruebas en vivo.
• Quitar del código una clave secreta encontrada y quedarse ahí. Hay que revocarla y sustituirla, porque sigue en el historial.

Lista de comprobación

• Plan de pago o API, workflows dinámicos activados (en Pro, desde /config).
• python3 y git funcionando, plugin instalado.
• Primer escaneo en una zona con datos de personas: login, pagos, API.
• Informe leído empezando por los fallos más graves.
• Parches aplicados uno por pull request, los que no tienen tests probados a mano.
• Los cuatro agujeros típicos comprobados también en vivo.
• Escaneo repetido antes de cada lanzamiento importante.

Preguntas frecuentes