Ataques a la cadena de suministro de software: el nuevo riesgo para las empresas

 

La seguridad informática está entrando en una nueva etapa. Los ciberdelincuentes ya no necesitan atacar directamente una aplicación utilizada por una empresa para conseguir acceso a sus sistemas.

Cada vez con mayor frecuencia, el objetivo se encuentra antes de que el software llegue al usuario final: repositorios de código, cuentas de desarrolladores, paquetes de código abierto, pipelines de CI/CD, herramientas de automatización y sistemas utilizados para construir y distribuir aplicaciones.

Durante 2025 y la primera mitad de 2026, Google Threat Intelligence identificó un crecimiento significativo de las campañas de compromiso de la cadena de suministro de software, especialmente contra repositorios y componentes de código abierto. Entre los ecosistemas afectados se encuentran npm, PyPI y Docker Hub.

Para las empresas, esto convierte la seguridad de la cadena de suministro de software en una prioridad relacionada directamente con la protección de credenciales, infraestructura cloud, aplicaciones empresariales y datos corporativos.

¿Qué es un ataque a la cadena de suministro de software?

Un ataque a la cadena de suministro ocurre cuando un atacante compromete un componente, proveedor, repositorio o proceso utilizado para desarrollar o distribuir software.

En lugar de atacar directamente a miles de empresas, el atacante puede buscar un punto común.

Por ejemplo:

Atacante → cuenta de desarrollador → repositorio → paquete malicioso → aplicaciones de los clientes

El atractivo para los ciberdelincuentes es evidente.

Si un paquete de código abierto es utilizado por miles de proyectos, comprometerlo puede proporcionar acceso indirecto a una cantidad considerable de organizaciones.

Google Threat Intelligence señala que los compromisos de software de código abierto ofrecen a los atacantes eficiencia y escala, aunque suelen ser descubiertos y divulgados más rápidamente una vez que comienzan a propagarse.

¿Por qué los atacantes están apuntando a CI/CD?

Las canalizaciones CI/CD (Continuous Integration y Continuous Delivery/Deployment) automatizan buena parte del proceso mediante el cual el código pasa desde el repositorio hasta una versión que puede ser distribuida.

Esto las convierte en objetivos especialmente interesantes.

Un pipeline puede tener acceso a:

• Tokens de autenticación.
• Credenciales cloud.
• Repositorios privados.
• Registros de paquetes.
• Claves API.
• Certificados.
• Sistemas de publicación.
• Infraestructura de producción.

Si un atacante compromete el pipeline, puede intentar utilizar esas credenciales para avanzar hacia otros sistemas.

El problema no es únicamente que pueda modificar código. También puede conseguir los permisos necesarios para publicar una versión maliciosa que posteriormente llegue a los usuarios.

GitHub Actions se ha convertido en una pieza crítica de seguridad

GitHub Actions permite automatizar tareas de desarrollo, pruebas y publicación.

Su integración con repositorios y credenciales hace que una configuración incorrecta pueda tener consecuencias importantes.

En julio de 2026, Chainguard documentó un ataque contra el ecosistema de AsyncAPI en el que un atacante aprovechó una configuración vulnerable de pull_request_target para obtener un token privilegiado de GitHub utilizado por el proceso de CI.

Posteriormente se publicaron cinco versiones maliciosas correspondientes a cuatro paquetes de npm.

El incidente demuestra por qué la seguridad de GitHub Actions debe tratarse como parte de la seguridad de la cadena de suministro, no simplemente como una cuestión de configuración del equipo de desarrollo.

El problema de las credenciales de CI/CD

Una de las principales razones por las que los pipelines son atractivos para los atacantes es la cantidad de credenciales que pueden manejar.

Un entorno de desarrollo automatizado puede contener acceso a:

• GitHub.
• npm.
• PyPI.
• Amazon Web Services.
• Microsoft Azure.
• Google Cloud.
• Bases de datos.
• Registros de contenedores.
• Sistemas internos.
• Herramientas de inteligencia artificial.

Cuando una credencial de alto privilegio queda expuesta, el incidente puede extenderse mucho más allá del proyecto originalmente comprometido.

Por eso, las estrategias modernas de DevSecOps están incorporando controles de mínimo privilegio, autenticación multifactor, credenciales temporales y mecanismos de publicación confiables.

npm se ha convertido en un objetivo importante

El ecosistema npm tiene una enorme importancia dentro del desarrollo moderno de aplicaciones JavaScript y Node.js.

Miles de proyectos dependen de paquetes publicados en este registro.

Eso crea un efecto multiplicador.

Un atacante que consiga modificar un paquete popular puede intentar aprovechar las actualizaciones automáticas para introducir código malicioso en proyectos que dependen de él.

