La semana de la realidad: el coding con IA choca contra la pared de la seguridad

La semana de la realidad: el coding con IA choca contra la pared de la seguridad

Abr 30, 2026 ai-assisted development secure coding vibe coding vulnerability research cloud security software supply chain code generation security benchmarks

La semana de la realidad: El coding con IA choca contra la seguridad

La última semana de abril de 2026 dejó un mensaje claro para quienes usan IA en el desarrollo: hemos creado herramientas potentes, pero la seguridad aún cojea. Cinco anuncios clave y estudios revelaron un ecosistema atrapado entre la velocidad innovadora y una deuda de seguridad acumulada.

Cifras que duelen

El dato que más impacta: el 20% de las apps reales hechas con herramientas de coding IA tienen fallos graves de seguridad. No es teoría. Están en producción ahora mismo, según datos de Wiz Research en Google Cloud Next.

"Graves" incluye accesos rotos, endpoints con datos expuestos y credenciales filtradas en el código generado. Miles de apps heredan estos riesgos de sus "compañeros IA". Y ojo: ese 20% podría ser generoso. Otros estudios independientes apuntan a números peores.

El benchmark que no miente: 23,8%

SecureVibeBench analizó 105 retos de coding sacados de vulnerabilidades reales en la base OSS-Fuzz. La consigna: resolver el problema sin repetir el patrón exacto del CVE anterior.

Cinco agentes IA lo intentaron: OpenHands, Claude Sonnet 4.5 y otros tres. El mejor resultado: 23,8% de soluciones funcionales y seguras.

O sea, en el 76,2% de los casos, el código fallaba, reintroducía la vulnerabilidad o ambas cosas. No fue un truco. Usaron fuzzing real (análisis dinámico), no solo linters estáticos. Detectaron overflows, buffers mal usados y race conditions. Bugs que acaban en CVEs.

¿Por qué pasa esto?

Los anuncios de la semana muestran un patrón. Wiz integra escaneos directamente en el IDE. Red Gate detalla cinco fallos típicos en código de bases de datos generado por IA, con el borrado accidental en producción de Replit como ejemplo. Lovable admite un 10% de problemas de seguridad en su propio código.

Las empresas no lo ignoran. Lo reconocen y agregan controles. Pero hay desigualdad: gigantes como Wiz, Red Gate o Vercel pueden permitirse escaneos y políticas. ¿Y el fundador solo con Cursor en un side project? ¿O el CEO no técnico que arma herramientas internas con IA?

(Habla The New Stack de ejecutivos que usan "desarrollo solo con LLM". Un CEO montó un BBS vibe-coded que corre en 23 MB de RAM sin incidentes en un año. Suena bien, pero ¿es la norma o solo los que sobrevivieron?)

El marco del colapso de confianza

Forrester ve el breach de Vercel/Context.ai no como un caso aislado, sino como el fin de los modelos de responsabilidad compartida rotos. Crítica clave: decisiones que cargan la seguridad al dev, como etiquetar variables sensibles como opcional.

El punto profundo: la seguridad perimetral de SaaS es una ilusión. Si la plataforma de deploy también genera código IA, guarda secrets y logs, la "frontera de confianza" se diluye.

Qué hacer en tu stack

Si usas coding asistido por IA, cambia el chip ya:

1. Parte de que el código generado tiene bugs. Prueba como si fuera de un junior nuevo. SAST, análisis dinámico, fuzzing.

2. Haz inventario de tus herramientas IA. La idea de AI-BOM de Wiz es básica higiene. Registra modelos, frameworks e IDE como Claude, Copilot, Cursor o Gemini. Tienen perfiles de seguridad distintos.

3. Rechaza defaults flojos. Si tu plataforma te pide etiquetar manualmente lo "sensible", huye. La seguridad debe ser por defecto, no opt-in. Igual con escaneos automáticos de código IA.

4. Prepárate para el 76%. Con un 23,8% de aciertos en SecureVibeBench, asume que la IA falla en seguridad. Combínala con revisiones, análisis estático y hardening en runtime.

5. Prioriza por dominio. Código de bases de datos, auth y APIs tiene el radio de explosión mayor. Refuérzalos primero.

La visión positiva

No es un no a la IA en desarrollo. CEOs como Moshe Bar (desarrollo solo LLM) o el de OutSystems (con A/B testing) demuestran que acelera sin bajar calidad, si lo diseñas bien.

Eso implica:

  • Escaneos de seguridad en el IDE antes del commit
  • Remedios prearmados vía extensiones
  • Inventario vivo de modelos y frameworks IA
  • Tests iguales a los de dependencias externas
  • Presión a vendors para seguridad implícita

Red Agent de Wiz, el análisis de Red Gate y SecureVibeBench no son profecías negras. Son la infra que siempre necesitábamos. Solo que la estamos armando después de soltar IA a millones de devs.

Patrón de la semana: despertar tarde, remedio rápido. Queda ver cuántas apps del limbo cargan ese 20% de vulnerabilidades en producción.


El desglose

Wiz en Google Cloud Next: Stack de tres: Red Agent (tests ofensivos), AI-BOM (inventario de modelos) y escaneo inline para código de Lovable. Remedios nativos en Claude Code y Cursor. 20% de apps IA con issues graves.

SecureVibeBench: 105 retos C/C++ de 41 proyectos OSS-Fuzz. ¿Código funcional y seguro? Mejor: 23,8%. El resto falla función o repite vulnerabilidades.

Análisis de Red Gate: Cinco patrones críticos en código DB IA. Ejemplos: borrado en Replit y 10% de issues en Lovable.

Coding de CEOs: Codenotary CEO arma BBS con 500 users en 23 MB, cero incidentes. OutSystems CEO testa su plataforma vs. Claude.

Forrester: Breach Vercel/Context.ai acaba con el pensamiento perimetral SaaS. Plataformas que mezclan generación de código, secrets y logs rompen la responsabilidad compartida.


Esta semana confirmó: el coding con IA está aquí, produce y aprendemos —a veces a golpes— a securizarlo.

Read in other languages:

RU BG EL CS UZ TR SV FI RO PT PL NB NL HU IT FR DE DA ZH-HANS EN