Escaneando Aplicaciones Vibe-Coded: Por Qué el SAST/DAST Tradicional Se Queda Corto (Parte 6)

Publicado el mayo 28, 2026 por Simon Roses

Serie Seguridad del Vibe Coding

  1. ¿Qué es la Seguridad del Vibe Coding? Una Guía de Campo para 2026
  2. El OWASP Top 10 para Aplicaciones Vibe-Coded
  3. Anatomía de una Brecha de Vibe Coding: Lecciones de los Peores Incidentes de 2026
  4. La Trampa de las Dependencias: Riesgos en la Cadena de Suministro del Código Generado por IA
  5. Autenticación y Secretos: Lo Que la IA Siempre Hace Mal
  6. Escaneando Aplicaciones Vibe-Coded: Por Qué el SAST/DAST Tradicional Se Queda Corto (estás aquí)
  7. Prompt Engineering para Código Seguro
  8. El Checklist de Seguridad del Fundador (próximamente)
  9. Asegurando el Pipeline de Codificación IA (próximamente)
  10. El Futuro de la Seguridad del Vibe Coding (próximamente)

Tiempo de lectura: 20 minutos

TL;DR

Los escáneres de seguridad tradicionales buscan coincidencias de patrones en código que existe. Las vulnerabilidades más peligrosas de las aplicaciones vibe-coded están en código que no existe — controles de autenticación ausentes, falta de limitación de peticiones, lógica de autorización inexistente. Un benchmark SAST de enero de 2026 encontró que las herramientas marcaban como vulnerable entre el 68% y el 75% del código seguro mientras los fallos arquitectónicos pasaban desapercibidos, y Georgia Tech ha rastreado 74 CVEs atribuidos a IA con descubrimientos mensuales que crecieron 6x en dos meses. Las nuevas herramientas nativas de IA están cerrando la brecha, pero a mediados de 2026, la autorización rota y los controles de seguridad ausentes siguen requiriendo revisión humana. Este artículo cubre qué funciona, qué no, y cómo construir un pipeline de escaneo para código generado por IA.

La Paradoja del Escaneo

Tenemos más herramientas de escaneo de seguridad que en cualquier otro momento de la historia del desarrollo de software. SAST, DAST, SCA, IAST, RASP — solo la cantidad de acrónimos sugiere que el problema debería estar resuelto. Y para código escrito por humanos, estas herramientas han ido mejorando de forma constante durante dos décadas. El problema es que las aplicaciones vibe-coded no fallan como las escritas por humanos.

Cuando un desarrollador humano introduce una inyección SQL, normalmente es porque olvidó parametrizar una consulta. Una herramienta SAST detecta la concatenación de cadenas dentro de una llamada SQL por coincidencia de patrones y la marca. Sencillo. Cuando una herramienta de codificación IA introduce un fallo de seguridad, el código suele ser sintácticamente limpio, sigue patrones documentados de la API y pasa todas las pruebas funcionales. La vulnerabilidad no está en cómo está escrito el código — está en lo que el código no hace. Falta validación en el servidor. Falta limitación de peticiones. Faltan controles de autorización. Faltan políticas RLS. No puedes detectar por coincidencia de patrones el código que no existe.

El Vibe Security Radar de Georgia Tech, lanzado en mayo de 2025, rastrea CVEs atribuibles a herramientas de codificación IA trazando los commits de corrección hacia atrás en el historial de Git. Sus cifras lo dicen todo: 6 CVEs atribuidos a IA en enero de 2026, 15 en febrero, 35 en marzo. Un aumento de casi 6x en dos meses. El total confirmado se sitúa en 74, y los investigadores estiman que la cifra real es entre 5 y 10 veces mayor porque la mayoría del código generado por IA no deja marcadores de atribución claros.

Mientras tanto, el informe de estrategia de emergencia de la Cloud Security Alliance — elaborado en un solo fin de semana por más de 60 colaboradores incluyendo a Jen Easterly y Bruce Schneier — advertía que la ventana para corregir vulnerabilidades se está desplomando: el tiempo medio desde la divulgación hasta la explotación confirmada ha caído a menos de un día en 2026, frente a los 2,3 años de 2019. Investigaciones separadas de la CSA han encontrado que el 62% de las muestras de código generado por IA contenían vulnerabilidades.

Los escáneres están funcionando, las vulnerabilidades siguen llegando a producción, y la brecha se amplía.

Qué Detecta Realmente el SAST (Y Qué No)