Google Threat Intelligence documentó en marzo de 2026 un compromiso relacionado con axios, uno de los paquetes más utilizados del ecosistema npm.

Las versiones maliciosas fueron retiradas aproximadamente tres horas después de su publicación, pero Google estimó que el alcance potencial era amplio debido a que el paquete superaba los 100 millones de descargas semanales y era dependencia de decenas de miles de paquetes.

Este ejemplo muestra por qué una vulnerabilidad o compromiso aparentemente limitado puede tener consecuencias mucho mayores.

Los paquetes de código abierto son un objetivo estratégico

El código abierto permite acelerar el desarrollo y reducir costes.

Una empresa puede incorporar en minutos una biblioteca que habría requerido semanas o meses para desarrollar internamente.

Pero esa eficiencia también introduce dependencia.

Cuando una organización utiliza cientos o miles de componentes externos, necesita conocer:

• Qué paquetes utiliza.
• Qué versiones están instaladas.
• De dónde proceden.
• Quién los mantiene.
• Qué permisos tienen.
• Qué vulnerabilidades presentan.
• Qué dependencias secundarias incorporan.

Esta visibilidad es una de las razones por las que herramientas de Software Composition Analysis (SCA) y los Software Bills of Materials (SBOM) están adquiriendo mayor relevancia.

El riesgo de los ataques que se propagan automáticamente

Los ataques modernos pueden incorporar mecanismos para propagarse desde un proyecto comprometido hacia otros repositorios o paquetes.

Google Threat Intelligence documentó durante 2026 campañas asociadas con el actor identificado como UNC6780, también conocido como TeamPCP, que afectaron a ecosistemas como npm, PyPI y Docker Hub.

En algunos incidentes se utilizaron credenciales robadas para ampliar el alcance de la campaña.

La automatización cambia la escala del problema.

Un atacante ya no necesita comprometer manualmente cada proyecto. Si consigue suficientes credenciales y permisos, determinadas partes de la propagación pueden automatizarse.

El caso de AsyncAPI: cómo una configuración puede convertirse en una brecha

El incidente documentado por Chainguard en julio de 2026 es un buen ejemplo de la cadena de acontecimientos.

El atacante aprovechó una configuración de GitHub Actions para obtener un token privilegiado.

Después utilizó ese acceso para activar el proceso legítimo de publicación y distribuir versiones comprometidas de varios paquetes.

Según Chainguard, las versiones maliciosas incluían un troyano capaz de buscar información como contraseñas de navegador, claves SSH, tokens de npm y GitHub, credenciales cloud y datos relacionados con criptomonedas.

La lección es importante: un pipeline legítimo puede convertirse en el mecanismo de distribución de software malicioso si sus controles de seguridad son comprometidos.

Los ataques ya no se limitan al software tradicional

Otro cambio importante es la relación entre la cadena de suministro y las herramientas de inteligencia artificial.

Google Threat Intelligence ha documentado actividad que combina amenazas contra software de código abierto con entornos de IA y asistentes de programación.

Entre los comportamientos observados se encuentran paquetes maliciosos, herramientas dirigidas a asistentes de programación y técnicas destinadas a manipular entornos de desarrollo basados en IA.

Esto abre una nueva superficie de ataque.

Los agentes de IA pueden tener acceso a:

• Código fuente.
• Terminales.
• Repositorios.
• Archivos de configuración.
• Variables de entorno.
• Herramientas de desarrollo.
• Sistemas de control de versiones.

Por ello, la AI security y la seguridad de la cadena de suministro de software comienzan a converger.

La inteligencia artificial también está cambiando el panorama de amenazas

El problema no consiste solamente en proteger los sistemas de IA.

La inteligencia artificial también puede ser utilizada por actores maliciosos para automatizar determinadas actividades.

En septiembre de 2026, CrowdStrike investigó una campaña en la que malware distribuido mediante paquetes npm de código abierto habría sido desarrollado con asistencia de IA. La investigación fue reportada por Axios y describió el caso como otro ejemplo de cómo la IA puede reducir determinadas barreras técnicas para los atacantes.

Esto no significa que la IA sea responsable por sí misma de los ataques.

El riesgo surge cuando las capacidades de automatización se combinan con credenciales comprometidas, software de código abierto y sistemas que ejecutan código automáticamente.

¿Cómo pueden protegerse las empresas?

La protección de la cadena de suministro requiere varias capas de seguridad.

1. Implementar mínimo privilegio

Las cuentas de desarrolladores, runners y pipelines deberían disponer únicamente de los permisos necesarios.

Una credencial de CI/CD no debería tener acceso ilimitado a toda la infraestructura corporativa.

2. Reducir las credenciales permanentes

