Ataque a la cadena de suministro de software (Software supply chain attack)
En términos de amenaza, un ataque a la cadena de suministro de software compromete algo en lo que la organización ya confía y que ya instala, en vez de atacarla a ella directamente. El código malicioso llega firmado, por el mecanismo de actualización, y alcanza de golpe a todos los clientes del componente comprometido.
Cómo funciona
Bajo la misma etiqueta hay varias rutas distintas. Se compromete una dependencia de un repositorio público de paquetes, porque se toma la cuenta de quien la mantiene o porque a esa persona se la coacciona o se la sustituye, y una versión nueva entrega código hostil a todo el que actualice. Se compromete el sistema de compilación, con lo que el código fuente sigue limpio y el artefacto no, que es el caso más difícil de detectar porque revisar el código no demuestra nada. Se compromete la infraestructura de actualización de un fabricante y las actualizaciones firmadas llevan la carga dentro. O el camino es un proveedor con una ruta de red de confianza hacia sus clientes.
Lo que tienen en común es que la decisión de confiar se tomó de antemano y se tomó bien: este es un componente del que dependemos, firmado por quien esperábamos.
Qué sale mal
Los controles de endpoint no están mirando. Un componente firmado de un fabricante conocido, instalado por el proceso de actualización, comportándose dentro de su contexto de ejecución normal, es exactamente el perfil que un producto de seguridad está ajustado para ignorar, y apretar ese ajuste genera un ruido inasumible. La detección tiene que venir, por tanto, del comportamiento posterior a la instalación: el componente que abre conexiones de red que nunca abrió, lee datos que no tienen nada que ver con su función, o lanza procesos que no tiene ningún motivo para lanzar.
El segundo problema es que casi ninguna organización sabe contestar a la primera pregunta que se hace durante uno de estos episodios, que es si contiene el componente afectado y en qué versión. Sin un SBOM generado en cada compilación, contestar lleva días, y la respuesta llega después del momento en el que había que decidir. Las dependencias transitivas lo empeoran: el paquete afectado casi nunca es uno que eligiera nadie.
Tercero, el resultado duradero suele ser un backdoor dentro de algo que se va a reinstalar desde la misma fuente durante la recuperación, así que la erradicación tiene que incluir la cadena de compilación y no solo las máquinas.
Dónde aparece esto en una auditoría
En una diligencia debida esto es una pregunta estructural y no un escaneo. Quién puede publicar en el repositorio de artefactos, si las compilaciones son reproducibles, si los artefactos van firmados y con su procedencia, si la resolución de dependencias está fijada o suelta, y si hay un inventario por entrega. Una empresa analizada que no pueda enseñar los controles de su cadena arrastra un riesgo que no sacarán a la luz las pruebas de aplicación, por muchas que se hagan. Los hallazgos se emparejan con la salida del software composition analysis, que contesta qué hay dentro, mientras que esto contesta quién podría cambiarlo. Esto forma parte de cómo evaluamos el riesgo de terceros y de la cadena de compilación en una diligencia debida.