Google stellt OSS-Rebuild-Projekt vor

Google startet das Projekt OSS Rebuild, um Open-Source-Pakete zu verifizieren und Angriffe auf die Lieferkette durch reproduzierbare Builds zu bekämpfen.
Eine Übersetzung von 🇬🇧 Linuxiac.com

Erinnern Sie sich an öffentlichkeitswirksame Vorfälle wie das 🇬🇧 xz-utils-Drama im Jahr 2024, das zeigte, wie böswillige Akteure Hintertüren in weit verbreitete Abhängigkeiten einschleusen und damit Millionen von Systemen gefährden können? Jetzt gibt es eine solide Methode, um diese Art von Versuchen zu stoppen, die von einem der weltweiten Tech-Giganten, nämlich Google, unterstützt wird.

Gestern kündigte das Open Source Security Team von Google ein brandneues Projekt an: OSS Rebuild, ein gehosteter Dienst, der beliebte Pakete von PyPI, npm und Crates.io automatisch neu kompiliert und dann für jeden Build eine Provenance der SLSA-Stufe 3 veröffentlicht.

Vereinfacht ausgedrückt wird versucht, die von Entwicklern heruntergeladenen Pakete neu zu erstellen, zu überprüfen, ob die Binärdateien aus dem öffentlichen Quellcode stammen, und Alarm zu schlagen, wenn etwas verdächtig erscheint. So funktioniert die ganze Sache:

• Automatische Build-Rezepte. Heuristiken untersuchen ein Upstream-Paket und spucken eine deklarative Build-Datei aus.
• Hermetischer Rebuild. Der Dienst kompiliert innerhalb einer minimalen, instrumentierten Umgebung neu.
• Semantisches Diffing. Bit-für-Bit-Übereinstimmungen sind nicht erforderlich; stattdessen werden die Archive normalisiert, um echte Diskrepanzen und nicht das Rauschen der Gzip-Zeitstempel zu erkennen.
• Signierte Provenienz. Jeder erfolgreiche Build gibt eine Sigstore-gestützte SLSA-Attestierung aus, die Sicherheitsteams verifizierbare Breadcrumbs liefert, die in SBOM-Generatoren oder Policy Engines eingefügt werden können.

Da jeder Schritt protokolliert und analysiert wird, kann die Plattform drei unangenehme Szenarien aufzeigen, die heute routinemäßig durchgehen:

• Versteckter Code. Wenn ein veröffentlichtes Artefakt Dateien enthält, die auf GitHub fehlen, wird die Bescheinigung einfach nicht ausgestellt - ein sofortiges Warnsignal.
• Vergiftete Builder. Standardisierte Container isolieren den Build von der potentiell kompromittierten CI eines Anbieters.
• Heimliche Hintertüren. Dynamische Trace-Analysen können merkwürdige Syscalls oder Netzwerkeinwahlen aufdecken - Hinweise, die Ermittler bei der letztjährigen xz-utils-Backdoor-Jagd isolierten.

Die Codebasis, die auf GitHub unter der Apache 2.0 Lizenz veröffentlicht wurde, enthält bereits eine Go-basierte CLI. Ein einziges go install setzt die Binärdatei oss-rebuild auf und ermöglicht es Praktikern, die Provenance (Herkunft) für syn v2.0.39 auf Crates.io zu verifizieren, jedens neuen  Rebuild von absl-py aufzulisten oder einen kompletten lodash-Rebuild direkt in Docker zu übertragen.

Abschließend betont Google, dass OSS Rebuild "nur der Anfang" ist. Die Unterstützung für andere Ökosysteme - etwa Maven Central, Go-Module, vielleicht sogar Container-Basis-Images - steht auf der Roadmap. Im Moment stupst das Unternehmen Sicherheitsforscher an, damit sie sich ein Bild machen, Probleme melden und den Attestierungs-Feed in bestehende SBOM-Pipelines einbinden.

Details finden Sie in der offiziellen Ankündigung von Google.

Spendieren Sie Bobby einen ☕ Ko-fi

Ein Service von s3n🧩net