"Revisión de seguridad con Claude Code" suele querer decir una de tres cosas: correr el comando /security-review en la terminal, sumar la GitHub Action de revisión de seguridad de Anthropic a tus pull requests, o directamente pedirle a Claude Code (o a otro agente de IA) que audite un pedazo de código. Las tres sirven. Ninguna es un programa de seguridad completo, y las tres mandan tu código a un proveedor de modelos.

En esta guía vemos qué ofrece de verdad Anthropic, en qué son buenas y malas estas revisiones, qué pasa con tu código, los riesgos específicos del código generado por IA y un flujo práctico que combina la revisión de un agente de IA con un scanner dedicado y tests.

Qué ofrece Anthropic para revisar seguridad

El comando /security-review

Claude Code trae el comando /security-review. Lo corrés desde la terminal antes de commitear y Claude analiza tus cambios pendientes buscando problemas de seguridad, con una severidad y un fix sugerido para cada hallazgo. Según el centro de ayuda de Anthropic, busca cosas como SQL injection, cross-site scripting, fallas de autenticación y autorización, manejo inseguro de datos y vulnerabilidades en dependencias, y está disponible para usuarios de Claude Code con planes pagos individuales (Pro o Max) y cuentas de API Console con pago por uso.

El comando está definido como un prompt en Markdown. Si lo que trae por defecto no encaja con tu stack, podés copiar security-review.md del repositorio de Anthropic a la carpeta .claude/commands/ de tu proyecto y editarlo, por ejemplo para contarle cuáles son tus helpers de autorización o para saltear categorías que ya cubrís con otra herramienta.

La GitHub Action

Anthropic publica una action open source, anthropics/claude-code-security-review, que corre el mismo tipo de análisis en los pull requests. Se dispara con eventos pull_request, revisa el diff y deja los hallazgos como comentarios de review en las líneas afectadas. Los inputs principales son una claude-api-key obligatoria, el modelo a usar, exclude-directories, un timeout y una ruta a custom-security-scan-instructions. También aplica un filtro de falsos positivos que por defecto descarta categorías como denegación de servicio, rate limiting, agotamiento de recursos, validación de input genérica sin impacto demostrado y open redirects.

Hay una advertencia del README que conviene no pasar por alto: la action no está endurecida contra ataques de prompt injection y solo debería usarse para revisar PRs confiables. Anthropic recomienda activar "Require approval for all external contributors" para que el workflow corra recién después de que un maintainer miró el PR. En un repo público, eso no es opcional.

Claude Code Security

En febrero de 2026 Anthropic anunció Claude Code Security, una capacidad aparte que escanea codebases enteras y sugiere parches para revisión humana. Salió como research preview limitado para clientes Enterprise y Team. Anthropic describe un proceso en varias etapas en el que Claude vuelve a examinar sus propios resultados para filtrar falsos positivos y les asigna severidad y nivel de confianza, y aclara que nada se aplica sin aprobación humana. También informó que, durante su investigación, encontró más de 500 vulnerabilidades en codebases open source en producción usando Claude Opus 4.6.

En qué es buena la revisión de seguridad con IA

  • Lee intención, no solo sintaxis. Un modelo puede notar que un controller filtra las queries por el usuario actual y su hermano no, que es justo la forma típica de una vulnerabilidad IDOR. A un motor de reglas eso le cuesta.
  • Explica. Los hallazgos vienen con el relato de cómo se explota el bug y un fix propuesto, lo que ayuda a devs que no son especialistas en seguridad.
  • Es barata de correr temprano. Un comando antes del commit agarra problemas cuando quien escribió el código todavía tiene todo el contexto en la cabeza.
  • Es flexible. Podés orientarla con instrucciones propias sobre convenciones del framework, librerías internas o tu modelo de amenazas.

Límites que tenés que tener en cuenta

  • Alcance y contexto. El comando y la action se enfocan en los cambios que se revisan. Un diff puede verse seguro mientras el problema real está en un middleware, una policy o un helper que no forma parte del diff. Las ventanas de contexto son grandes, pero el modelo razona sobre lo que le das.
  • No determinismo. Dos corridas sobre el mismo código pueden dar hallazgos distintos. Para un revisor está bien; para un gate de compliance que tiene que ser repetible, es incómodo.
  • Falsos positivos y falsos negativos. El filtrado baja el ruido, y las categorías excluidas (como DoS u open redirects) no se reportan aunque a vos te importen. Una revisión limpia no prueba que el código sea seguro.
  • Prompt injection. El código, los comentarios, la documentación y el texto de los issues son input para el modelo. Un PR malicioso puede intentar convencer al revisor de que no reporte algo, y por eso Anthropic limita la action a PRs confiables.
  • Lo que está fuera de tu código. CVEs en dependencias, secretos enterrados en el historial de git y configuración de cloud necesitan datos y herramientas que una revisión de diff no reemplaza.

La propia guía de Anthropic va en la misma línea: las revisiones automáticas deben complementar, no reemplazar, las prácticas de seguridad existentes y la revisión manual de código.

Qué pasa con tu código