Static Application Security Testing funciona analizando código fuente sin ejecutarlo. Herramientas como CodeQL, Semgrep, SonarQube y Checkmarx parsean el código en un árbol de sintaxis abstracta y luego buscan coincidencias de patrones contra firmas de vulnerabilidades conocidas — concatenación de cadenas en consultas SQL, eval() sobre entrada no confiable, funciones criptográficas obsoletas. Estos son patrones bien definidos, y SAST los maneja de forma fiable.

El problema son los falsos positivos y los puntos ciegos estructurales.

El Problema de los Falsos Positivos

Un estudio de enero de 2026 evaluó CodeQL, Semgrep, SonarQube y Joern contra OWASP Benchmark v1.2 — 2.740 casos de prueba en Java con estado de vulnerabilidad conocido. CodeQL obtuvo el mayor F1-score con 74,4%, pero marcó el 68,2% de los casos no vulnerables como positivos — 904 falsos positivos en todo el benchmark. SonarQube produjo 1.254 falsos positivos, cubriendo el 45,8% de todos los casos. Semgrep marcó el 74,8% de los casos no vulnerables. Joern tuvo menos falsos positivos con 96, pero alcanzó solo un 8,2% de recall — apenas detecta nada.

Para un vibe coder ejecutando Semgrep contra su código generado por IA por primera vez, esto significa que aproximadamente tres cuartas partes de las alertas que ve son ruido. Después del tercer falso positivo sobre una «inyección potencial» en código que en realidad es seguro, la mayoría acaba ignorando la salida. La señal se ahoga en el ruido, y los problemas reales — los que importan — pasan desapercibidos.

Un caso con el que me encuentro constantemente. En los últimos años he hecho muchas revisiones de código de aplicaciones basadas en AWS en VULNEX, y Semgrep marca los IDs de cuenta de AWS como fugas de información sensible en casi todos los proyectos. El problema es que la propia AWS no considera los IDs de cuenta como información sensible — su documentación indica explícitamente que se pueden compartir cuando sea necesario. Es un falso positivo que aparece en todos y cada uno de los proyectos AWS, entrenando a los equipos a ignorar la salida de Semgrep para ese código por completo. Siempre trabajo con el cliente para entender sus requisitos de privacidad específicos antes de descartar o escalar cualquier hallazgo — algunas organizaciones sí tratan los IDs de cuenta como información interna independientemente de lo que diga AWS — pero este es exactamente el tipo de ruido que erosiona la confianza en las herramientas automatizadas.

El Punto Ciego Estructural

Los falsos positivos son molestos pero manejables. El punto ciego estructural es el verdadero problema. SAST funciona buscando coincidencias de patrones en código que existe. Las vulnerabilidades del código vibe-coded suelen estar en código que no existe.

Pensemos en la aplicación QuickNote de la Parte 5. Los problemas más peligrosos no eran errores en el código — eran funcionalidades ausentes. Sin limitación de peticiones en el endpoint de login. Sin políticas RLS en la base de datos. Sin verificación de autorización en el servidor. Sin expiración de tokens. SAST no puede señalar la ausencia de un control de seguridad, porque no hay código que analizar. Es como pedirle a un corrector ortográfico que te diga que a tu ensayo le falta la conclusión.

Esto es lo que ocurre cuando ejecutas Semgrep contra una aplicación Express.js vibe-coded típica:

semgrep --config=auto ./src

Semgrep probablemente marcará cosas como el uso de innerHTML (problema real — XSS), llamadas a eval() si las hay, y quizás la función de hash MD5. Lo que no marcará: que el endpoint /api/users/:id/notes carece de verificación de propiedad, que jwt.sign() se llamó sin parámetro expiresIn, que toda la aplicación no tiene middleware de limitación de peticiones, que Supabase RLS está deshabilitado en todas las tablas.

Estas son las clases de vulnerabilidad que más importan en aplicaciones vibe-coded, y SAST es estructuralmente incapaz de detectarlas.

Para Qué Sirve el SAST

Esto no es un argumento para dejar de usar SAST. La coincidencia de patrones detecta problemas reales: credenciales hardcodeadas (cuando coinciden con patrones conocidos), llamadas a funciones peligrosas, uso de bibliotecas con vulnerabilidades conocidas, vectores de inyección obvios. Para el subconjunto de vulnerabilidades que parecen errores tradicionales, SAST funciona. El problema es que en aplicaciones vibe-coded, ese subconjunto cubre quizás el 30% de la superficie de riesgo real. El otro 70% es arquitectónico.

Lo Que el DAST No Detecta en la Era de las SPA

Dynamic Application Security Testing adopta el enfoque opuesto — en vez de leer código fuente, ejecuta la aplicación y la ataca desde fuera. OWASP ZAP y Burp Suite envían payloads maliciosos a los endpoints, monitorizan las respuestas y marcan comportamientos que indican vulnerabilidades. Si puedes provocar una inyección SQL mediante una petición HTTP, DAST lo encuentra. Si un payload XSS reflejado aparece en la respuesta, DAST lo detecta.

