Una cuenta de mantenedor de npm comprometida envió versiones maliciosas de Axios, una de las bibliotecas JavaScript más usadas, al registro. El ataque, que ocurrió el mes pasado, pasó por alto GitHub Actions por completo. El atacante publicó directamente a través del CLI npm con credenciales robadas. Una dependencia oculta desplegó un troyano de acceso remoto. Durante tres horas, todos npm install los que extrajeron las versiones afectadas quedaron comprometidos. El radio de la explosión se extendió más allá de lo que nadie esperaba: el ataque llegó más tarde a la propia cadena de firma de OpenAI en macOS, forzando la rotación de certificados.

Ese mismo mes, CVE-2025-55182 convirtió el mecanismo de renderizado del lado servidor de React en un vector de ataque. Un fallo de desserialización en los componentes del servidor React fue explotado durante Next.js para vulnerar hosts 766, robando credenciales de base de datos, claves SSH y secretos AWS. El marco en el que los desarrolladores confiaban como infraestructura se convirtió en el punto de entrada.

Una semana después, CVE-2026-33579 expuso una vulnerabilidad de escalada de privilegios en OpenClaw, una plataforma de agentes de IA de código abierto. Más de 135.000 instancias se ejecutaban sin ninguna autenticación. Un responsable no técnico de una organización había configurado OpenClaw en un VPS personal sin aprobación de IT. Shadow IT, pero con una superficie de ataque impulsada por IA.

Tres incidentes en el mismo mes, con tres vectores de ataque diferentes, pero con el mismo fallo subyacente: en todos los casos, la puerta de revisión de seguridad que se suponía debía detectar el problema llegó después de que la decisión vulnerable ya se hubiera tomado.

El ataque a Axios pasó desapercibido porque el código malicioso nunca pasó por el repositorio. El exploit Next.js sobrevivió a las pruebas de penetración porque la vulnerabilidad residía en el marco, no en la aplicación. La exposición de OpenClaw eludió completamente la revisión de acceso porque el despliegue ocurrió fuera de la visibilidad de la organización.

Las puertas de seguridad revisan lo que ya se ha construido. No pueden impedir lo que nunca fue diseñado para ser seguro.

El modelo de compuertas y por qué persiste

El modelo de seguridad dominante en la mayoría de las organizaciones es una puerta: el desarrollo construye algo y luego seguridad lo revisa antes de que pase a producción. La puerta tiene diferentes nombres según la organización: revisión de seguridad, prueba de penetración, comprobación de cumplimiento, junta de revisión de arquitectura. El mecanismo varía, pero la estructura es la misma: primero construir y validar después.

Este modelo persiste porque es conveniente desde el punto de vista organizativo. Otorga a los equipos de seguridad un papel definido con límites claros. Da a los equipos de desarrollo libertad para construir sin interrupciones. Da al liderazgo una casilla: «seguridad revisada.»

El problema es que el modelo de compuertas fue diseñado para un mundo donde el ciclo de desarrollo se medía en meses, la superficie de ataque era relativamente estable y el número de dependencias era manejable. Ninguna de esas condiciones se mantiene ya.

Los ciclos de desarrollo modernos se miden en días u horas. Las herramientas de codificación por IA aceleran aún más esto. Un desarrollador que utiliza un asistente de IA puede generar y desplegar código más rápido que cualquier equipo de seguridad para revisarlo. La superficie de ataque ahora incluye no solo el código que escribes, sino todas las dependencias que instalan tus herramientas, cada framework en el que confías, cada consentimiento de API que aprueba tu administrador y todos los agentes de IA que actúan en tu nombre.

Cuando escribí sobre modelado de amenazas en la nube, el argumento era que las consideraciones de seguridad deben ocurrir antes del despliegue, no después. Ese argumento solo se ha vuelto más agudo. El desplazamiento hacia la izquierda de la seguridad ya no es el debate; El verdadero desafío es hacer que la seguridad sea una propiedad inherente del proceso de desarrollo en lugar de una validación externa de su resultado.

Lo que se rompe cuando la seguridad es solo una puerta

Los síntomas son consistentes en todas las organizaciones que dependen de la seguridad basada en puertas.

El punto ciego de la dependencia. Cuando una herramienta de codificación de IA se ejecuta npm install o pip install, está tomando una decisión de seguridad. Está confiando en un paquete, sus mantenedores, sus dependencias transitivas y la integridad del registro. El ataque Axios demostró que esta confianza puede ser explotada a nivel de registro, saltándose todos los controles de seguridad a nivel de código. Una puerta de seguridad que revisa el código de la aplicación no puede detectar una dependencia comprometida que se instaló antes de la revisión.

