Dépendance cachée

Une dépendance cachée (hidden dependency) est du code, un paquet ou un fichier qu'un build télécharge et utilise, mais qu'aucun lockfile ni manifeste ne liste. Comme la plupart des outils SBOM partent de ces listes, les dépendances cachées manquent dans la plupart des SBOM, et c'est précisément par là que sont passées plusieurs attaques de la chaîne d'approvisionnement récentes. En génie logiciel général, l'expression désigne aussi un couplage non déclaré entre modules ; ici, elle a le sens de la chaîne d'approvisionnement.

Dépendances cachées courantes

• Hooks d'installation. npm exécute les scripts preinstall, install et postinstall d'un paquet pendant npm install (documentation npm). Ce que ces scripts téléchargent n'apparaît jamais dans package-lock.json. C'est la voie qu'a empruntée le ver Shai-Hulud.
• Scripts de build. Cargo compile et exécute le build.rs d'une crate juste avant de la construire (Cargo Book). Certains scripts de build téléchargent à ce moment une bibliothèque C ou un binaire précompilé, et Cargo.lock ne l'enregistre pas.
• Images de base. Dans un build de conteneur, l'image de base et ses couches de système d'exploitation viennent d'un registre, et non d'un lockfile de langage. Voir SBOM d'images Docker.
• Étapes de CI. Les actions de configuration et les installeurs curl | sh d'un workflow récupèrent des outils directement depuis une URL, sans lockfile, sans version épinglée ni hash, sauf si l'auteur en ajoute.

Le code commité dans le dépôt (dépendances vendorisées) est une autre façon pour des composants d'échapper aux manifestes, mais il n'est pas récupéré pendant le build. « Phantom dependency » désigne encore autre chose : en JavaScript, un paquet que votre code utilise sans le déclarer, disponible uniquement grâce au hoisting.

Pourquoi les outils SBOM les ratent

Les outils fondés sur le lockfile lisent la liste déclarée dans le lockfile et ne voient donc que ce qui est déclaré. Les scanners de sortie examinent l'artefact terminé et en déduisent ce qui y est entré, ce qui reste de la devinette pour du code compilé comme Rust. Aucun des deux ne voit ce que le build a récupéré en chemin. La liste complète de ce que chaque approche rate, caches et outils de build compris, figure dans générateurs de SBOM open source. Une dépendance cachée est une lacune de complétude de la SBOM que la SBOM elle-même ne peut pas révéler.

L'épinglage ne règle pas non plus le problème : un lockfile peut être parfait et le hook d'installation qu'il épingle peut quand même télécharger quelque chose de nouveau. Les builds qui récupèrent du contenu au moment du build sont aussi l'une des raisons pour lesquelles un build reproductible est difficile à obtenir.

Comment les trouver

• Lisez le journal du build à la recherche de téléchargements : la sortie de npm install et cargo build, et les lignes de curl ou wget.
• Comparez une SBOM générée à partir du lockfile avec les paquets que l'étape d'installation signale.
• Cherchez dans votre SBOM un paquet dont vous savez qu'il est dans votre image de base, comme libc6. S'il n'y est pas, les couches de l'image manquent.
• Cherchez curl et wget dans vos workflows.

La réponse fiable consiste à enregistrer ce que le build reçoit réellement par le réseau, plutôt qu'à le reconstituer après coup.

CRACI

CRACI voit le trafic qui entre dans chaque build, il enregistre donc les dépendances cachées que les outils fondés sur le lockfile ratent. Lorsqu'il n'a pas pu tout voir, par exemple parce qu'un job a autorisé du trafic qui contourne son proxy sensible aux paquets, l'état de complétude du job le signale. Sa politique d'egress décide aussi quels hôtes un build peut joindre, si bien qu'un curl | sh vers un hôte que la politique n'autorise pas échoue. Voir SBOM au moment du build.