Por qué la seguridad tradicional de aplicaciones ya no funciona

El modelo de «encontrar y arreglar» para la seguridad de aplicaciones deja de funcionar. Cuando los desarrolladores completan código escrito con IA, despliegan actualizaciones a diario y la lista de vulnerabilidades conocidas crece en progresión geométrica, el enfoque antiguo simplemente se ve desbordado.

Por qué se rompió la AppSec de antes

La seguridad tradicional partía de que los errores detectados podían corregirse antes de la siguiente versión. Pero el mundo ha cambiado. Asistentes de IA como GitHub Copilot aceleran la escritura de código, los desarrolladores publican varias versiones al día (gracias a los pipelines de CI/CD) y el número de vulnerabilidades conocidas (CVE) se ha multiplicado varias veces en un par de años. La velocidad de desarrollo supera ahora la velocidad de detección y corrección de problemas.

El problema se agrava de forma exponencial: cada CVE requiere tiempo para análisis, evaluación, desarrollo del parche, pruebas y reversión de versión. Y cada semana aparecen nuevas vulnerabilidades. La cola crece más rápido de lo que se puede procesar.

El punto de sobrecalentamiento

• Crecimiento exponencial de las CVE: cada año hay más vulnerabilidades nuevas que el anterior. Solo en 2023 se registraron más de 28 mil CVE.
• Parches rezagados: la cola de correcciones es más larga de lo que la humanidad puede procesar. El retraso medio entre el descubrimiento de una vulnerabilidad y la publicación del parche es de meses.
• La IA va más rápido que el QA: los modelos generativos escriben código más rápido de lo que se puede revisar a mano, o incluso con herramientas automatizadas.
• Una cadena infinita de dependencias: una sola vulnerabilidad en una biblioteca popular infecta cientos o miles de aplicaciones, desde móviles hasta infraestructuras críticas.

Desplazarse a la izquierda

Las empresas empiezan a adoptar el «shift-left»: integrar los controles de seguridad en las primeras fases del desarrollo, directamente en el IDE del desarrollador, en lugar de detectar los problemas tras el despliegue en producción. En la práctica, el análisis estático (SAST) bloquea el código poco fiable antes del merge, las comprobaciones de dependencias detectan CVE en versiones de bibliotecas y el análisis dinámico (DAST) simula ataques en un entorno de pruebas.

Pero a menudo ni siquiera eso basta. Algunas empresas pasan a la respuesta automatizada a incidentes: si se detecta una vulnerabilidad en producción, una alerta revierte o aísla de inmediato el código problemático sin intervención humana. Esto reduce la ventana de vulnerabilidad de horas a minutos.

«La seguridad ya no puede ser el último paso del desarrollo.

Debe estar integrada en el código desde la primera línea.»

Un nuevo contrato entre Dev y Sec

El modelo antiguo era antagónico: los desarrolladores escribían rápido y los ingenieros de seguridad criticaban después. El nuevo modelo exige colaboración. El desarrollador se acostumbra a pensar en la seguridad mientras escribe código, y el ingeniero de seguridad se integra en el equipo y escribe automatización en lugar de hacer revisiones manuales.

Qué significa esto

La era en que el equipo de AppSec se sentaba con una lista de verificación y cazaba errores en el pentest llega a su fin. La nueva realidad es una seguridad integrada en el desarrollo, no pegada por encima. DevSecOps, no departamentos de AppSec aislados. Las empresas que no se reorienten se quedarán atrás tanto en velocidad como en fiabilidad.