La magnitud de este problema está creciendo. Los agentes de IA que autoinstalan dependencias multiplican el radio de explosión. Cada automatización npm install es una decisión de confianza no revisada. Cuando el proceso de desarrollo genera dependencias más rápido de lo que el proceso de seguridad puede evaluarlas, la puerta se convierte en un cuello de botella que los equipos rodean, o en una formalidad que solo detecta lo que fue diseñada para detectar.

El problema del marco como superficie de ataque. El exploit React2Shell (CVE-2025-55182) convirtió un framework de confianza en un vector de ataque. Las puertas de seguridad suelen asumir que los frameworks son seguros. Revisan el código de la aplicación, no el código del framework. Pero cuando el propio marco es la vulnerabilidad, el modelo de compuertas tiene un punto ciego estructural. Los 766 hosts vulnerados ejecutaban aplicaciones que habrían pasado cualquier revisión de seguridad estándar.

La brecha del camino de consentimiento. Cuando Anthropic extendió el conector Microsoft 365 de Claude a todos los usuarios, creó una ruta de datos que fluye a través de la API de Graph, no del navegador. Los controles de endpoint y las políticas del navegador no ven este camino. Un Administrador Global da su consentimiento y, de repente, un modelo de IA ha leído acceso al correo electrónico corporativo y a las transcripciones de reuniones. La puerta de seguridad para esta decisión es un diálogo de consentimiento, sin modelo de amenazas, sin análisis del flujo de datos y sin marco de gobernanza para evaluar solicitudes de conectores de datos de IA.

Este es el patrón que describí en la brecha de gobernanza de GenAI: organizaciones desplegando capacidades de IA sin la infraestructura de gobernanza que las gestione. La brecha de la vía de consentimiento es la dimensión de seguridad de esa brecha de gobernanza.

La desadaptación de velocidad. este mes, Anthropic reveló que su modelo Claude Mythos descubrió de forma autónoma miles de vulnerabilidades zero-day en todos los sistemas operativos y navegadores principales, incluyendo un error de 27 años en OpenBSD, un fallo de 16 años en FFmpeg y escapes completos del sandbox del navegador. El modelo anterior produjo 2 exploits funcionales a partir de cientos de intentos en Firefox. Mythos produjo 181.

El descubrimiento de vulnerabilidades se ha vuelto barato y rápido. Parchear millones de sistemas desplegados sigue siendo lento y costoso. Cuando la IA puede encontrar vulnerabilidades a velocidad de máquina, un modelo de seguridad que depende de revisiones periódicas y pruebas de penetración programadas queda estructuralmente superado. La puerta se abre una vez cada trimestre. Los ataques llegan de forma continua.

La seguridad como restricción, no como punto de control

La alternativa al modelo de la puerta no es «sin seguridad». Es la seguridad incrustada como una restricción en el propio proceso de desarrollo, de la misma manera que la seguridad de tipos es una restricción en un lenguaje tipado. No se realiza una «revisión de seguridad de tipos» después de escribir código en TypeScript. El compilador lo aplica de forma continua. Las restricciones de seguridad deberían funcionar igual.

Una restricción es diferente de una puerta de tres maneras:

Las restricciones son continuas, no periódicas. Una puerta dispara una vez, en un punto definido del proceso. Una restricción siempre está activa. Cada commit, cada instalación de dependencia, cada cambio de infraestructura se evalúa en tiempo real frente a la restricción.

Las limitaciones son preventivas, no detectivas. Una puerta detecta problemas una vez que existen. Una restricción impide que se introduzcan. Cuando una tubería rechaza un despliegue porque contiene un secreto codificado de forma fija, eso es una restricción. Cuando una prueba de penetración encuentra un secreto codificado en producción, eso es una puerta, y ya es demasiado tarde.

Las restricciones son responsabilidad del equipo de desarrollo, no del equipo de seguridad. Este es el cambio cultural que la mayoría de las organizaciones resisten. Cuando la seguridad es una puerta, el equipo de seguridad la posee. Cuando la seguridad es una restricción, el equipo de desarrollo la posee, y el equipo de seguridad define las restricciones y verifica su aplicación. El equipo de seguridad se convierte en el arquitecto de las restricciones, no en el operador de la puerta.

