El problema: los agentes de IA eligen dependencias más rápido de lo que tu equipo las puede revisar
El CISO de Chainguard, Quincy Castro, lo resume en una frase que cualquier founder debería grabarse: "La velocidad ha superado a la gobernanza y los controles". Cuando un asistente de IA puede generar código al instante, el ciclo tradicional de pedir, revisar y aprobar se convierte en un cuello de botella. Los ingenieros ya no se bancan un mundo en el que terminan su trabajo en minutos y luego todo se apila contra un proceso manual heredado.
El problema tiene dos capas. Por un lado, los agentes de IA seleccionan dependencias según la relevancia para un prompt, no según qué tan bien se mantiene el paquete. Por el otro, los programas de citizen developer ponen el ensamblaje de software en manos de personas sin formación tradicional en ingeniería, lo que dificulta la validación técnica.
Por qué la seguridad nunca revisó bien el open source (y la IA lo acelera)
Castro, que lleva cuatro roles como CISO a cuestas, asegura que la IA no rompió un proceso que funcionara: las áreas de seguridad siempre fueron las últimas en aprobar, después de que el equipo de ingeniería llevaba la idea del whiteboard al MVP. "La idea de que un equipo pequeño de seguridad pueda ser especialista en cada stack tecnológico de una compañía Fortune 500 es ridícula", dice.
🤖 La IA no es solo para leer sobre ella
En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.
👥 Aplicarla en la comunidadEsa debilidad previa es la razón por la que la cadena de suministro de software se volvió un objetivo tan jugoso. Si ya éramos malos revisando, sumar la velocidad y la escala del desarrollo agéntico solo empeora el cuadro. Las puertas de control existían porque las organizaciones asumían que el juicio individual podía fallar; el desarrollo con agentes está borrando la pausa donde esas puertas se activaban.
El 96% de los CVEs vive fuera del top 20 de imágenes de contenedor
El informe State of Trusted Open Source de Chainguard de marzo de 2026 encontró que el 96,2% de las vulnerabilidades comunes (CVEs) se concentra fuera de las 20 imágenes de contenedor más usadas; la edición de junio subió esa cifra al 97%. Los programas de hardening empresarial se concentran en el pequeño conjunto de imágenes que cubre el resto.
"La concentración del riesgo está invertida respecto de donde va la atención corporativa", dice Castro. Las organizaciones invierten fortunas en endurecer un puñado de imágenes conocidas, mientras la exposición real vive en la larga cola.
Los atacantes van por la larga cola
Los atacantes prefieren proyectos menos visibles porque los repos populares tienen más mantenedores, más contribuidores revisando cambios y más escrutinio automatizado, lo que los hace caros como objetivo. En lugar de colar malware en un proyecto open source muy visible, buscan proyectos peor mantenidos y luego empujan a los developers hacia ellos.
Castro menciona una operación reciente que produjo forks en masa de proyectos legítimos, sembró malware y los dispersó lo suficiente para que los developers confundieran el fork con el repositorio oficial, terminando por meter capacidad atacante en sus pipelines de CI/CD. En marzo, los intrusos que se apoderaron del scanner Trivy forzaron un push de 75 de 76 etiquetas de versión a commits que cargaban un infostealer, y luego usaron los secretos robados para publicar paquetes maliciosos en npm río abajo.
Las técnicas en aumento incluyen typosquatting, takeover de cuentas de mantenedores, puntos de distribución envenenados y dependency riding. La confianza que todas esas tácticas explotan, argumenta Castro, nunca estuvo justificada, dado que cualquiera puede escribir y publicar código open source.
Dependencias transitivas: el punto ciego
Meter un paquete en tu build significa heredar todo lo que sus autores eligieron como dependencia, y todo lo que esas dependencias eligieron a su vez. La visibilidad se desvanece dos o tres capas hacia abajo, lo que hace que el código malicioso a esa profundidad sea mucho más difícil de detectar.
"Hemos tenido detecciones que se disparan para una dependencia con malware, y descubrimos que no es parte de la imagen del contenedor, ni aparece en el bill of materials", cuenta Castro. "Rebobinamos la cinta y vemos que fue una dependencia de una dependencia transitiva que corrió brevemente durante el build. ¿Era real? Sí. ¿Una persona normal construyendo esto tendría alguna señal de que estaba en riesgo? Absolutamente no".
El escaneo no escala con código generado por IA
El argumento de Castro es directo: hacer más de lo mismo que nunca funcionó del todo, pero a mucha mayor velocidad y escala, significa que ya perdiste antes de empezar. Las empresas ya batallan para parchear vulnerabilidades severas, ni hablar de las medias y altas que aceptan como riesgo de forma recurrente. Más escaneo y más parcheo no aguantan un volumen geométricamente mayor de código desarrollado por agentes.
Los firewalls de developer y las políticas que rompen builds heredan la misma limitación: interceptan tarde, cerca del ingeniero y de producción, convirtiendo un fallo de aprovisionamiento en una cola de pull requests bloqueados. "Los ingenieros terminan lidiando con un montón de builds rotos cuando lo que quieren es enviar productos que la gente ame", resume.
El contexto importa: el caso Trivy y el efecto multiplicador
La advertencia de Castro se sostiene con evidencia reciente. En mayo de 2026, la firma francesa CrowdSec confirmó el robo de código fuente de unos 300 repositorios (170 de ellos privados) como consecuencia directa del ataque a la cadena de suministro de TanStack de mayo de 2026, donde el grupo TeamPCP publicó 84 artefactos maliciosos en 42 paquetes.
El hilo se extiende aún más: una investigación de CloudSEK y Hudson Rock reportó que credenciales de más de 2.500 organizaciones, incluyendo Microsoft, Amazon, Cisco, Samsung y Salesforce, quedaron expuestas durante una ventana de 40 minutos en marzo, después de que versiones comprometidas de LiteLLM (un tool open source que agiliza el desarrollo con IA) se descargaran del Python Package Index. El vector inicial fue precisamente el scanner Trivy comprometido, infectando también KICS y el SDK de Python de Telnyx.
Mientras tanto, una campaña npm activa descubierta por Checkmarx muestra lo rápido que los atacantes se adaptan: el paquete malicioso indexed-btree —diseñado para imitar al legítimo sorted-btree— evade las defensas de scripts de instalación de npm v12 escondiendo el loader en el método BTree.prototype.set(), que se ejecuta en runtime. Checkmarx detectó nueve paquetes vinculados a la misma operación, con descargas semanales acumuladas que superan los 7 millones.
El mercado de imágenes hardened se recalienta
El espacio que Chainguard ayudó a crear ya no está solo. Según una nota de TechTarget, Docker liberó los más de 1.000 imágenes de su catálogo Docker Hardened Images bajo licencia Apache 2.0, citando explícitamente a Chainguard y a su ronda de US$280M como presión competitiva. Otros competidores incluyen ActiveState, BellSoft, Broadcom, Cloudsmith, Echo, Lineaje, Minimus, RapidFort, Red Hat, Seal Security, SUSE y Wiz, además del Iron Bank de la Fuerza Aérea de EEUU.
La misma nota destaca que apenas el 8,8% de los encuestados de la IDC DevSecOps and Software Supply Chain Security Survey (511 respondents, julio 2025) mencionó imágenes hardened y open source confiable como una de sus tres prioridades de gasto en seguridad de supply chain para los siguientes 12 meses. Chainguard, en paralelo, superó los 1.000 millones de build manifests en septiembre de 2026, duplicando su volumen de producción en seis meses y totalizando más de 3.000 imágenes de contenedor únicas y 675.000 variantes.
¿Qué significa esto para tu startup?
Si tu equipo usa GitHub Copilot, Cursor, Claude Code o cualquier IDE con asistente, la superficie de ataque ya no es lo que tu equipo escribió: es lo que la IA decidió importar. Tres movimientos concretos:
- Pega un candado a la lista de dependencias permitidas. Configura allow-lists de paquetes en tu registry interno o en tu pipeline de CI/CD, de modo que la IA no pueda importar libremente lo primero que matchea con el prompt. Esto solo no resuelve las dependencias transitivas, pero reduce el ruido más visible.
- Audita lo que ya está corriendo. Haz una pasada con un scanner SBOM sobre tus builds de producción. No te quedes con el bill of materials declarativo: busca dependencias que aparecieron en builds sin quedar en la imagen final, porque ahí es donde Castro dice que vive el malware más esquivo.
- Deja de pensar en "revisar antes del merge" como tu única línea de defensa. Castro lo dice sin rodeos: ese modelo ya no escala con código generado por agentes. Invierte en provenancia verificada y componentes seguros por default —o asume formalmente el riesgo de la larga cola y documenta quién lo aprobó.
Fuentes
- AI coding tools are accelerating dependency sprawl and expanding malware risk with it (fuente original)
- Chainguard Surpasses 1 Billion Container Build Manifests
- Free Docker Hardened Images challenge Chainguard
- Terabytes of credentials leaked in massive supply-chain attack (LiteLLM/Trivy)
- CrowdSec Confirms Source Code Stolen in Supply Chain Attack
- Malicious npm packages evade install-script defenses at runtime
🤖 La IA no es solo para leer sobre ella
En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.
👥 Aplicarla en la comunidad
