Dependencia oculta

Una dependencia oculta (hidden dependency) es código, un paquete o un archivo que un build descarga y usa, pero que ningún lockfile ni manifiesto enumera. Como la mayoría de las herramientas SBOM parten de esas listas, las dependencias ocultas faltan en la mayoría de las SBOM, y precisamente por ahí entraron varios ataques a la cadena de suministro recientes. En la ingeniería de software general, la expresión también designa un acoplamiento no declarado entre módulos; aquí se usa en el sentido de la cadena de suministro.

Dependencias ocultas habituales

• Hooks de instalación. npm ejecuta los scripts preinstall, install y postinstall de un paquete durante npm install (documentación de npm). Lo que esos scripts descargan nunca aparece en package-lock.json. Es la vía que siguió el gusano Shai-Hulud.
• Scripts de build. Cargo compila y ejecuta el build.rs de un crate justo antes de construirlo (Cargo Book). Algunos scripts de build descargan en ese momento una biblioteca C o un binario precompilado, y Cargo.lock no lo registra.
• Imágenes base. En un build de contenedor, la imagen base y sus capas de sistema operativo vienen de un registro, no del lockfile de ningún lenguaje. Vea SBOM de imágenes Docker.
• Pasos de CI. Las acciones de configuración y los instaladores curl | sh de un workflow obtienen herramientas directamente de una URL, sin lockfile, sin versión fijada ni hash, salvo que el autor los añada.

El código incluido en el repositorio (dependencias incorporadas) es otra forma de que los componentes escapen a los manifiestos, pero no se descarga durante el build. «Phantom dependency» significa otra cosa: en JavaScript, un paquete que su código usa sin declararlo, disponible solo gracias al hoisting.

Por qué las herramientas SBOM las omiten

Las herramientas basadas en el lockfile leen la lista declarada en el lockfile, así que solo ven lo declarado. Los escáneres de salida examinan el artefacto terminado y deducen qué entró, lo que en código compilado como Rust es pura conjetura. Ninguno de los dos ve lo que el build obtuvo por el camino. La lista completa de lo que omite cada enfoque, incluidos cachés y herramientas de build, está en generadores de SBOM de código abierto. Una dependencia oculta es una laguna en la completitud de la SBOM que la propia SBOM no puede revelar.

Fijar versiones tampoco lo resuelve: un lockfile puede ser perfecto y el hook de instalación que fija puede descargar algo nuevo igualmente. Los builds que descargan cosas durante el build son además una de las razones por las que un build reproducible es difícil de conseguir.

Cómo encontrarlas

• Revise el registro del build en busca de descargas: la salida de npm install y cargo build, y las líneas de curl o wget.
• Compare una SBOM generada a partir del lockfile con los paquetes que notifica el paso de instalación.
• Busque en su SBOM un paquete que sepa que está en su imagen base, como libc6. Si no aparece, faltan las capas de la imagen.
• Busque curl y wget en sus workflows.

La respuesta fiable es registrar lo que el build recibe realmente por la red, en lugar de reconstruirlo después.

CRACI

CRACI ve el tráfico que entra en cada build, así que registra las dependencias ocultas que omiten las herramientas basadas en el lockfile. Cuando no ha podido verlo todo, por ejemplo porque un job permitió tráfico que esquiva su proxy consciente de paquetes, el estado de completitud del job lo indica. Su política de egress decide además a qué hosts puede llegar un build, de modo que un curl | sh a un host que la política no permite falla. Vea SBOM en tiempo de build.