El ejemplo más contundente de este cambio ocurrió este mes. El núcleo de Linux, el proyecto de código abierto más fundamental del mundo, formalizó su política sobre el código generado por IA en 59 líneas. Los agentes de IA no pueden añadir etiquetas de Signed-off-off. Solo los humanos pueden certificar el Certificado de Origen de Desarrollador. Cada contribución asistida por IA debe llevar una etiqueta «Asistido por» que identifique el modelo y las herramientas utilizadas. El usuario humano asume toda la responsabilidad legal de cada línea, cada error y cada fallo de seguridad. La comunidad del kernel no creó una puerta de revisión para el código de IA. Incorporaron la responsabilidad como una restricción en el propio proceso de contribución: la atribución es obligatoria, la aprobación humana no es negociable y la responsabilidad es inequívoca. Si el núcleo de Linux puede formalizar la responsabilidad del código de IA en 59 líneas, la pregunta para todas las organizaciones de ingeniería es por qué no lo han hecho.

Cinco restricciones que sustituyen a la puerta

No son aspiracionales. Hoy son implementables, y las organizaciones que los han adoptado reportan menos incidentes de seguridad, ciclos de despliegue más rápidos y menos fricción entre los equipos de seguridad y desarrollo.

1. Gobernanza de dependencias en la tubería

Cada instalación de dependencia debe ser validada contra una política antes de entrar en la compilación: versiones fijadas, sumas de comprobación verificadas, escaneo de vulnerabilidades conocidas, cumplimiento de licencias. Esto no es una auditoría periódica de package-lock.json. Es un paso de pipeline que falla la compilación si una dependencia viola la política.

Para el desarrollo asistido por IA, esta limitación es fundamental. Cuando un agente de IA genera código que incluye una nueva dependencia, la canalización debe validar esa dependencia antes de que el código se fusione. La velocidad del agente no lo exime de la restricción.

2. Detección de secretos como gancho previo al compromiso

No hay secretos en el código fuente. Esto es una restricción, no una política. Un gancho de pre-commit que escanea claves API, contraseñas de base de datos y credenciales antes de que el código salga del equipo del desarrollador. Un paso de pipeline que escanea de nuevo antes de la fusión. Una comprobación en tiempo de ejecución que señala cualquier secreto que aparezca en los registros o mensajes de error.

La cantidad de repositorios donde todavía me encuentro con credenciales codificadas es asombrosa. El material de herramientas existe. La barrera es cultural: la creencia de que «lo arreglaremos después» es aceptable cuando la restricción debería hacer imposible el «después».

3. Política de infraestructuras como código

Las políticas de seguridad para la infraestructura deben codificarse y aplicarse en la cadena de despliegue. Requisitos de cifrado, reglas de segmentación de red, políticas de privilegio mínimo IAM, estándares de etiquetado: todo validado automáticamente antes de aplicar cualquier plantilla. Si un módulo de Terraform crea un bucket público de S3, la tubería falla. Sin excepción. No hay aprobación manual.

Esto se conecta directamente con el argumento de Infraestructura como Código No es DevOps. La IAC sin gobernanza automatizada es provisión automatizada con una superficie de ataque expuesta. La capa de gobernanza es la restricción de seguridad.

4. Marco de Revisión de Conectores de Datos de IA

Cada herramienta de IA que solicite acceso a datos de la organización debe pasar por un proceso de revisión definido antes de conceder el consentimiento: ¿a qué datos accede, por qué camino, qué controles se aplican a ese camino, quién lo aprobó y cuándo caduca la aprobación?

Esta es la limitación que habría cambiado la historia del conector Claude M365. En lugar de que un Administrador Global tome solo una decisión de consentimiento, la organización tendría un marco: verificación de clasificación de datos, verificación de cobertura DLP, revisión del alcance de acceso y una aprobación documentada con fecha de caducidad.

5. Modelo de amenaza como artefacto de desarrollo

Un modelo de amenaza no debería ser un documento que la seguridad produce y los desarrolladores ignoran. Debe ser un artefacto de desarrollo que conviva junto al código, actualizado cuando cambia la arquitectura, referenciado cuando se diseñan nuevas funcionalidades. Cuando un desarrollador añade un nuevo endpoint de API, el modelo de amenaza para ese servicio debe actualizarse como parte de la misma solicitud de tirada.

