Verborgen afhankelijkheid

Een verborgen afhankelijkheid (hidden dependency) is code, een pakket of een bestand dat een build downloadt en gebruikt, maar dat in geen enkele lockfile of manifest staat. Omdat de meeste SBOM-tools met die lijsten werken, ontbreken verborgen afhankelijkheden in de meeste SBOM's, en juist daar liepen verschillende recente supplychainaanvallen. In algemene software-engineering betekent de term ook niet-gedeclareerde koppeling tussen modules; hier gaat het om de supplychainbetekenis.

Veelvoorkomende verborgen afhankelijkheden

• Installhooks. npm voert de scripts preinstall, install en postinstall van een pakket uit tijdens npm install (npm-documentatie). Wat die scripts downloaden, verschijnt nooit in package-lock.json. Dat is de route die de worm Shai-Hulud nam.
• Buildscripts. Cargo compileert en draait de build.rs van een crate vlak voordat de crate wordt gebouwd (Cargo Book). Sommige buildscripts downloaden op dat moment een C-bibliotheek of een vooraf gebouwde binary, en Cargo.lock legt dat niet vast.
• Base images. In een containerbuild komen de base image en de lagen van het besturingssysteem uit een registry, niet uit de lockfile van een taal. Zie SBOM's voor Docker-images.
• CI-stappen. Setup-actions en curl | sh-installers in een workflow halen tools rechtstreeks van een URL, zonder lockfile, versiepin of hash, tenzij de auteur er een toevoegt.

Code die in de repository is gecommit (gevendorde afhankelijkheden) is nog een manier waarop componenten buiten manifesten blijven, maar die wordt niet tijdens de build opgehaald. "Phantom dependency" betekent weer iets anders: in JavaScript een pakket dat uw code gebruikt zonder het te declareren, alleen beschikbaar via hoisting.

Waarom SBOM-tools ze missen

Lockfile-gebaseerde tools lezen de gedeclareerde lijst in de lockfile en zien dus alleen wat gedeclareerd is. Outputscanners bekijken het afgeronde artefact en leiden af wat erin is gegaan, wat bij gecompileerde code zoals Rust giswerk blijft. Geen van beide ziet wat de build onderweg heeft opgehaald. De volledige lijst van wat elke aanpak mist, inclusief caches en buildtools, staat bij open-source-SBOM-generators. Een verborgen afhankelijkheid is een gat in de SBOM-volledigheid dat de SBOM zelf niet kan tonen.

Pinnen lost het ook niet op: een lockfile kan perfect zijn en de installhook die ze pint, kan toch iets nieuws downloaden. Builds die tijdens de build dingen ophalen, zijn bovendien een reden waarom een reproduceerbare build moeilijk te bereiken is.

Hoe u ze vindt

• Lees het buildlog op downloads: de uitvoer van npm install en cargo build, en regels van curl of wget.
• Vergelijk een SBOM die uit de lockfile is gegenereerd met de pakketten die de installatiestap meldt.
• Zoek in uw SBOM naar een pakket waarvan u weet dat het in uw base image zit, zoals libc6. Staat het er niet in, dan ontbreken de imagelagen.
• Doorzoek uw workflows op curl en wget.

Het betrouwbare antwoord is vastleggen wat de build werkelijk via het netwerk binnenkrijgt, in plaats van het achteraf te reconstrueren.

CRACI

CRACI ziet het verkeer dat elke build binnenkomt en legt dus de verborgen afhankelijkheden vast die lockfile-gebaseerde tools missen. Als het niet alles kon zien, bijvoorbeeld omdat een job verkeer toestond dat de pakketbewuste proxy omzeilt, zegt de volledigheidsstatus van de job dat. Het egressbeleid bepaalt bovendien welke hosts een build überhaupt kan bereiken, zodat een curl | sh naar een host die het beleid niet toestaat, mislukt. Zie build-time SBOM's.