Para aplicaciones web tradicionales renderizadas en servidor, DAST ha sido razonablemente eficaz. Pero las aplicaciones vibe-coded son abrumadoramente aplicaciones de página única (SPA) construidas con React, Next.js o Vue, y la arquitectura de DAST no funciona bien con ellas.

El Problema del Rastreo

DAST descubre la funcionalidad de las aplicaciones rastreando — siguiendo enlaces, enviando formularios, parseando HTML. Las SPA no funcionan así. Las rutas se gestionan en el cliente mediante JavaScript. Los formularios son componentes React que se comunican a través de llamadas fetch(). Los endpoints de API no se descubren parseando HTML, porque el HTML es una cáscara casi vacía que carga un bundle de JavaScript. Un rastreador DAST que llega a una aplicación React vibe-coded típica ve <div id="root"></div> y quizás algunas etiquetas <script>. Se pierde todo lo demás.

Las herramientas DAST modernas han mejorado en la renderización de JavaScript — ZAP tiene un AJAX Spider, Burp tiene un navegador integrado. Pero siguen teniendo problemas con flujos de autenticación (especialmente OAuth), workflows de múltiples pasos y estado de la aplicación. Un formulario de login que usa useState para el seguimiento de inputs y useEffect para almacenar el token no se comporta como un formulario HTML tradicional, y los rastreadores DAST a menudo no pueden completar el flujo de auth para alcanzar la superficie protegida que hay detrás.

La Brecha de Lógica de Negocio

Incluso cuando DAST llega a los endpoints, se topa con la misma pared que SAST: la vulnerabilidad está en lo que el código no hace. DAST envía un payload de inyección SQL a /api/notes y comprueba si la respuesta parece salida de base de datos. Es una prueba legítima. Pero no comprueba si /api/notes/42 devuelve datos de un usuario diferente. No comprueba si el endpoint /api/admin/users es accesible con un token de usuario normal. No comprueba si el endpoint de login permite 10.000 intentos por minuto.

Estas son vulnerabilidades de lógica de negocio — requieren entender el comportamiento previsto de la aplicación, no solo su superficie de entrada/salida. DAST trata la aplicación como una caja negra. Para aplicaciones vibe-coded donde las vulnerabilidades más peligrosas están en el modelo de autorización, ese enfoque de caja negra se pierde lo que importa.

Dónde el DAST Sigue Ayudando

DAST detecta problemas de configuración que SAST no puede: cabeceras de seguridad ausentes, políticas CORS permisivas, información del servidor expuesta, configuraciones erróneas de SSL/TLS. Estos son problemas a nivel de despliegue, no a nivel de código, y las aplicaciones vibe-coded tienden a salir con configuraciones por defecto terribles porque la IA optimiza para que «funcione en local». Ejecutar ZAP o Nuclei contra tu aplicación desplegada detecta las carencias de la capa de infraestructura.

Nuclei merece una mención específica. Su biblioteca de templates mantenida por la comunidad supera ya los 11.000 templates, y ProjectDiscovery ha introducido generación de templates con IA — describe una comprobación en lenguaje natural, obtén un template YAML. Un pull request reciente añadió templates DAST de Seguridad IA específicamente dirigidos a patrones de sistemas IA. No resuelve el problema arquitectónico fundamental, pero es lo más cerca que ha llegado DAST de ser consciente del vibe coding.

La Brecha del SCA: Cuando las Dependencias No Existen

Las herramientas de Software Composition Analysis (SCA) — Snyk, npm audit, Dependabot, Socket.dev — comprueban las dependencias de tu proyecto contra bases de datos de vulnerabilidades. Si usas lodash@4.17.20 y hay un CVE para esa versión, SCA lo marca. Esta ha sido una de las prácticas automatizadas de seguridad más eficaces de la última década.

El código generado por IA rompe el SCA porque las dependencias son inventadas.

Slopsquatting

El término, acuñado por el investigador de seguridad Seth Larson, describe lo que ocurre cuando las herramientas de codificación IA recomiendan paquetes que no existen en ningún registro. Un estudio de marzo de 2025 que analizó 576.000 muestras de código generado por IA encontró que aproximadamente el 20% recomendaba paquetes que no son reales. Peor aún, el 43% de esos nombres de paquetes alucinados son consistentes entre diferentes ejecuciones de la IA — lo que significa que un atacante puede predecir qué nombres falsos sugerirá la IA, registrarlos y rellenarlos con código malicioso.

