Google startet OSS Rebuild zur Stärkung der Sicherheit in Open-Source-Paket-Ökosystemen

Google hat mit OSS Rebuild ein neues Projekt ins Leben gerufen, das die Sicherheit in den Paket-Ökosystemen von Open-Source-Software deutlich verbessern soll. Ziel ist es, das Vertrauen in zentrale Plattformen wie PyPI (Python), npm (JavaScript/TypeScript) und Crates.io (Rust) zu stärken – insbesondere angesichts der wachsenden Bedrohung durch Supply-Chain-Angriffe.

Transparente Herkunft, automatisiert reproduziert

Kernstück des Projekts ist die unabhängige Reproduktion sogenannter Upstream-Artefakte – also der Pakete, wie sie ursprünglich von den Maintainern erstellt wurden. Mittels automatisierter Prozesse leitet OSS Rebuild deklarative Build-Definitionen ab und erstellt damit sogenannte SLSA-Provenance-Dokumente (Supply-chain Levels for Software Artifacts). Diese erfüllen die Anforderungen von SLSA Build Level 3 – und das ganz ohne Zutun der Paketverwalter.

Weniger Aufwand für Maintainer, mehr Kontrolle für Sicherheitsteams

OSS Rebuild richtet sich insbesondere an Sicherheitsteams, die so Einblick in die Herkunft von Softwarepaketen erhalten, ohne auf Änderungen oder Mitwirkung der ursprünglichen Entwickler angewiesen zu sein. Das Projekt umfasst:

• Eine Automatisierung zur Erstellung reproduzierbarer Builds für Tausende Pakete in den genannten Ökosystemen.

• Tools zur Überwachung und Verifikation von Build-Prozessen, die sich in bestehende Sicherheits- und Schwachstellen-Management-Workflows integrieren lassen.

• Infrastrukturdefinitionen, mit denen Unternehmen eigene Instanzen von OSS Rebuild betreiben können – inklusive Erzeugung, Signierung und Verteilung von Herkunftsnachweisen.

Mit OSS Rebuild setzt Google einen neuen Standard im Kampf gegen die wachsenden Risiken in der Open-Source-Lieferkette – und bietet eine skalierbare Lösung für mehr Transparenz und Sicherheit in der Softwareentwicklung.

Herausforderungen

Open-Source-Software ist zur Grundlage unserer digitalen Welt geworden. Von kritischen Infrastrukturen bis hin zu alltäglichen Anwendungen machen OSS-Komponenten mittlerweile 77 % moderner Anwendungen aus. Mit einem geschätzten Wert von über 12 Billionen US-Dollar ist Open-Source-Software für die Weltwirtschaft so wichtig wie nie zuvor.

Doch gerade diese Allgegenwärtigkeit macht Open Source zu einem attraktiven Ziel: Jüngste, viel beachtete Angriffe auf die Lieferkette haben gezeigt, mit welch raffinierten Methoden weit verbreitete Pakete kompromittiert werden können. Jeder Vorfall untergräbt das Vertrauen in offene Ökosysteme und führt zu Unsicherheit sowohl bei den Mitwirkenden als auch bei den Nutzern.

Die Sicherheitscommunity hat mit Initiativen wie Security Scorecard, pypi’s Trusted Publishers und npm’s native SLSA-Unterstützung reagiert. Es gibt jedoch kein Patentrezept: Jede Maßnahme zielt auf einen bestimmten Aspekt des Problems ab und geht oft mit Kompromissen einher, wie beispielsweise der Verlagerung von Aufgaben auf Publisher und Maintainer.

Das Ziel

Mit OSS Rebuild möchten wir die Sicherheitscommunity in die Lage versetzen, ihre Lieferketten besser zu verstehen und zu kontrollieren, indem wir die Nutzung von Paketen so transparent machen wie die Verwendung eines Quell-Repositorys. Unsere Rebuild-Plattform ermöglicht diese Transparenz durch einen deklarativen Build-Prozess, Build-Instrumentierung und Netzwerküberwachungsfunktionen, die innerhalb des SLSA Build-Frameworks detaillierte, dauerhafte und vertrauenswürdige Sicherheitsmetadaten generieren – Google.

Aufbauend auf dem von uns mit OSS Fuzz für die Erkennung von Speicherproblemen entwickelten gehosteten Infrastrukturmodell, versucht OSS Rebuild in ähnlicher Weise, gehostete Ressourcen zu nutzen, um Sicherheitsherausforderungen in Open Source zu bewältigen, diesmal mit dem Ziel, die Software-Lieferkette zu sichern. Google

Unsere Vision geht über ein einzelnes Ökosystem hinaus: Wir setzen uns dafür ein, Transparenz und Sicherheit in der Lieferkette für die gesamte Open-Source-Softwareentwicklung zu gewährleisten. Unsere anfängliche Unterstützung für die Paketregister PyPI (Python), npm (JS/TS) und Crates.io (Rust), die für viele ihrer beliebtesten Pakete eine Rebuild-Herkunftsangabe bereitstellen, ist nur der Anfang unserer Reise. Google

So funktioniert OSS Rebuild

Google setzt bei der Reproduktion von Softwarepaketen auf Automatisierung und heuristische Verfahren. Dabei wird zunächst eine potenzielle Build-Definition für ein Zielpaket ermittelt und neu erstellt. Das Ergebnis wird anschließend semantisch mit dem bestehenden Upstream-Artefakt verglichen. Um Instabilitäten zu beseitigen, die etwa durch Archivkomprimierung entstehen und Bit-für-Bit-Vergleiche erschweren, werden beide Versionen normalisiert.

