Versteckte Abhängigkeit

Eine versteckte Abhängigkeit (hidden dependency) ist Code, ein Paket oder eine Datei, die ein Build herunterlädt und nutzt, die aber in keinem Lockfile oder Manifest steht. Weil die meisten SBOM-Tools mit diesen Listen arbeiten, fehlen versteckte Abhängigkeiten in den meisten SBOMs, und genau dort liefen mehrere jüngere Supply-Chain-Angriffe. In der allgemeinen Softwareentwicklung bezeichnet der Begriff auch eine nicht deklarierte Kopplung zwischen Modulen; hier ist die Supply-Chain-Bedeutung gemeint.

Typische versteckte Abhängigkeiten

• Install-Hooks. npm führt die Skripte preinstall, install und postinstall eines Pakets während npm install aus (npm-Dokumentation). Was diese Skripte herunterladen, erscheint nie in package-lock.json. Das ist der Weg, den der Wurm Shai-Hulud nahm.
• Build-Skripte. Cargo kompiliert und startet das build.rs eines Crates unmittelbar vor dessen Build (Cargo Book). Manche Build-Skripte laden an dieser Stelle eine C-Bibliothek oder ein vorkompiliertes Binary herunter, und Cargo.lock hält das nicht fest.
• Basis-Images. In einem Container-Build kommen das Basis-Image und seine Betriebssystem-Layer aus einer Registry, nicht aus einem Lockfile einer Sprache. Siehe SBOMs für Docker-Images.
• CI-Schritte. Setup-Actions und curl | sh-Installer in einem Workflow holen Tools direkt von einer URL, ohne Lockfile, Versions-Pin oder Hash, sofern der Autor keinen ergänzt.

Ins Repository eingecheckter Code (vendorte Abhängigkeiten) ist ein weiterer Weg, auf dem Komponenten an Manifesten vorbeikommen, er wird aber nicht während des Builds geladen. „Phantom Dependency“ meint wiederum etwas anderes: in JavaScript ein Paket, das Ihr Code nutzt, ohne es zu deklarieren, und das nur durch Hoisting verfügbar ist.

Warum SBOM-Tools sie übersehen

Lockfile-basierte Tools lesen die deklarierte Liste im Lockfile und sehen daher nur, was deklariert ist. Output-Scanner betrachten das fertige Artefakt und leiten ab, was hineingeflossen ist, was bei kompiliertem Code wie Rust Raten bleibt. Keiner von beiden sieht, was der Build unterwegs geladen hat. Die vollständige Liste dessen, was jeder Ansatz übersieht, einschließlich Caches und Build-Tools, steht unter Open-Source-SBOM-Generatoren. Eine versteckte Abhängigkeit ist eine Lücke in der SBOM-Vollständigkeit, die die SBOM selbst nicht erkennen lässt.

Pinning löst das auch nicht: Ein Lockfile kann perfekt sein, und der Install-Hook, den es pinnt, kann trotzdem etwas Neues herunterladen. Builds, die zur Build-Zeit Dinge laden, sind außerdem ein Grund, warum ein reproduzierbarer Build schwer zu erreichen ist.

Wie Sie sie finden

• Lesen Sie das Build-Log auf Downloads: die Ausgabe von npm install und cargo build sowie Zeilen von curl oder wget.
• Vergleichen Sie eine aus dem Lockfile erzeugte SBOM mit den Paketen, die der Installationsschritt meldet.
• Suchen Sie in Ihrer SBOM ein Paket, von dem Sie wissen, dass es in Ihrem Basis-Image steckt, etwa libc6. Fehlt es, fehlen die Image-Layer.
• Durchsuchen Sie Ihre Workflows nach curl und wget.

Die verlässliche Antwort ist, aufzuzeichnen, was der Build tatsächlich über das Netzwerk aufnimmt, statt es hinterher zu rekonstruieren.

CRACI

CRACI sieht den Datenverkehr, der in jeden Build hineinkommt, und zeichnet deshalb die versteckten Abhängigkeiten auf, die Lockfile-basierte Tools übersehen. Wenn es nicht alles sehen konnte, etwa weil ein Job Verkehr zuließ, der seinen paketbewussten Proxy umgeht, sagt das der Vollständigkeitsstatus des Jobs. Seine Egress-Richtlinie legt außerdem fest, welche Hosts ein Build überhaupt erreichen kann, sodass ein curl | sh zu einem Host, den die Richtlinie nicht erlaubt, fehlschlägt. Siehe Build-Time-SBOMs.