Dipendenza nascosta

Una dipendenza nascosta (hidden dependency) è codice, un pacchetto o un file che una build scarica e usa, ma che nessun lockfile o manifest elenca. Poiché la maggior parte degli strumenti SBOM parte da quegli elenchi, le dipendenze nascoste mancano nella maggior parte delle SBOM, ed è proprio da lì che sono passati diversi attacchi alla supply chain recenti. Nell'ingegneria del software in generale l'espressione indica anche un accoppiamento non dichiarato tra moduli; qui si intende il significato legato alla supply chain.

Dipendenze nascoste comuni

• Hook di installazione. npm esegue gli script preinstall, install e postinstall di un pacchetto durante npm install (documentazione npm). Ciò che questi script scaricano non compare mai in package-lock.json. È la strada seguita dal worm Shai-Hulud.
• Script di build. Cargo compila ed esegue il build.rs di un crate subito prima di compilarlo (Cargo Book). Alcuni script di build scaricano in quel momento una libreria C o un binario precompilato, e Cargo.lock non lo registra.
• Immagini base. In una build di container, l'immagine base e i suoi layer di sistema operativo provengono da un registry, non dal lockfile di un linguaggio. Veda SBOM delle immagini Docker.
• Passi di CI. Le action di setup e gli installer curl | sh di un workflow scaricano strumenti direttamente da un URL, senza lockfile, senza versione fissata né hash, a meno che l'autore non li aggiunga.

Il codice inserito nel repository (dipendenze incorporate) è un altro modo in cui i componenti sfuggono ai manifest, ma non viene scaricato durante la build. «Phantom dependency» indica invece altro: in JavaScript, un pacchetto che il Suo codice usa senza dichiararlo, disponibile solo grazie all'hoisting.

Perché gli strumenti SBOM le ignorano

Gli strumenti basati sul lockfile leggono l'elenco dichiarato nel lockfile e vedono quindi solo ciò che è dichiarato. Gli scanner dell'output esaminano l'artefatto finito e deducono che cosa vi è entrato, il che per il codice compilato come Rust resta una congettura. Nessuno dei due vede ciò che la build ha scaricato lungo il percorso. L'elenco completo di ciò che ogni approccio ignora, cache e strumenti di build compresi, si trova in generatori di SBOM open source. Una dipendenza nascosta è una lacuna nella completezza della SBOM che la SBOM stessa non può rivelare.

Fissare le versioni non risolve il problema: un lockfile può essere perfetto e l'hook di installazione che fissa può comunque scaricare qualcosa di nuovo. Le build che scaricano contenuti durante la build sono anche uno dei motivi per cui una build riproducibile è difficile da ottenere.

Come trovarle

• Legga il log della build alla ricerca di download: l'output di npm install e cargo build, e le righe di curl o wget.
• Confronti una SBOM generata dal lockfile con i pacchetti che il passo di installazione riporta.
• Cerchi nella Sua SBOM un pacchetto che sa essere nella Sua immagine base, come libc6. Se non c'è, mancano i layer dell'immagine.
• Cerchi curl e wget nei Suoi workflow.

La risposta affidabile è registrare ciò che la build riceve davvero dalla rete, invece di ricostruirlo a posteriori.

CRACI

CRACI vede il traffico che entra in ogni build, quindi registra le dipendenze nascoste che gli strumenti basati sul lockfile ignorano. Quando non ha potuto vedere tutto, ad esempio perché un job ha consentito traffico che aggira il suo proxy consapevole dei pacchetti, lo stato di completezza del job lo indica. La sua policy di egress decide inoltre quali host una build può raggiungere, per cui un curl | sh verso un host che la policy non consente fallisce. Veda SBOM in fase di build.