Ataque a la cadena de suministro

El software de hoy se arma con piezas hechas por otros: bibliotecas de código abierto que trae un gestor de paquetes, herramientas de compilación, servicios en la nube, servidores de actualizaciones. Un ataque a la cadena de suministro no va directo contra el objetivo final. Compromete una de esas piezas de confianza y deja que el flujo normal de actualizaciones lleve el código malicioso a cada empresa y persona que está más abajo.

Dos casos muestran el patrón. En un ataque descubierto en 2020, unos intrusos habían metido una puerta trasera en actualizaciones de SolarWinds Orion, un producto de monitoreo de redes que miles de organizaciones, incluidas agencias del gobierno de Estados Unidos, instalaron como un trámite más. En 2024 un desarrollador notó que xz, una biblioteca de compresión presente en muchos sistemas Linux, tenía una puerta trasera escondida, puesta por un colaborador que pasó unos dos años ganándose la confianza de los mantenedores. También abundan las versiones más simples: publicar un paquete malicioso con un nombre que difiere en una letra de uno popular, o robarle la contraseña a un mantenedor y subir una versión envenenada.

Es difícil defenderse porque el código llega firmado, desde la fuente esperada y por el canal en el que se supone que tenés que confiar. Las respuestas apuntan a saber y verificar de qué dependés: fijar versiones exactas, llevar un inventario de componentes (un SBOM), chequear firmas y procedencia con marcos como SLSA, proteger las cuentas de los mantenedores con un 2FA fuerte y limitar lo que cada componente puede hacer.