Eso es exactamente lo que pasó. En enero de 2026, un paquete npm alucinado llamado react-codeshift se propagó por 237 repositorios a través de código generado por IA. Nadie plantó deliberadamente el nombre del paquete en los datos de entrenamiento de la IA. La IA lo alucinó, múltiples desarrolladores lo instalaron cuando su IA lo sugirió, y finalmente alguien lo registró con código malicioso. El ataque a la cadena de suministro fue automatizado por la propia IA.

Las herramientas SCA no pueden marcar un paquete que no tiene un CVE porque es nuevo y no aparece en ninguna base de datos de vulnerabilidades. npm audit habría reportado cero problemas para react-codeshift — el paquete existía, no tenía CVEs conocidos, y su package.json parecía normal. El comportamiento malicioso estaba en el código, no en los metadatos.

Qué Detecta Cada Herramienta SCA

El panorama SCA se ha dividido en dos campos. Las herramientas tradicionales basadas en CVE (npm audit, Dependabot, escaneo básico de Snyk) comprueban paquetes contra bases de datos de vulnerabilidades conocidas. Si la vulnerabilidad tiene un CVE, la detectan. Si no, no. Para paquetes establecidos con investigación de seguridad activa, esto funciona. Para paquetes alucinados, paquetes recién registrados y paquetes con comportamiento malicioso ofuscado, están ciegos.

Socket.dev representa el enfoque más nuevo — analiza el comportamiento de los paquetes en vez de solo comprobar bases de datos de CVE. Detecta scripts de instalación que exfiltran variables de entorno, llamadas de red a dominios inesperados, código ofuscado que se decodifica en tiempo de ejecución y cambios repentinos en el comportamiento de los mantenedores. Este análisis de comportamiento detecta ataques a la cadena de suministro que las bases de datos de CVE aún no han catalogado.

Snyk DeepCode AI combina análisis simbólico con IA para escanear fragmentos de código a medida que se generan, detectando patrones vulnerables dentro del IDE antes de que lleguen al repositorio. Esto está más cerca de donde el SCA necesita ir para aplicaciones vibe-coded — señalar problemas en el momento de la generación en vez de después de que el paquete se instale y el código se haya hecho commit.

Para los problemas de dependencias que cubrí en la Parte 4, ninguna herramienta SCA por sí sola cubre toda la superficie de riesgo. La respuesta práctica es la superposición: npm audit para CVEs conocidos, Socket.dev para anomalías de comportamiento, y verificación manual de que los paquetes que tu IA sugirió realmente existen y son lo que dicen ser.

Lo Que Realmente Funciona: La Nueva Ola

La brecha entre lo que detectan las herramientas tradicionales y lo que necesitan las aplicaciones vibe-coded ha generado una nueva generación de herramientas de seguridad. Algunas son nativas de IA — usan LLMs para razonar sobre el código en vez de buscar coincidencias de patrones. Otras adoptan enfoques híbridos, combinando análisis tradicional con razonamiento potenciado por IA. Algunas están diseñadas específicamente para aplicaciones vibe-coded.

SAST Aumentado con LLM

La mejora a corto plazo más prometedora es usar LLMs para post-procesar la salida de SAST tradicional. El mismo estudio de enero de 2026 que expuso las tasas de falsos positivos del SAST también probó superponer agentes LLM sobre la salida. La mejor configuración redujo la tasa inicial de falsos positivos del 98,3% al 6,3%. El LLM lee el código señalado en contexto, entiende qué hace, y determina si la alerta es legítima o ruido.

Esto no resuelve el problema del punto ciego — el LLM sigue trabajando a partir de los hallazgos iniciales del SAST, así que el código ausente sigue siendo invisible. Pero hace que la salida del SAST sea realmente utilizable. En vez de 750 alertas donde 700 son falsos positivos, obtienes 50 alertas donde 47 son reales. Esa es la diferencia entre un informe que nadie lee y un informe que impulsa correcciones.

Análisis Neuro-Simbólico (IRIS)

IRIS, publicado en ICLR 2025, adopta un enfoque diferente. En vez de filtrar la salida del SAST, combina el razonamiento de LLM con el análisis estático de CodeQL en un framework neuro-simbólico. El LLM identifica patrones potenciales de vulnerabilidad a través de la comprensión del código, luego CodeQL los valida con análisis formal. Usando GPT-4, IRIS detectó 55 vulnerabilidades en 30 proyectos Java — un 103,7% más que CodeQL solo. Encontró 4 vulnerabilidades previamente desconocidas. Incluso un modelo más pequeño (DeepSeekCoder 7B) detectó 52 vulnerabilidades, lo que demuestra que este enfoque no requiere modelos de última generación.