Claude Code corre en tu máquina, pero para hablar con el modelo manda prompts, contexto de código y respuestas por la red (TLS 1.2 o superior). Lo que pasa después depende de la cuenta, según la documentación de uso de datos de Anthropic:

  • Cuentas comerciales (Team, Enterprise, API): retención estándar de 30 días, y Anthropic no entrena modelos con el código o los prompts enviados bajo términos comerciales salvo que el cliente lo habilite.
  • Cuentas de consumo (Free, Pro, Max): 30 días de retención si no permitís el entrenamiento; 5 años si permitís que tus datos se usen para mejorar modelos.
  • Zero data retention está disponible para cuentas de Claude for Enterprise calificadas, y se habilita por organización.
  • Proveedores cloud: Claude Code también puede usar Amazon Bedrock, Google Cloud o Microsoft Foundry, donde aplican los controles de ese proveedor.

Para muchos equipos esto es totalmente aceptable. Se vuelve un problema cuando:

  • los contratos o NDAs con clientes limitan qué subprocesadores pueden ver el código fuente;
  • el repositorio es tu propiedad intelectual central (un motor de trading, un modelo propio, un set de reglas de detección);
  • una regulación o una auditoría te exige probar dónde se procesó el código y por cuánto tiempo;
  • el repo tiene secretos o datos regulados en fixtures, que viajan junto con el contexto.

La alternativa es un modelo que hosteás vos, así el código nunca sale de infraestructura que controlás. Los pros y contras están en IA self-hosted para seguridad de código.

Riesgos de seguridad del código generado por IA

Los agentes de IA escriben mucho código rápido, y los bugs que meten no tienen nada de exótico. Son los clásicos, producidos a más velocidad y revisados con menos cuidado:

  • Autorización faltante. El endpoint anda en la demo, así que nadie nota que carga objetos por ID sin verificar el dueño. El broken access control encabeza el OWASP Top 10 2025.
  • Inyección. SQL, comandos de shell y templates armados con strings siguen apareciendo, sobre todo en scripts de admin "rápidos". Mirá inyección SQL.
  • Secretos en el código. Keys pegadas en un archivo de config para que algo arranque, y después commiteadas.
  • Dependencias. Versiones viejas sacadas de los datos de entrenamiento del modelo, o nombres de paquetes que no existen y que un atacante puede registrar (a veces lo llaman slopsquatting).
  • Defaults permisivos. CORS con comodín, modo debug prendido, tokens de CI demasiado amplios, contenedores corriendo como root.
  • Permisos del agente. Un agente que ejecuta comandos, lee la web y pushea código es en sí mismo una superficie de ataque si lee contenido no confiable.

Un flujo práctico: revisión con IA más scanner más tests

  1. Antes del commit: corré /security-review (o el equivalente de tu agente) sobre el cambio. Arreglá lo que es real y anotá lo que no te convence.
  2. En cada pull request: corré la action de revisión con IA en PRs confiables, más chequeos determinísticos de dependencias y secretos. Una revisión de código con IA dedicada o un scanner que mire el repo completo agarra lo que una revisión de diff no puede ver.
  3. Tests de autorización: para cada endpoint que recibe un ID, sumá un test donde una segunda cuenta intenta leer y modificar los datos de la primera. Los tests son determinísticos; son lo que mantiene arreglado un bug arreglado.
  4. Escaneos periódicos del repo completo para encontrar vulnerabilidades en el código que se fueron acumulando en muchos cambios chicos, y un escáner de seguridad de APIs para tus endpoints.
  5. Revisión humana en zonas de alto riesgo: auth, pagos, multi-tenancy, criptografía. Una revisión de código segura estructurada le sigue ganando a cualquier herramienta en lógica de negocio.
  6. Pruebas externas cuando lo que está en juego lo justifica: un pentesting o pentesting asistido por IA contra un entorno corriendo.

Dónde entra Nurbak

Nurbak está pensado para el paso que las revisiones de diff no cubren: conectás GitHub y escaneás un repositorio completo. El análisis corre sobre el propio modelo de IA self-hosted de Nurbak, así que no manda tu código a OpenAI ni a Anthropic. Reporta vulnerabilidades explotables, incluyendo IDOR/BOLA y autorización faltante, con archivo y línea, más CVEs en dependencias y secretos en el historial de git, con un score de 0 a 100 y explicaciones en lenguaje claro.

Para ser precisos con Claude: el auto-fix opcional es otra cosa. Si le pedís a Nurbak que abra un Pull Request con el fix y un test de regresión de seguridad, ese fix se genera con Claude, solo con tu consentimiento explícito, y el consentimiento queda registrado en un audit trail. El escaneo gratis te muestra completos los 3 hallazgos más importantes, y los planes arrancan en USD 79 por mes. Más detalle en la página de revisión de código con IA.

En resumen

Las herramientas de revisión de seguridad de Claude Code son una buena primera línea: rápidas, explicativas y fáciles de adoptar, sobre todo /security-review antes del commit y la GitHub Action en pull requests confiables. Tratalas como un revisor, no como un gate. Combinalas con escaneo del repo completo, chequeo de dependencias y secretos, tests de autorización y revisiones humanas o pentests periódicos, y decidí a conciencia qué código puede salir de tu infraestructura.

Para seguir leyendo