Ataques a la cadena de suministro: cuando la amenaza viene de software de confianza

Qué hace diferentes a los ataques a la cadena de suministro

En un ataque tradicional, el adversario apunta directamente a tu organización: explota tus vulnerabilidades, hace phishing a tus empleados o fuerza tus credenciales por fuerza bruta. Un ataque a la cadena de suministro toma una ruta más indirecta: el atacante compromete software, hardware o servicios en los que confías e instalas tú mismo. Cuando ese componente de confianza te llega, la carga maliciosa viaja con él.

Este enfoque es devastadoramente eficaz porque las organizaciones tienen defensas maduras contra los ataques directos, pero a menudo depositan una confianza implícita en sus proveedores de software, repositorios de paquetes y canalizaciones de compilación. El atacante solo necesita comprometer a un proveedor ascendente para alcanzar a miles de objetivos descendentes.

Casos de gran repercusión

SolarWinds Orion (2020)

APT29 (un grupo patrocinado por el Estado ruso) comprometió el sistema de compilación de SolarWinds, una plataforma de monitorización de TI ampliamente utilizada. Insertaron una puerta trasera —denominada SUNBURST— en la actualización legítima del software SolarWinds Orion. Aproximadamente 18 000 organizaciones instalaron la actualización troyanizada, incluidos el Departamento del Tesoro de EE. UU., el Departamento de Seguridad Nacional y grandes contratistas de defensa. La puerta trasera permaneció inactiva durante dos semanas tras la instalación antes de activarse, eludiendo la detección basada en el comportamiento.

La lección: incluso las actualizaciones de software firmadas y suministradas por el proveedor no son fiables de forma incondicional.

Puerta trasera en XZ Utils (2024)

Un actor de amenazas dedicó casi dos años a ganarse pacientemente la confianza en el proyecto de código abierto XZ Utils bajo una identidad falsa, asumiendo poco a poco el mantenimiento. A continuación, insertó una sofisticada puerta trasera dirigida a los demonios SSH vinculados a systemd en sistemas Linux. La puerta trasera fue detectada por un ingeniero de Microsoft que notó un uso inusual de CPU durante los inicios de sesión por SSH, apenas unos días antes de que la versión comprometida llegara a los principales repositorios de distribución.

Este caso demostró la sofisticación de la ingeniería social a largo plazo dirigida a los mantenedores de código abierto.

Envenenamiento de paquetes de npm

El ecosistema de JavaScript ha sufrido incidentes repetidos en la cadena de suministro:

• event-stream (2018): un nuevo mantenedor añadió una carga de criptominería dirigida a una cartera de Bitcoin específica
• node-ipc (2022): el mantenedor insertó deliberadamente código destructivo dirigido a direcciones IP rusas y bielorrusas
• Typosquatting: paquetes con nombres como lodahs, crossenv o momnet para captar comandos npm install mal escritos

Solo el registro de npm alberga más de dos millones de paquetes, y los árboles de dependencias suelen tener cientos de paquetes de profundidad, la mayoría de los cuales tu equipo nunca ha revisado.

Vectores de ataque en la cadena de suministro de software

Los ataques a la cadena de suministro entran por múltiples canales:

• Sistemas de compilación comprometidos: inyección de código malicioso durante la compilación (como en SolarWinds)
• Confusión de dependencias: subida de un paquete público malicioso con el mismo nombre que un paquete interno privado, aprovechando el orden de resolución del gestor de paquetes
• Typosquatting: registro de paquetes con nombres similares a bibliotecas populares
• Robo de cuentas: secuestro de la cuenta del mantenedor de un paquete para publicar una actualización maliciosa
• Compromiso de la canalización CI/CD: inyección de pasos maliciosos en canalizaciones de compilación que tienen amplio acceso a los sistemas de producción
• Hardware comprometido: implantes añadidos durante la fabricación (una preocupación para el firmware y los equipos de red)

Defensas: gestión de dependencias

Fija las versiones de las dependencias: no uses rangos de versiones flotantes (^1.2.3 o latest). Los archivos de bloqueo (package-lock.json, Cargo.lock, requirements.txt con hashes) garantizan que instalas exactamente lo que probaste. Verifica la integridad mediante sumas de comprobación:

# npm — verificar frente al archivo de bloqueo
npm ci

# pip — exigir verificación de hash
pip install --require-hashes -r requirements.txt

Audita las dependencias con regularidad: npm audit, pip-audit, cargo audit, trivy para contenedores. Suscríbete a los avisos de seguridad de tus dependencias clave a través de Dependabot de GitHub u OSV.dev.

Minimiza tu árbol de dependencias. Antes de añadir un paquete, pregúntate: ¿esta dependencia se mantiene activamente? ¿Qué tan extendido es su uso? ¿Podrías implementarlo tú mismo en 20 líneas?

Defensas: seguridad de la canalización de compilación

• Usa compilaciones reproducibles: el mismo código fuente debería producir siempre una salida idéntica bit a bit, lo que hace detectables las modificaciones no autorizadas
• Firma tus artefactos de publicación y verifica las firmas antes del despliegue: usa Sigstore/cosign para contenedores y binarios
• Aplica el mínimo privilegio en CI/CD: los trabajos de compilación solo deben tener acceso a lo que necesitan; los secretos deben limitarse a canalizaciones y entornos específicos
• Habilita SLSA (Supply Chain Levels for Software Artifacts): un marco que proporciona procedencia verificable para los artefactos de compilación
• Revisa los flujos de trabajo de GitHub Actions y las acciones de terceros: fija las acciones a SHA de commits específicos, no a nombres de ramas o etiquetas mutables

Defensas: riesgo de proveedores y código abierto

• Mantén un Software Bill of Materials (SBOM): un inventario completo de todos los componentes de software y sus versiones. Herramientas como Syft y CycloneDX pueden generar SBOM automáticamente.
• Antes de adoptar una biblioteca de código abierto crítica, revisa la actividad de su mantenedor, su modelo de gobernanza y si ha tenido incidentes de seguridad anteriores
• Para las dependencias críticas, considera el vendoring (copiar el código fuente en tu propio repositorio) para evitar que los cambios ascendentes te afecten automáticamente
• Implementa controles de salida de red en tu entorno de compilación para impedir que los paquetes maliciosos extraigan secretos durante el tiempo de compilación