Skjult afhængighed

En skjult afhængighed (hidden dependency) er kode, en pakke eller en fil, som et build downloader og bruger, men som ingen lockfile eller manifest angiver. Fordi de fleste SBOM-værktøjer arbejder ud fra de lister, mangler skjulte afhængigheder i de fleste SBOM'er, og det var netop der, flere nyere supply chain-angreb foregik. I almindelig softwareudvikling betyder udtrykket også en ikke-deklareret kobling mellem moduler; her menes betydningen i forsyningskæden.

Almindelige skjulte afhængigheder

• Install-hooks. npm kører en pakkes scripts preinstall, install og postinstall under npm install (npm-dokumentationen). Det, som de scripts downloader, optræder aldrig i package-lock.json. Det var den vej, ormen Shai-Hulud tog.
• Build-scripts. Cargo kompilerer og kører en crates build.rs lige før cratet bygges (Cargo Book). Nogle build-scripts downloader på det tidspunkt et C-bibliotek eller en færdigbygget binær, og Cargo.lock registrerer det ikke.
• Base images. I et container-build kommer base imaget og dets operativsystemlag fra et register, ikke fra noget sprogs lockfile. Se SBOM'er for Docker-images.
• CI-trin. Setup-actions og curl | sh-installere i et workflow henter værktøjer direkte fra en URL uden lockfile, versionsfastlåsning eller hash, medmindre forfatteren tilføjer det.

Kode, der er committet til repositoriet (vendorede afhængigheder), er en anden måde, komponenter undslipper manifester på, men den hentes ikke under buildet. "Phantom dependency" betyder noget helt tredje: i JavaScript en pakke, som din kode bruger uden at deklarere den, og som kun er tilgængelig via hoisting.

Hvorfor SBOM-værktøjer overser dem

Lockfile-baserede værktøjer læser den deklarerede liste i lockfilen og ser derfor kun det, der er deklareret. Output-scannere ser på den færdige artefakt og udleder, hvad der gik ind, hvilket bliver gætteri for kompileret kode som Rust. Ingen af dem ser, hvad buildet hentede undervejs. Den fulde liste over, hvad hver tilgang overser, inklusive caches og build-værktøjer, står under open source SBOM-generatorer. En skjult afhængighed er et hul i SBOM-fuldstændigheden, som SBOM'en ikke selv kan afsløre.

Fastlåsning løser det heller ikke: en lockfile kan være perfekt, og den install-hook, den låser, kan stadig downloade noget nyt. Builds, der henter ting under buildet, er også en grund til, at et reproducerbart build er svært at opnå.

Sådan finder du dem

• Læs buildloggen for downloads: output fra npm install og cargo build og linjer fra curl eller wget.
• Sammenlign en SBOM genereret fra lockfilen med de pakker, installationstrinnet rapporterer.
• Søg i din SBOM efter en pakke, du ved findes i dit base image, for eksempel libc6. Er den der ikke, mangler imagets lag.
• Søg efter curl og wget i dine workflows.

Det pålidelige svar er at registrere, hvad buildet faktisk tager ind over netværket, i stedet for at rekonstruere det bagefter.

CRACI

CRACI ser trafikken, der kommer ind i hvert build, så det registrerer de skjulte afhængigheder, som lockfile-baserede værktøjer overser. Når det ikke kunne se alt, for eksempel fordi et job tillod trafik, der går uden om dets pakkebevidste proxy, siger jobbets fuldstændighedsstatus det. Dets egress-politik afgør desuden, hvilke værter et build overhovedet kan nå, så et curl | sh til en vært, politikken ikke tillader, mislykkes. Se build-time SBOM'er.