Der Artikel behandelt umfassend die Herausforderungen und Maßnahmen zur Sicherung von Software-Lieferketten, insbesondere im Kontext von Supply-Chain-Angriffen. Hier sind die wichtigsten Punkte zusammengefasst:
8 min de lectura
El 19 de marzo de 2026, el popular escáner de vulnerabilidades Trivy se convirtió él mismo en un vector de ataque. 75 de las 76 etiquetas de versión en el repositorio de GitHub fueron comprometidas, y un binario manipulado robó claves SSH, credenciales en la nube y secretos de Kubernetes de las cadenas CI/CD. El ataque revela un patrón que en 2026 se ha agravado: los atacantes ya no apuntan a las aplicaciones, sino a las herramientas que deberían protegerlas.
Según el informe del BSI de 2025, los ataques a la cadena de suministro en Alemania se han duplicado. El tiempo medio de detección es de 287 días – casi diez meses en los que código comprometido puede ejecutarse sin ser detectado en entornos de producción. Cualquiera que desarrolle, compre o gestione software debe considerar su cadena de suministro como un frente de ataque. Este artículo muestra, con casos actuales, qué ocurre, qué patrones se repiten y qué medidas concretas funcionan.
En resumen
- Ataque a Trivy, marzo de 2026: 75 etiquetas de versión comprometidas, un infostealer de tres fases extrajo secretos de CI/CD hacia un dominio de typosquatting. Afectado: miles de equipos DevSecOps en todo el mundo (Aqua Security, CrowdStrike, Wiz).
- 156 por ciento más de paquetes maliciosos de código abierto en comparación anual. Desde 2019 se han identificado más de 704.000 paquetes maliciosos (Sonatype 2024).
- El 74 por ciento de todas las bases de código contienen vulnerabilidades de código abierto de alto riesgo (Synopsys OSSRA 2024).
- La SBOM será obligatoria: La Ley de Resiliencia Cibernética de la UE obliga a los fabricantes a proporcionar una lista de componentes de software legible por máquina. Principales obligaciones a partir de diciembre de 2027, obligaciones de notificación desde septiembre de 2026.
- BSI: 119 nuevas vulnerabilidades por día, un aumento del 24 por ciento. El 48 por ciento de los operadores de infraestructuras críticas carecen de sistemas de detección de ataques (Informe del BSI 2025).
El ataque a Trivy: cuando el escáner se convierte en troyano
Trivy es uno de los escáneres de vulnerabilidades de código abierto más utilizados en el ámbito DevSecOps. Analiza imágenes de contenedores, sistemas de archivos y plantillas IaC en busca de vulnerabilidades, y se ejecuta en miles de cadenas CI/CD como una acción de GitHub. Precisamente ahí es donde actuaron los atacantes.
El grupo «TeamPCP» comprometió a finales de febrero de 2026 las credenciales de GitHub Actions del proyecto Trivy. La primera reacción de Aqua Security fue incompleta: la rotación de credenciales no cubrió todos los accesos. El 19 de marzo llegó la segunda ola: 75 de las 76 etiquetas de versión en el repositorio aquasecurity/trivy-action fueron redirigidas mediante force-push a código malicioso. Las siete etiquetas en aquasecurity/setup-trivy también fueron afectadas.
El código infiltrado actuó en tres fases. Primero: extracción de variables de entorno y credenciales del almacenamiento del ejecutor CI/CD. Segundo: cifrado de datos sensibles – claves SSH, credenciales en la nube, tokens de bases de datos, secretos de Kubernetes. Tercero: exfiltración hacia el dominio de typosquatting scan.aquasecurtiy[.]org – un nombre de dominio deliberadamente escrito de forma incorrecta.
La ironía: una herramienta diseñada para encontrar vulnerabilidades se convirtió en una vulnerabilidad. El ataque podría haberse evitado en gran medida mediante el anclaje basado en SHA de las acciones de GitHub. Quien hubiera referenciado un hash de commit específico en lugar de trivy-action@v0.35.0 no habría sido afectado por la manipulación de etiquetas.
El patrón: XZ Utils, 3CX y la estrategia a largo plazo
Los ataques a la cadena de suministro siguen cada vez más un patrón: ganar confianza, comprometer la infraestructura, propagarse ampliamente.
El ejemplo más extremo es la puerta trasera en XZ-Utils de marzo de 2024 (CVE-2024-3094, CVSS 10.0). Un atacante con el seudónimo «Jia Tan» construyó confianza durante tres años con el mantenedor de la biblioteca de compresión ampliamente utilizada. Al final, implantó una puerta trasera que permitía la ejecución remota de código a través de OpenSSH – en un componente que se ejecuta prácticamente en todos los servidores Linux. El ataque fue descubierto por casualidad: el desarrollador de PostgreSQL Andres Freund notó un retraso inusual en los inicios de sesión SSH.
En el ataque a 3CX (marzo de 2023), Mandiant documentó por primera vez una «doble compromisión de la cadena de suministro»: el grupo Lazarus comprometió primero el software de trading X_Trader, infectó a través de él a un empleado de 3CX y luego manipuló los entornos de compilación. La aplicación de escritorio firmada fue distribuida a 600.000 empresas con 12 millones de usuarios.
El patrón común en los tres casos: el vector de ataque no fue la aplicación, sino la infraestructura detrás de ella. Sistemas de compilación, repositorios de código, registros de dependencias. Quien solo protege su propia aplicación pero confía ciegamente en herramientas y dependencias, deja una flanco abierto que se está explotando cada vez más. Gartner pronosticó en 2022 que hasta 2025, el 45 por ciento de las organizaciones sufrirían ataques a su cadena de suministro de software. Una encuesta de BlackBerry en 2024 reveló: ya es el 75 por ciento.
«La gestión del riesgo en la cadena de suministro sigue siendo uno de los mayores problemas para los CISO.»
– Philip Reitinger, CEO de Global Cyber Alliance, de forma aproximada (SecurityWeek Cyber Insights 2024)
Las cifras: por qué el problema crece exponencialmente
El informe Sonatype sobre el estado de la cadena de suministro de software 2024 documenta un aumento del 156 por ciento en paquetes maliciosos de código abierto en comparación con el año anterior. Desde 2019 se han identificado más de 704.000 paquetes maliciosos en registros como npm, PyPI y Maven – más de 512.000 de ellos solo desde noviembre de 2023.
El informe Synopsys OSSRA 2024 añade: el 96 por ciento de las bases de código analizadas contienen componentes de código abierto. El 84 por ciento contienen al menos una vulnerabilidad conocida. El 74 por ciento contienen vulnerabilidades de alto riesgo – un salto del 54 por ciento respecto al año anterior. Y el 91 por ciento utiliza componentes que están desactualizados en diez o más versiones.
A esto se suma un fenómeno nuevo: el «slopsquatting» – los atacantes aprovechan la tendencia de los asistentes de código con IA a «alucinar» nombres de paquetes inexistentes. Registran esos nombres y los llenan con código malicioso. Si un desarrollador adopta la sugerencia de la IA sin verificarla, el malware se instala automáticamente.
El problema del «slopsquatting» es especialmente insidioso porque crece con la difusión de los asistentes de programación con IA. Según ReversingLabs, en 2024 ya 14 de 23 campañas de malware relacionadas con criptomonedas apuntaban a paquetes npm. En septiembre de 2025, 20 paquetes npm fueron comprometidos, que juntos acumulaban más de dos mil millones de descargas semanales. Por tanto, la superficie de ataque no crece linealmente: crece con cada nuevo paquete que instala un desarrollador, con cada nueva dependencia que un sistema de compilación resuelve automáticamente. Y según Sonatype, en el 95 por ciento de los casos en los que los desarrolladores usan un componente vulnerable, ya existe una versión parcheada. El problema no es la disponibilidad de soluciones, sino la falta de atención a las actualizaciones.
Los costes son cuantificables: según el IBM Cost of a Data Breach Report 2024, el coste medio de una violación de datos es de 4,88 millones de dólares – un récord histórico. Las compromisiones de la cadena de suministro estuvieron ligeramente por encima según el análisis de IBM y fueron el segundo vector de ataque más frecuente.
Para las empresas alemanas, la situación se agrava por dos desarrollos paralelos. Primero: la directiva NIS2 convierte la seguridad de la cadena de suministro en una obligación legal para unas 29.500 empresas – incluyendo la responsabilidad personal de los directores ejecutivos en caso de negligencia. Segundo: la escasez de personal especializado en ciberseguridad significa que muchas empresas no tienen suficientes recursos para revisar sistemáticamente sus dependencias. El BSI informa que el 80 por ciento de los operadores de infraestructuras críticas han implementado sistemas de gestión de seguridad de la información, pero presentan deficiencias importantes en la gestión de la continuidad del negocio. Si una dependencia crítica se ve comprometida y no existe un plan de respuesta a incidentes, los 287 días hasta la detección resultan especialmente dolorosos.
Por qué las herramientas de seguridad tradicionales no son suficientes
La mayor parte de la seguridad empresarial se basa en un modelo que no cubre los ataques a la cadena de suministro: protección perimetral, detección en el endpoint, segmentación de red. Estas herramientas detectan malware que viene del exterior, pero no código malicioso introducido a través de canales de confianza.
En el ataque a Trivy, el código malicioso llegó a través de una herramienta que se utilizaba explícitamente como medida de seguridad. Ningún antivirus habría activado la alarma, ningún registro de firewall habría mostrado anomalías. El ataque utilizó la cadena CI/CD normal – los mismos caminos por los que también se distribuye código legítimo. Para los sistemas de detección de intrusiones, todo parecía funcionar con normalidad.
Por eso también fallan los pentests tradicionales ante los riesgos de la cadena de suministro. Un pentest examina la infraestructura propia, no los sistemas de compilación de los proyectos de código abierto que se utilizan como dependencias. Y una auditoría de la base de código propia no encuentra una puerta trasera en una dependencia de nivel superior anidada 50 versiones en profundidad.
Lo que se necesita en cambio es: Shift Left en la cadena de suministro – verificaciones de seguridad no solo al final de la cadena, sino en cada dependencia individual. Esto significa: cada paquete se verifica al incorporarlo al código, no solo al desplegarlo. Cada acción de GitHub se ancla mediante SHA, no mediante etiqueta. Y cada proceso de compilación se firma y verifica criptográficamente – antes de que un solo byte llegue a producción.
El cambio de paradigma es comparable a la introducción de Zero Trust en las redes: no más «todo dentro del perímetro es de confianza», sino «nada es de confianza hasta que se verifique» – y esto incluye las propias herramientas de desarrollo.
Alemania: 119 vulnerabilidades por día y la obligación de la SBOM
El informe del BSI 2025 documenta 119 nuevas vulnerabilidades de seguridad por día en el período analizado – un aumento del 24 por ciento. 461 fugas de datos con instituciones alemanas como víctimas. Y el 48 por ciento de los operadores de infraestructuras críticas carecen de un sistema de detección de ataques.
El Cyber Resilience Act de la UE (en vigor desde el 10 de diciembre de 2024) obliga a todos los fabricantes de productos con elementos digitales a proporcionar una SBOM legible por máquina. Principales obligaciones a partir del 11 de diciembre de 2027, obligaciones de notificación desde el 11 de septiembre de 2026. Sanciones: hasta 15 millones de euros o el 2,5 por ciento del volumen de negocio mundial anual.
El BSI ha definido requisitos concretos para la SBOM con TR-03183-2 (agosto de 2025). Formatos recomendados: SPDX y CycloneDX. Para empresas reguladas por NIS2, la seguridad de la cadena de suministro ya es parte explícita de los requisitos legales.
En Estados Unidos, desde 2021 rige la Orden Ejecutiva 14028: todo proveedor de software que suministre al gobierno federal debe presentar una SBOM. La fecha límite para la implementación fue septiembre de 2023. Europa sigue con el CRA – e incluso da un paso más allá que la regulación estadounidense con las obligaciones de notificación desde septiembre de 2026. Para pymes alemanas que suministran tanto a EE. UU. como a la UE, esto significa: la SBOM no es opcional, es un requisito para acceder al mercado en ambos lados del Atlántico.
La dimensión financiera es considerable: según el IBM Cost of a Data Breach Report 2024, el coste medio de un incidente en la cadena de suministro es de casi 5 millones de dólares. Para una empresa mediana con 500 empleados, esto puede ser una amenaza existencial – especialmente si el tiempo de detección es de casi diez meses y durante ese tiempo se comprometen más sistemas. A esto se suman las consecuencias regulatorias: bajo NIS2, las sanciones por deficiencias en la seguridad de la cadena de suministro pueden alcanzar hasta 10 millones de euros y la responsabilidad personal de los directores. Bajo el CRA, se añaden hasta 15 millones más. Los costes de prevención – herramientas para SBOM, escaneo de dependencias, medio puesto dedicado a seguridad de la cadena de suministro – se sitúan en la cifra baja de cinco dígitos anuales. La relación entre inversión y daño potencial justifica cualquiera de estas medidas.
Qué medidas concretas protegen: seis acciones con evidencia
1. Anclaje de dependencias basado en SHA. En lugar de referenciar acciones de GitHub por etiqueta (@v1), usar el hash de commit específico. Las etiquetas pueden sobrescribirse, los hashes SHA no. Todo el ataque a Trivy habría fracasado.
2. Crear y mantener una SBOM. Quien no sabe qué dependencias contiene su software, no puede reaccionar ante la próxima alerta CVE. Herramientas como Syft generan SBOMs automáticamente a partir de imágenes de contenedores.
3. Implementar SLSA Nivel 2. El marco Supply-chain Levels for Software Artifacts asegura la integridad de la compilación. El Nivel 2 – procedencia de compilación firmada digitalmente – es alcanzable en pocas semanas con cosign y GitHub-OIDC.
4. Escaneo de dependencias en la cadena CI/CD. Verificación automatizada de cada dependencia en cada compilación. Herramientas: Dependabot, Snyk, Grype. Ningún push sin una verificación de seguridad positiva.
5. Firma de código con Sigstore. Gratis, código abierto, permite firmas criptográficas para binarios y paquetes. Las manipulaciones quedan demostradas.
6. Evaluación regular del riesgo del proveedor. No solo verificar el propio software, sino también a los proveedores. Quien utiliza un escáner de vulnerabilidades debe saber si su cadena CI/CD está protegida.
La combinación de estas seis medidas constituye el mínimo necesario para una seguridad robusta en la cadena de suministro. Ninguna medida por sí sola es suficiente. El anclaje SHA sin escaneo de dependencias no detecta vulnerabilidades conocidas. Una SBOM sin evaluación del proveedor muestra las dependencias propias, pero no su estado de seguridad. Y la firma de código sin SLSA solo prueba quién firmó, no si el proceso de compilación fue limpio. La fortaleza está en la combinación: transparencia (SBOM), integridad (SLSA + firma), verificación (escaneo + evaluación) y endurecimiento (anclaje).
El punto decisivo: la seguridad de la cadena de suministro no es un proyecto que se termine una vez. Es un proceso continuo que debe integrarse en cada compilación, cada despliegue y cada decisión de compra. El ataque a Trivy ha demostrado que incluso las herramientas que deberían garantizar la seguridad pueden ser comprometidas. Quien entiende esto, no basa su defensa en la confianza, sino en la verificación.
«Los ataques a la cadena de suministro de software de nuestra infraestructura global de TIC son cada vez más frecuentes, agresivos y graves.»
– CISA, Defending Against Software Supply Chain Attacks, de forma aproximada
La lección de 2024, 2025 y el primer trimestre de 2026 es clara: las cadenas de suministro de software son la nueva principal superficie de ataque. Quien las ignora, confía en un mundo que exige verificación. El caso de Trivy es especialmente instructivo – no porque fuera técnicamente novedoso, sino porque muestra que incluso las herramientas de defensa son vulnerables. La respuesta no es desconfiar del código abierto. Es la verificación sistemática: cada dependencia verificada, cada compilación firmada, cada cambio rastreable. Es un trabajo intenso. Pero la alternativa – 287 días con código comprometido en producción – lo es mucho más.
Preguntas frecuentes
¿Qué fue el ataque a la cadena de suministro de Trivy?
En marzo de 2026, el grupo TeamPCP comprometió el escáner de vulnerabilidades de código abierto Trivy de Aqua Security. 75 de las 76 etiquetas de versión en el repositorio de GitHub fueron redirigidas a código malicioso. El código infiltrado robó secretos de CI/CD como claves SSH, credenciales en la nube y tokens de Kubernetes.
¿Qué es una SBOM y por qué será obligatoria?
Una SBOM (lista de materiales de software) es una lista legible por máquina de todos los componentes de software de un producto. La Ley de Resiliencia Cibernética de la UE la hace obligatoria a partir de diciembre de 2027. Los formatos comunes son CycloneDX y SPDX.
¿Cómo me protejo de los ataques a la cadena de suministro?
Las medidas más importantes son: anclaje de dependencias basado en SHA, escaneo automatizado de dependencias en la cadena CI/CD, crear y mantener una SBOM, firma de código con Sigstore y evaluación regular del riesgo del proveedor.
¿Qué es el anclaje basado en SHA?
En lugar de referenciar una acción de GitHub por etiqueta de versión (por ejemplo, @v1), se utiliza el hash de commit específico. Las etiquetas pueden ser sobrescritas por atacantes, los hashes SHA no.
¿Cuánto tiempo permanecen sin descubrir los ataques a la cadena de suministro?
Según el informe del BSI 2025, el tiempo medio de detección es de 287 días. En la puerta trasera de XZ-Utils, la preparación duró incluso tres años.
¿Qué empresas alemanas están afectadas?
Toda empresa que utilice o gestione software. Especialmente expuestas: empresas bajo regulación NIS2 (unas 29.500 en Alemania) y operadores de infraestructuras críticas.
¿Qué es SLSA?
Supply-chain Levels for Software Artifacts – un modelo escalonado para la integridad de la compilación. El Nivel 2 puede implementarse en pocas semanas con cosign y GitHub-OIDC.
Recomendaciones de lectura de la redacción
Más del MBF Media Network
Fuente de imagen: Pexels / Tima Miroshnichenko (px:5380603)