La tasa de falsos descubrimientos sigue siendo alta con un 84,82%, pero es un 5,21% menor que CodeQL por sí solo. Más importante aún, IRIS detecta categorías de vulnerabilidades que la simple coincidencia de patrones no capta — puede razonar sobre si una verificación de autorización es semánticamente correcta, no solo sobre si existe alguna.

Escáneres Nativos de IA

Dos escáneres de seguridad nativos de IA importantes se lanzaron a principios de 2026. Claude Code Security de Anthropic, publicado en febrero de 2026, utiliza razonamiento LLM para analizar código en busca de vulnerabilidades en vez de buscar coincidencias de patrones. Está disponible para clientes Enterprise y Team, y es gratuito para mantenedores de código abierto. En su periodo inicial, encontró más de 500 vulnerabilidades de alta gravedad en proyectos de código abierto. Codex Security de OpenAI, lanzado en marzo de 2026, escaneó más de 1,2 millones de commits durante su beta, revelando 792 hallazgos críticos y 10.561 de alta gravedad.

Ninguna de las dos herramientas ha sido auditada independientemente, así que hay que tomar las cifras con cautela. Pero el enfoque es fundamentalmente diferente del SAST tradicional — en vez de buscar coincidencias de patrones, estas herramientas leen el código como lo haría un revisor de seguridad, razonando sobre el flujo de datos, los límites de confianza y si el modelo de seguridad tiene sentido a nivel arquitectónico.

Puertas de Seguridad Pre-Publicación

VibeGuard, publicado en abril de 2026, apunta a los puntos ciegos específicos del código generado por IA con un framework de puerta de seguridad pre-publicación. Comprueba cinco categorías: higiene de artefactos (source maps, archivos de depuración que llegan a producción), deriva de configuración de empaquetado, secretos hardcodeados, riesgos de cadena de suministro y exposición de source maps. La motivación surgió de un incidente real — en marzo de 2026, el propio CLI de Claude Code de Anthropic envió un source map de 59,8 MB que exponía aproximadamente 512.000 líneas de código TypeScript. En experimentos controlados con 8 proyectos sintéticos, VibeGuard logró un 100% de recall y un 89,47% de precisión (F1 = 94,44%).

Es una herramienta más específica que un escáner SAST completo, pero apunta exactamente a lo que las aplicaciones vibe-coded hacen mal. Las herramientas de codificación IA son muy buenas generando código que funciona. Son terribles generando artefactos de despliegue limpios y reforzados. VibeGuard se sitúa en esa brecha.

Plataformas de Seguridad Agénticas

DryRun Security se define como seguridad de código «nativa de IA, agéntica». En vez de buscar coincidencias de patrones en archivos individuales, inspecciona el flujo de datos entre archivos y servicios — entendiendo cómo se mueven los datos por la aplicación a nivel arquitectónico. Su Informe de Precisión SAST de 2025 mostró un 88% de detección de vulnerabilidades sembradas desde el primer uso, superando a cuatro analizadores estáticos tradicionales líderes, con particular fortaleza en lógica compleja y fallos de autorización. En febrero de 2026, lanzaron un DeepScan Agent que realiza revisiones de seguridad de repositorios completos.

Escape recaudó 18 millones de dólares en marzo de 2026 específicamente para reemplazar los escáneres heredados con pruebas de seguridad dirigidas por agentes IA. Vale la pena estudiar la metodología de su equipo de investigación: escanearon 5.600 aplicaciones vibe-coded accesibles públicamente y encontraron más de 2.000 vulnerabilidades de alto impacto. El desglose es revelador — más de 400 secretos expuestos y 175 casos de exposición de datos personales, incluyendo historiales médicos y números de cuentas bancarias. APIs sin autenticación, falta de limitación de peticiones y BOLA/IDOR dominaron los hallazgos. Estas son exactamente las clases de vulnerabilidad que los escáneres tradicionales no detectan.

Lo Que los Escáneres No Detectan: Los Puntos Ciegos del Vibe Coding

A lo largo de la investigación, seis patrones de vulnerabilidad en código generado por IA evaden consistentemente las herramientas de escaneo tradicionales. Conocerlos significa saber qué buscar manualmente, incluso cuando el escáner te da un informe limpio.

1. Controles de Seguridad Solo en el Frontend

La IA genera un auth guard de React que comprueba si hay un JWT en localStorage antes de renderizar las rutas protegidas. El guard funciona — los usuarios no autenticados ven la página de login. Pero la API detrás de esas rutas acepta cualquier petición, con o sin token. SAST escaneando el backend ve endpoints de API que reciben peticiones y devuelven datos. No hace referencia cruzada con el frontend para comprobar si existe cumplimiento del lado del servidor. DAST puede que ni siquiera llegue a los endpoints si no puede completar el flujo de auth del frontend.