Ist ein Paket erfolgreich reproduziert, veröffentlicht Google die entsprechende Build-Definition samt Ergebnis über SLSA Provenance. Diese Bescheinigung ermöglicht es Nutzern, die Herkunft eines Pakets anhand der Quellhistorie zuverlässig nachzuvollziehen, den Build-Prozess nachzuvollziehen und bei Bedarf auf Basis einer stabilen Ausgangslage anzupassen oder zu reproduzieren – etwa zur Erstellung detaillierterer Software-Stücklisten (SBOMs).

Für Plattformen wie PyPI, npm und Crates.io ist dieser Prozess bereits weitgehend automatisiert. Die meisten Pakete erhalten dadurch ohne Zutun von Nutzern Schutz. Wo eine vollständige Reproduktion per Automatisierung nicht möglich ist, stellt Google manuelle Build-Spezifikationen bereit, um auch hier der Community eine reproduzierbare Basis zu bieten.

Zudem sieht Google großes Potenzial in der Nutzung von KI für die Paket-Reproduktion. Viele Build- und Release-Prozesse sind lediglich in natürlichsprachlicher Dokumentation festgehalten, was sie für herkömmliche logische Systeme schwer zugänglich macht – für Sprachmodelle jedoch zunehmend verwertbar. Erste Tests zeigen, dass sich selbst komplexe Builds mit minimalem menschlichem Eingreifen auf diese Weise automatisiert erkunden und testen lassen.

Funktionen

OSS Rebuild hilft bei der Erkennung verschiedener Arten von Sicherheitsverletzungen in der Lieferkette:

• Nicht übermittelter Quellcode – Wenn veröffentlichte Pakete Code enthalten, der nicht im öffentlichen Quellcode-Repository vorhanden ist, bestätigt OSS Rebuild das Artefakt nicht.
  • Angriff in der Praxis: solana/webjs (2024)
• Kompromittierung der Build-Umgebung – Durch die Erstellung standardisierter, minimaler Build-Umgebungen mit umfassender Überwachung kann OSS Rebuild verdächtige Build-Aktivitäten erkennen oder die Gefährdung durch kompromittierte Komponenten gänzlich vermeiden.
  • Angriff aus der Praxis: tj-actions/changed-files (2025)
• Versteckte Hintertüren – Selbst ausgeklügelte Hintertüren wie xz zeigen während des Builds oft anomale Verhaltensmuster. Die dynamischen Analysefunktionen von OSS Rebuild können ungewöhnliche Ausführungspfade oder verdächtige Vorgänge erkennen, die durch manuelle Überprüfung nur schwer zu identifizieren sind.
  • Angriff aus der Praxis: xz-utils (2024)

Für Unternehmen und Sicherheitsexperten bietet OSS Rebuild folgende Vorteile:

• Metadaten ohne Änderung der Registrierungen verbessern, indem Daten für Upstream-Pakete angereichert werden. Es ist nicht erforderlich, benutzerdefinierte Registrierungen zu verwalten oder auf ein neues Paket-Ökosystem umzustellen.
• SBOMs erweitern, indem detaillierte Informationen zur Build-Beobachtbarkeit zu bestehenden Software-Stücklisten hinzugefügt werden, wodurch ein vollständigeres Sicherheitsbild entsteht.
• Beschleunigen Sie die Reaktion auf Schwachstellen, indem Sie mithilfe unserer überprüfbaren Build-Definitionen einen Pfad zu Anbietern, Patches und Re-Hosting-Upstream-Paketen bereitstellen.

Für Herausgeber und Betreuer von Open-Source-Paketen bietet OSS Rebuild folgende Vorteile:

• Stärkung des Vertrauens in Pakete durch unabhängige Überprüfung der Build-Integrität der Pakete für Verbraucher, unabhängig von der Komplexität des ursprünglichen Builds.
• Nachrüstung der Integrität historischer Pakete mit hochwertigen Build-Bescheinigungen, unabhängig davon, ob Build-Bescheinigungen zum Zeitpunkt der Veröffentlichung vorhanden waren oder unterstützt wurden.
• Reduzierung der CI-Sicherheitsempfindlichkeit, sodass sich Herausgeber auf ihre Kernentwicklungsarbeit konzentrieren können. CI-Plattformen verfügen in der Regel über komplexe Autorisierungs- und Ausführungsmodelle. Durch separate Neubauten muss die CI-Umgebung nicht mehr für die Sicherheit Ihrer Pakete verantwortlich sein.

Probieren Sie es aus!

Der einfachste (aber nicht einzige!) Weg, um auf OSS Rebuild-Bescheinigungen zuzugreifen, ist die Verwendung der bereitgestellten Go-basierten Befehlszeilenschnittstelle. Diese lässt sich einfach kompilieren und installieren:

$ go install github.com/google/oss-rebuild/cmd/oss-rebuild@latest

Sie können die SLSA-Herkunft von OSS Rebuild abrufen:

$ oss-rebuild get cratesio syn 2.0.39…

oder die neu kompilierten Versionen eines bestimmten Pakets erkunden:

$ oss-rebuild list pypi absl-py…

oder sogar das Paket selbst neu kompilieren:

$ oss-rebuild get npm lodash 4.17.20 –output=dockerfile | \

docker run $(docker buildx build –

Qeulle: Google Security Blog 

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky