Amenazas a la cadena de suministro

Un ataque a la cadena de suministro de software compromete a una organización no vulnerándola directamente, sino corrompiendo algo en lo que confía y que consume: una biblioteca, una herramienta de compilación, una imagen base de contenedor o un servidor de actualizaciones.

Como el software moderno se ensambla a partir de cientos de componentes de terceros, un solo eslabón manipulado se hereda en cada consumidor posterior. El atacante invierte una vez y alcanza a muchas víctimas.

• Inversión de la confianza — el perímetro de seguridad se desplaza fuera de su propio código
• Radio de impacto transitivo — un paquete malicioso llega a miles de compilaciones

Cuando añade una dependencia directa, a menudo incorpora decenas de dependencias transitivas que nunca eligió. Una aplicación típica de Node o Python declara unos pocos paquetes, pero resuelve cientos.

Enumere todo el árbol resuelto, no solo el manifiesto, para ver qué distribuye realmente:

Los atacantes publican paquetes maliciosos con nombres parecidos a los de paquetes populares, esperando que alguien cometa una errata fatal.

• Typosquatting — reqeusts en lugar de requests
• Combosquatting — python-requests imitando el nombre real
• Confusión de dependencias — publicar un paquete público con el mismo nombre que uno privado interno, de modo que un resolvedor mal configurado descargue la versión del atacante

Defiéndase fijando un registro interno de confianza y utilizando paquetes privados con ámbito o espacio de nombres.

Un paquete legítimo y ampliamente confiable puede volverse malicioso si se compromete la cuenta de su mantenedor o si un colaborador malicioso obtiene permisos de publicación.

Incidentes recientes del mundo real muestran que los atacantes obtienen mediante phishing las credenciales de mantenedores y después publican una versión manipulada que exfiltra tokens durante la instalación.

• Exija 2FA en todas las cuentas de publicación
• Prefiera paquetes con tokens de publicación con ámbito y versiones protegidas
• Supervise la aparición inesperada de nuevos mantenedores en dependencias críticas

Muchos ecosistemas ejecutan código durante la instalación, antes de que se ejecute su aplicación. Un npm install puede ejecutar un enlace postinstall que robe variables de entorno o claves SSH.

Desactive los scripts de instalación arbitrarios en CI y audite cualquier paquete que los necesite:

El propio entorno de compilación es un objetivo de gran valor. Si un atacante manipula un compilador, la imagen del ejecutor de CI o un complemento de compilación, todos los artefactos que produzca tendrán una puerta trasera, aunque su código fuente esté limpio.

El ejemplo clásico es un mecanismo de actualización troyanizado que firma malware con una clave legítima de firma de código, de modo que las víctimas lo aceptan como auténtico.

• Trate la infraestructura de compilación como producción y aplique un endurecimiento completo
• Utilice ejecutores de compilación efímeros y reproducibles
• Separe las claves de firma del equipo de compilación

Un archivo de bloqueo fija versiones exactas y hashes del contenido, de modo que una nueva resolución no pueda sustituir silenciosamente un artefacto por otro. Confírmelo siempre en el repositorio y haga que CI lo verifique en lugar de permitir nuevas resoluciones sin restricciones.

El campo de integridad almacena un hash; si el archivo tar descargado no coincide, la instalación falla.

Las versiones con vulnerabilidades conocidas (registradas como CVE) son la debilidad más común de la cadena de suministro. Las herramientas de análisis de composición de software (SCA) comparan sus dependencias resueltas con bases de datos de vulnerabilidades.

Ejecute análisis en CI y haga fallar las compilaciones cuando se detecten problemas críticos:

Los rangos de versiones flotantes (^1.2.0) permiten incorporar automáticamente nuevas versiones, lo cual resulta práctico, pero le expone a un parche malicioso.

• Fije versiones exactas y revise las actualizaciones deliberadamente
• Fije mediante digest las imágenes de contenedor, no mediante etiquetas mutables como latest
• Incorpore las dependencias críticas en su propio repositorio o espejo para que una eliminación en el origen no pueda interrumpir ni comprometer su sistema

Proteger la cadena de suministro es una tarea continua, no un análisis puntual. Necesita saber qué distribuye, de dónde procede y cuándo se vuelve vulnerable.

• Genere una SBOM para cada versión (en la próxima lección)
• Registre la procedencia de la compilación para poder demostrar cómo se produjo un artefacto
• Suscríbase a avisos de seguridad para que una CVE recién divulgada desencadene una nueva evaluación de las compilaciones ya distribuidas

Trace cada etapa en la que entre información no confiable: los equipos de los desarrolladores, el control de código fuente, los registros de dependencias, el sistema de compilación, el almacenamiento de artefactos y el canal de actualización. Cada una es un posible punto de inyección.

Para cada etapa, pregúntese: ¿quién puede escribir aquí, qué le permitiría hacer un compromiso y cómo lo detectaría? Esto produce una lista priorizada de controles en lugar de una lista de comprobación genérica.

Compruebe su comprensión de un tipo común de ataque a la cadena de suministro.

Ha aprendido por qué las dependencias son vectores de ataque y cómo reducir esa exposición.

• La inversión de la confianza significa que su seguridad depende de terceros que no controla
• Amenazas principales: typosquatting, confusión de dependencias, toma de control de mantenedores, scripts de instalación maliciosos y herramientas de compilación comprometidas
• Defensas esenciales: archivos de bloqueo con hashes de integridad, análisis SCA, fijación exacta mediante digest, 2FA para los publicadores y supervisión continua

A continuación, inventariará exactamente el contenido de su software mediante una SBOM.