2. APIs Sin Autenticación

El escaneo de Escape de 5.600 aplicaciones vibe-coded encontró aplicaciones con 7–12 endpoints de API públicos realizando operaciones destructivas (DELETE, PUT) sin ninguna autenticación. La especificación OpenAPI — cuando existía — no tenía esquemas de seguridad definidos. SAST no marca un endpoint por no tener middleware de auth, porque «sin middleware» no es un patrón que pueda detectar. El código es perfectamente válido; simplemente le falta un requisito de seguridad.

3. Falta de Limitación de Peticiones

Como mostré en la Parte 5, un endpoint de login sin limitación de peticiones permite a un atacante probar las 1.000 contraseñas más comunes en diez segundos. Ningún escáner marca esto porque la limitación de peticiones es una adición de middleware, no un patrón de código. El endpoint de login en sí es correcto — valida credenciales y devuelve un token. La ausencia de express-rate-limit o su equivalente es una decisión de despliegue, no un error de código.

4. BOLA/IDOR Sin IDs Secuenciales

La brecha BOLA de Lovable de la Parte 5 es el ejemplo canónico. La API comprobaba la autenticación (token Firebase válido) pero no la autorización (¿el usuario de este token es propietario de este proyecto?). SAST ve la llamada a firebase.auth() y considera el endpoint protegido. La verificación de propiedad que debería seguir es lógica de negocio que el escáner no puede inferir. DAST podría teóricamente detectar IDOR probando con dos sesiones de usuario diferentes, pero la mayoría de las configuraciones DAST no preparan escenarios de prueba multiusuario.

5. Configuraciones Inseguras por Defecto

El código generado por IA usa Supabase con RLS deshabilitado, Firebase con reglas de seguridad configuradas como allow read, write: if true, Express sin configuración CORS (permitiendo todo por defecto), y bibliotecas JWT con el parámetro algorithms sin establecer (permitiendo el ataque none). Ninguna de estas son errores. Son todas configuraciones válidas que resultan ser inseguras. SAST necesitaría reglas específicas de configuración para marcarlas — y la mayoría de herramientas no incluyen reglas para «tabla Supabase sin política RLS.»

6. Fallos de Higiene de Artefactos

Source maps enviados a producción, archivos .env incorporados en imágenes Docker, node_modules incluidos en artefactos desplegables, logging de depuración activo en producción. Estas no son vulnerabilidades de código — son fallos de empaquetado y despliegue que exponen código fuente, secretos y arquitectura interna. El SAST y DAST tradicionales no escanean artefactos de compilación en absoluto.

Construyendo un Pipeline de Escaneo que Funcione

Ninguna herramienta por sí sola cubre toda la superficie de riesgo de una aplicación vibe-coded. La respuesta práctica es superponer herramientas donde cada una cubra una brecha diferente, ejecutarlas en el orden correcto, y saber qué sigue requiriendo revisión humana.

Capa 1: Pre-Commit (Detectar Secretos Antes de que Se Envíen)

Antes de que el código llegue al repositorio, ejecuta detección de secretos. Esta es la comprobación automatizada con mayor retorno de inversión porque los secretos en control de versiones son permanentes — incluso si borras el archivo, el secreto sigue en el historial de Git.

# Instalar y ejecutar Gitleaks como hook de pre-commit
gitleaks detect --source . --verbose

# O TruffleHog para análisis más profundo incluyendo historial de Git
trufflehog filesystem . --only-verified

Configúralo como hook de pre-commit de Git. Cada commit se escanea. Si se detecta un secreto, el commit se bloquea. Esta es la única capa donde la automatización es genuinamente fiable — los patrones están bien definidos y los falsos positivos son manejables.

Capa 2: Pipeline CI (SAST + SCA en Cada Push)

Ejecuta SAST y SCA en tu pipeline CI. El objetivo aquí no es la perfección — es detectar el 30% de problemas que la coincidencia de patrones maneja bien.

# Semgrep con auto-config (extrae conjuntos de reglas relevantes para tu stack)
semgrep --config=auto --error --json ./src > semgrep-results.json

# npm audit para CVEs conocidos de dependencias
npm audit --audit-level=high

# Socket.dev CLI para análisis de comportamiento de dependencias
socket scan create --repo . --branch main

El paso crítico es filtrar la salida del SAST. Si tu equipo se ahoga en falsos positivos, empieza solo con las reglas de alta confianza. El conjunto de reglas p/security-audit de Semgrep es más específico que --config=auto. Para SCA, diferencia entre dependencias de desarrollo y producción — un CVE en una dependencia de desarrollo tiene menor prioridad que uno en tu middleware de autenticación.

Capa 3: Post-Despliegue (DAST Contra la Aplicación en Ejecución)

Después del despliegue, ejecuta DAST contra tu aplicación real. Esto detecta problemas de configuración que no existen en el código fuente.

# Nuclei con templates de la comunidad
nuclei -u https://yourapp.com -t nuclei-templates/ -severity critical,high

# Escaneo básico con ZAP
docker run -t zaproxy/zap-stable zap-baseline.py -t https://yourapp.com -r report.html

Para SPAs, usa el AJAX Spider de ZAP o el rastreo basado en navegador de Burp en lugar del rastreador HTTP por defecto. Proporciona al escáner tu especificación OpenAPI si la tienes — descubrirá endpoints que el rastreador no encuentra.

Capa 4: Revisión Aumentada con IA (La Nueva Capa)

Esta es la capa emergente que no existía hace un año. Si tienes acceso a Claude Code Security, Codex Security o DryRun, ejecútalos como complemento al SAST tradicional. Cubren la brecha de razonamiento arquitectónico — detectando controles ausentes, evaluando si la lógica de autorización es semánticamente correcta y entendiendo el flujo de datos entre los límites de los servicios.

Si no tienes acceso a estas herramientas comerciales, puedes aproximar el enfoque ejecutando un LLM contra tu salida de SAST para filtrar falsos positivos (la técnica del estudio de enero de 2026 redujo los falsos positivos del 98,3% al 6,3%), o pidiendo a un LLM que revise archivos clave de seguridad con preguntas dirigidas: «¿Este endpoint verifica que el usuario autenticado es propietario del recurso solicitado?» «¿Hay un middleware de limitación de peticiones aplicado a esta ruta?»

Capa 5: Revisión Manual (La Capa Insustituible)

Llevo más de dos décadas en seguridad de aplicaciones. Cada encargo que hago en VULNEX empieza con escaneo automatizado y termina con revisión manual, porque las herramientas automatizadas siempre se dejan algo. Para aplicaciones vibe-coded, la revisión manual es aún más importante porque las clases de vulnerabilidad son arquitectónicas.

El checklist de revisión manual es más corto de lo que la gente piensa. Para cada endpoint de API: ¿comprueba autenticación? ¿Comprueba autorización — no solo «está logueado este usuario» sino «tiene este usuario permiso para acceder a este recurso específico»? ¿El cliente envía algún dato que controla el comportamiento del servidor (IDs de usuario, flags de rol, overrides de precio) sin validación del lado del servidor? ¿Hay funciones de administración accesibles para usuarios normales?

Una revisión manual enfocada de la capa de auth y autorización lleva horas, no días, y detecta los problemas que todas las herramientas automatizadas se pierden.

Lo Que Cuesta

Para un fundador en solitario o un equipo pequeño, esto es aproximadamente lo que implica. Las capas 1–3 usan herramientas gratuitas y de código abierto — Gitleaks, Semgrep, npm audit, la capa gratuita de Socket.dev, Nuclei. Configurar el pipeline CI completo lleva una tarde si manejas GitHub Actions o similar, un fin de semana si partes de cero. La capa 4 varía: Claude Code Security es gratuito para proyectos de código abierto, DryRun y Escape tienen precios comerciales que normalmente empiezan en unos pocos cientos al mes. La capa 5 es donde se encarece si no tienes experiencia en seguridad en el equipo. Una revisión enfocada de auth y autorización por parte de una consultora de seguridad suele costar entre 3.000 € y 10.000 € dependiendo del tamaño y complejidad de la aplicación. Es dinero real para una startup en fase inicial — pero saltársela es precisamente lo que provocó las brechas de la Parte 3.

El Checklist de Escaneo

Ejecuta esto contra tu aplicación vibe-coded. Cada elemento aborda una brecha específica del escaneo tradicional.

Secretos (Pre-Commit):

  1. Ejecuta gitleaks detect --source . --verbose y trufflehog filesystem . --only-verified — cero hallazgos antes de cualquier commit
  2. Busca claves filtradas en los bundles del frontend: grep -r "sk-\|API_KEY\|SECRET\|Bearer\|supabase\|firebase" dist/ build/
  3. Verifica que los archivos .env nunca se han subido al repositorio: git log --all --diff-filter=A -- '*.env' '.env*'