Esta es la evolución del argumento que ya había expuesto en otra publicación: el modelado de amenazas debe ocurrir antes de su despliegue. El siguiente paso es convertirlo en un artefacto vivo que evoluciona con el código, no en un ejercicio puntual que se vuelve monótono en cuanto cambia la arquitectura.

El modelo de las barandillas de la empresa

Existe una forma estructurada de implementar restricciones de seguridad en toda una organización. En la metodología AI-DLC, utilizamos lo que llamamos Especificaciones de Protección Empresarial: un conjunto de principios, restricciones y estándares innegociables organizados por categoría, cada uno con un nivel de gravedad y un propietario designado.

Las categorías abarcan la línea base de seguridad, restricciones de cumplimiento, barreras arquitectónicas, estándares de codificación, preparación operativa, guardas de costes y barreras específicas para IA. Cada barrera de seguridad tiene una gravedad: obligatoria (la infracción bloquea el despliegue), requerida (las excepciones requieren una decisión documentada con aceptación del riesgo) o recomendada (buenas prácticas, desviación señalada pero no bloqueada).

La decisión clave de diseño es que se apliquen barreras de seguridad en el proceso de desarrollo, no que se revisen después. Cada sesión de generación de código, cada cambio de infraestructura, cada despliegue se valida automáticamente contra las barreras de seguridad. El propio colaborador de IA recibe instrucciones para validar su salida frente a las barreras antes de presentarla al equipo.

Esto es seguridad como restricción: las barreras no ralentizan el desarrollo, lo canalizan. Los equipos que trabajan dentro de límites bien definidos avanzan más rápido, no más despacio, porque no desperdician ciclos en reestructuraciones, hallazgos de seguridad o remediación de cumplimiento a posteriori.

El modelo Enterprise Guardrails se explora en profundidad en Reimagine, Don’t Retrofit, donde se conecta con el argumento más amplio de que el desarrollo impulsado por IA requiere gobernanza por diseño, no por revisión.

La Resistencia Cultural

El mayor obstáculo para la seguridad como restricción es cultural, no técnico.

Los equipos de desarrollo resisten las restricciones porque asocian la seguridad con la fricción. «La seguridad nos retrasa» es la objeción más común. Pero la fricción que experimentan es el modelo de puertas: construir algo, esperar a que seguridad lo revise, obtener resultados, reestructurar, volver a enviar. Esa fricción es real, y es producto de la puerta, no de la seguridad en sí.

Los equipos de seguridad resisten el cambio porque cambia su papel. En el modelo de la puerta, el equipo de seguridad es la autoridad. Revisan, aprueban, rechazan. En el modelo de restricciones, el equipo de seguridad define las reglas, pero la tubería las hace cumplir. El valor del equipo de seguridad pasa del control operativo al diseño arquitectónico. Es un puesto más impactante, pero requiere habilidades diferentes y una identidad distinta.

El liderazgo se resiste porque las limitaciones requieren inversión. Construir flujos de trabajo automatizados para la aplicación de políticas, la gobernanza de dependencias, la detección de secretos y la modelización de amenazas requiere tiempo y dinero desde el principio. El modelo de puerta es más barato de empezar: contrata un equipo de seguridad, programa revisiones, marca la casilla. El modelo de restricciones es más barato de operar: menos incidentes, despliegues más rápidos, menos reestructuración. Pero la inversión inicial es real.

¿Qué deberían preguntar ahora los líderes de ingeniería?

Los incidentes de principios de 2026 han hecho que el argumento sea concreto: ataques a la cadena de suministro que eluden la revisión de código, vulnerabilidades de frameworks que eluden la seguridad de aplicaciones, conectores de datos de IA que eluden los controles de endpoint y descubrimiento de vulnerabilidades a velocidad de máquina que supera las revisiones trimestrales.

Cada uno de estos rompe el modelo de compuertas de una manera diferente. Juntos, argumentan que la seguridad debe estar integrada en el proceso de desarrollo como una restricción, no aplicada a su salida como una revisión.

Todas las organizaciones se encargan de la seguridad. Pero pocos cuentan con un modelo de seguridad diseñado para la velocidad, complejidad y superficie de ataque que supone la forma en que se construye realmente el software hoy en día.

Si tu seguridad sigue dependiendo de una puerta que se activa después de que el código está escrito, las dependencias se instalan y la infraestructura está desplegada, la puerta seguirá encontrando problemas. Simplemente los encontrará demasiado tarde.

Ricardo