GitHub recomienda mecanismos de publicación confiables para reducir la dependencia de credenciales de larga duración dentro de los pipelines.

El objetivo es limitar el valor de una credencial incluso si termina siendo comprometida.

3. Aislar los runners

Los entornos utilizados para ejecutar CI/CD deberían estar aislados de los sistemas críticos.

Google recomienda el aislamiento de pipelines y entornos de prueba, además del uso de runners efímeros y restricciones de tráfico de salida.

4. Analizar las dependencias

Las empresas deberían conocer exactamente qué componentes externos utilizan sus aplicaciones.

Las herramientas SCA pueden ayudar a identificar vulnerabilidades conocidas y dependencias problemáticas.

5. Utilizar SBOM

Un Software Bill of Materials permite mantener un inventario de los componentes que forman parte de una aplicación.

Cuando aparece una vulnerabilidad en una biblioteca determinada, disponer de un SBOM facilita identificar qué sistemas pueden estar afectados.

6. Aplicar períodos de espera para nuevas versiones

Una versión recién publicada puede ser legítima, pero también podría haber sido comprometida.

GitHub incorporó en 2026 un período de espera predeterminado para determinadas actualizaciones de Dependabot, con el objetivo de dar tiempo a detectar señales de una versión maliciosa antes de incorporarla automáticamente.

7. Proteger las cuentas de los mantenedores

Las cuentas de desarrolladores y mantenedores de paquetes son objetivos especialmente importantes.

La autenticación multifactor, la protección contra phishing y la revisión periódica de permisos pueden reducir el riesgo de apropiación de cuentas.

¿Qué es DevSecOps y por qué es importante?

DevSecOps integra seguridad dentro del ciclo de desarrollo de software.

En lugar de comprobar la seguridad únicamente cuando una aplicación está terminada, los controles se incorporan durante todo el proceso.

Esto puede incluir:

• Análisis de código.
• Análisis de dependencias.
• Escaneo de vulnerabilidades.
• Gestión de secretos.
• Seguridad de contenedores.
• Validación de paquetes.
• Control de identidad.
• Seguridad de CI/CD.
• Pruebas automatizadas.
• Monitorización continua.

La ventaja es que las amenazas pueden detectarse antes de que lleguen a producción.

El mercado de la seguridad de la cadena de suministro

El aumento de estos ataques está impulsando la demanda de soluciones especializadas.

Entre las áreas con mayor interés empresarial se encuentran:

Software Composition Analysis (SCA): análisis de dependencias de terceros.

SBOM: inventario de componentes de software.

DevSecOps: integración de controles de seguridad en el desarrollo.

CI/CD Security: protección de pipelines y runners.

Cloud Security: protección de infraestructura y credenciales en la nube.

Secrets Management: almacenamiento y gestión segura de claves y tokens.

Identity and Access Management: control de identidades y privilegios.

AI Security: protección de modelos, agentes y herramientas de programación basadas en IA.

Para proveedores de tecnología y empresas, estas categorías representan una parte cada vez más importante de la estrategia de seguridad corporativa.

¿Estamos ante una nueva etapa de la ciberseguridad?

Los incidentes registrados durante 2025 y 2026 muestran que la cadena de suministro de software se está convirtiendo en un objetivo estratégico para los atacantes.

Google Threat Intelligence considera que las grandes campañas de compromiso de código abierto observadas durante 2025 y principios de 2026 representan una expansión significativa de esta táctica respecto de años anteriores.

El cambio fundamental es que la superficie de ataque ya no termina en la aplicación.

Ahora también incluye todo aquello que permite crear, probar, empaquetar, publicar y actualizar esa aplicación.

Una empresa puede tener una aplicación perfectamente protegida y aun así quedar expuesta si una dependencia comprometida entra en su proceso de construcción.

Los ataques a la cadena de suministro de software están transformando la manera en que las empresas deben pensar sobre la ciberseguridad.

Los repositorios de código, paquetes de código abierto, cuentas de desarrolladores, pipelines de CI/CD y herramientas de inteligencia artificial forman parte de una misma superficie de ataque.

Los incidentes documentados durante 2026 muestran que comprometer un único componente puede proporcionar a los atacantes una vía para alcanzar numerosos proyectos y organizaciones.

La respuesta no consiste en abandonar el software de código abierto ni la automatización.

La estrategia pasa por reducir privilegios, proteger identidades, aislar pipelines, controlar dependencias, utilizar SBOM, analizar código y establecer mecanismos de verificación antes de distribuir software.

En un mercado donde las aplicaciones dependen cada vez más de cientos de componentes externos, la seguridad de la cadena de suministro se ha convertido en una parte fundamental de la seguridad empresarial.

Google Threat Intelligence — Mitigation Guidance for Supply Chain Compromise