SAST (Pipeline CI):

  1. Ejecuta semgrep --config=p/security-audit --error ./src — usa el conjunto de reglas enfocado, no --config=auto, para mantener el ruido controlado
  2. Revisa manualmente cada hallazgo high o critical — busca innerHTML, eval(), dangerouslySetInnerHTML, SQL sin sanitizar

SCA (Pipeline CI):

  1. Ejecuta npm audit --audit-level=high — soluciona todos los CVEs altos y críticos
  2. Verifica que las dependencias son reales: comprueba que cada paquete en package.json tiene una página legítima en npmjs.com con descargas y un mantenedor real
  3. Ejecuta Socket.dev o Snyk para análisis de comportamiento — detecta ataques a la cadena de suministro que las bases de datos de CVE no captan

DAST (Post-Despliegue):

  1. Ejecuta nuclei -u https://yourapp.com -severity critical,high contra tu aplicación desplegada
  2. Comprueba cabeceras de seguridad y CORS: curl -s -D- https://yourapp.com | grep -i "x-frame\|x-content-type\|strict-transport\|content-security-policy" y prueba con Origin: https://evil.com

Manual (Las Brechas):

  1. Prueba cada endpoint de API sin el frontend — ¿requiere autenticación?
  2. Prueba acceso entre usuarios — ¿puede el Usuario A acceder a los recursos del Usuario B cambiando IDs?
  3. Prueba endpoints de administración con el token de un usuario normal, envía 100 peticiones rápidas al login para verificar la limitación de peticiones (espera un 429), y confirma que las reglas de Supabase RLS / Firebase están habilitadas y limitadas al usuario autenticado

Este pipeline no detectará todo. Pero cubre las capas donde las herramientas automatizadas son fiables, señala las áreas donde están ciegas, y dirige el esfuerzo manual donde más importa. Si no estás ejecutando ningún escaneo hoy — que, por lo que veo en las evaluaciones, es el caso de la mayoría de aplicaciones vibe-coded — empezar con los puntos 1, 2, 11 y 12 te da el mayor valor de seguridad con el menor esfuerzo.

Lo Que Deberías Sacar de Esto

Los escáneres de seguridad tradicionales no están rotos. Están resolviendo un problema diferente. Fueron construidos para un mundo donde los desarrolladores entienden su código y cometen errores localizados — una consulta sin parametrizar, una función criptográfica mal usada, una dependencia desactualizada. El código generado por IA introduce una nueva clase de vulnerabilidad: código arquitectónicamente correcto con controles de seguridad ausentes. El login funciona, el JWT valida, la base de datos responde — y el hecho de que cualquier usuario autenticado pueda leer los datos de cualquier otro usuario no es algo que un buscador de patrones pueda detectar.

El panorama del escaneo está evolucionando rápido. Las herramientas nativas de IA que razonan sobre el código en vez de buscar coincidencias de patrones están empezando a cerrar la brecha. El enfoque IRIS (análisis neuro-simbólico), el filtrado de falsos positivos basado en LLM y las puertas pre-publicación como VibeGuard son pasos en la dirección correcta. Pero a mediados de 2026, ninguna herramienta automatizada detecta de forma fiable la lógica de autorización rota, la falta de limitación de peticiones o los controles de seguridad solo en el cliente. Eso sigue requiriendo revisión humana.

Mi flujo de trabajo en VULNEX: Gitleaks y TruffleHog para secretos, Semgrep para problemas basados en patrones, npm audit más Socket.dev para dependencias, Nuclei para la superficie desplegada, y después pruebas manuales de cada frontera de autenticación y autorización. Las capas automatizadas llevan minutos, la revisión manual lleva horas — y por mi experiencia, es en la revisión manual donde aparecen las vulnerabilidades críticas.

Si eres un fundador en solitario o un ingeniero sin formación en seguridad — que describe a la mayoría de la gente que construye con herramientas de codificación IA — la capa 5 es la difícil. No puedes revisar lo que no sabes buscar. Mi consejo práctico: ejecuta las capas 1–3 como mínimo, son gratuitas y detectan problemas reales. Si tu aplicación maneja datos de usuario, pagos o cualquier cosa sensible, presupuesta una revisión de seguridad profesional antes de lanzar. No tiene que ser un pentest completo — una revisión enfocada de tus fronteras de autenticación y autorización, acotada a 2–3 días, detecta los problemas arquitectónicos que la automatización no alcanza. La Parte 8 de esta serie profundizará en esto con un checklist completo para fundadores.

Como siempre: no te fíes de nada, verifica todo.

Lecturas Adicionales

Referencias

Esta entrada fue publicada en AI, IA, Pentest, Privacidad, SDL, Seguridad y etiquetada , , , , , , . Guarda el enlace permanente.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.