Das Supply chain Levels for Software Artifacts (SLSA) ist ein Sicherheitsrahmenwerk, das dabei hilft, Vertrauen zu schaffen, dass eine Reihe von Eingaben wie Quellcode, Bibliotheken und Softwarepakete zu einer Reihe von klar definierten Ausgaben wie einem Binärprodukt und einem Software Bill of Materials führen. Es ist ein strukturierter Satz technischer Anforderungen, der einem Produzenten hilft, den Teilen der Lieferkette zu vertrauen, die unter seiner direkten Kontrolle stehen, und bietet Vertrauen in den Build-Prozess, um etwaige Angriffe auf die vorgelagerte Lieferkette zu erkennen.
Adoptium hat die sicheren Entwicklungspraktiken unseres Projekts bewertet, um den angemessenen SLSA-Attestierungsgrad zu bestimmen. Details zu den SLSA-Level-Anforderungen und deren Erfüllung durch Adoptium sind nachfolgend aufgeführt. Beachten Sie, dass SLSA sich noch im „Alpha"-Status befindet und die Anforderungen sich ändern können, insbesondere für SLSA Level 3 und 4.
SLSA Level Eins
Die folgenden Anforderungen für Adoptiums Build von Eclipse Temurin wurden erfüllt und genügen den notwendigen Anforderungen für SLSA Level 1.
Dieses Level bedeutet, dass der Build-Prozess von Adoptium vollständig skriptbasiert und automatisiert ist und formal strukturierte Software Bill of Material (SBOM)-Attestierungen veröffentlicht, die die Komponenten, Bibliotheken und Module auflisten, die für den Build jedes Binärprodukts erforderlich sind.
- Build - Scripted build
-
Alle Schritte zur Erstellung von Eclipse Temurin sind durch versionskontrollierte Jenkins-Pipelines definiert, die Build-Skripte aufrufen, die im adoptium/temurin-build-Repository gespeichert sind. Die Pipelines und Build-Skripte sind für jeden einsehbar und verifizierbar, und die Läufe des Jenkins-Systems stehen zur Überprüfung offen. Die Dokumentation zur Verwendung der Build-Skripte ist in der Readme-Datei des Build-Repositorys verfügbar.
- Provenance - Available
-
Adoptium stellt SBOM-Attestierungen für die Herkunft von Eclipse Temurin-Builds bereit. Die SBOM ist im OWASP CycloneDX-Format und neben jedem unserer Temurin-Release-Artefakte verfügbar.
Die SBOM enthält die Informationen, die zur Wiederherstellung des Builds erforderlich sind, einschließlich der vom Build-Prozess verwendeten Quell-Repository-Tags, des vollständigen Satzes der verwendeten Parameter, der Ausgabe der Konfigurationsschritte und verschiedener anderer Informationen. Wir entwickeln kontinuierlich die in der SBOM enthaltenen spezifischen Details weiter.
SLSA Level Zwei
Die folgenden zusätzlichen Anforderungen für Adoptiums Build von Eclipse Temurin wurden erfüllt und genügen den notwendigen Anforderungen für SLSA Level 2.
Dieses Level fügt zusätzliche Anforderungen hinzu, um eine gewisse Manipulationsresistenz des Build-Prozesses zu gewährleisten, hauptsächlich in den Bereichen der Versionskontrolle des gesamten Codes und der Nutzung eines Build-Dienstes zur Erstellung und Verteilung von Builds.
- Source - Version controlled
-
Adoptium spiegelt den OpenJDK Java SE-Referenzimplementierungs-Quellcode in unser lokales Github-Repository (z. B. adoptium/jdk17u). Jede Änderung am von uns gebauten Quellcode und den verwendeten Skripten wird vom Versionskontrollsystem von Github verfolgt. Dies gewährleistet einen Verlaufsdatensatz der Änderungen, die in jede Revision eingeflossen sind. Jede Änderung enthält die Identitäten des Uploaders und der Reviewer, Zeitstempel der Überprüfungen und Einreichungen, die Änderungsbeschreibung/-begründung, den Inhalt der Änderung und die übergeordneten Revisionen. Alle Committer und Reviewer durchlaufen eine starke Authentifizierung, und alle Mitwirkenden müssen die Eclipse Contributor Agreement ausführen und einhalten.
Jede unveränderliche Revision des unter unserer Kontrolle stehenden Codes hat eine eindeutige Referenz mit unbegrenzter Lebensdauer über Github (Repository-URL + Branch/Tag/Ref + Commit-ID). Eclipse Temurin wird aus getaggten Revisionen unseres Spiegels gebaut, und wir stellen Quellarchivdateien für jeden Release zur Verfügung.
- Build - Build service
-
Alle Build-Schritte von Adoptium laufen auf unserem eigenen verwalteten Jenkins-Build-Dienst und dem Code-Signing-Dienst der Eclipse Foundation. Diese Dienste führen die Builds durch, generieren die SBOMs und erstellen ggf. die Installer. Die Ausgaben der Builds werden vom Jenkins-CI-System in GitHub-Release-Repositories hochgeladen. Kein Teil des Prozesses läuft auf der Workstation eines Entwicklers.
Der Zugang zu Build-Diensten wird vom Projekt sorgfältig verwaltet. Das Build-System ist so offen wie möglich, um die Überprüfung durch die Community zu ermöglichen, ohne die Sicherheit zu gefährden.
- Provenance - Authenticated
-
TODO: The provenance’s authenticity and integrity can be verified by the consumer. This SHOULD be through a digital signature from a private key accessible only to the service generating the provenance.
- Provenance - Service generated
-
Alle Provenance-Daten von Adoptium werden direkt durch die kontinuierlichen Build- und Testsysteme des Projekts generiert. Dienstbenutzer können den Inhalt der Provenance nicht einschleusen oder ändern. Die GNU Privacy Guard (GPG)-Codesignaturen von Eclipse Temurin werden vom Eclipse Code-Signing-Dienst generiert, andere Provenance-Daten einschließlich des Software Bill of Materials, kryptografischer Hashes, Build-Metadaten usw. werden direkt vom Projekt-Build-System ausgegeben.
SLSA Level Drei - In Bearbeitung
Einige der folgenden zusätzlichen Anforderungen für Adoptiums Build von Eclipse Temurin wurden erfüllt. Die Arbeit an den verbleibenden Punkten wird fortgesetzt, während wir SLSA Level 3 anstreben.
- Source - Retained 18mo
-
Alle Revisionen des Quellcodes und seiner Änderungshistorie werden auf unbestimmte Zeit aufbewahrt und können nicht gelöscht werden, es sei denn, dies unterliegt einer etablierten und transparenten Richtlinie zur Vernichtung, wie einer gesetzlichen oder Eclipse Foundation-Richtlinienanforderung. Diese Ebene der Superuser-Kontrolle für das Ändern oder Löschen von Historien wird direkt und ausschließlich von der Eclipse Foundation im Auftrag des Projekts verwaltet.
Da wir unseren gesamten Code in GitHub speichern, ist es für Personen nicht möglich, die Geschichte zu löschen oder zu ändern, selbst nicht mit Mehrparteienfreigabe, außer durch vertrauenswürdige Eclipse Foundation-Plattformadministratoren mit Zweiparteienfreigabe gemäß der Vernichtungsrichtlinie der Stiftung. Fragen zu dieser Richtlinie sollten an die Eclipse Foundation gerichtet werden.
- Build - Build as code
-
Die Build-Definition und -Konfiguration von Adoptium, die vom Build-Dienst ausgeführt wird, ist nachweislich aus Textdateidefinitionen abgeleitet, die in unserem Versionskontrollsystem gespeichert sind.
- Build - Ephemeral environment
-
Ephemere Umgebungs-Builds wie ein Container oder eine VM, die ausschließlich für diesen Build bereitgestellt und nicht von einem vorherigen Build wiederverwendet werden, sind für Linux x86-, ARM32- und aarch64-Builds vorhanden. Andere Plattformen befinden sich noch in Arbeit im Projekt.
- Build - Isolated
-
Der Adoptium-Build-Dienst stellt sicher, dass jeder Build-Schritt in einer isolierten Umgebung ohne Einfluss von anderen Build-Instanzen läuft, ob vorhergehend oder gleichzeitig.
Es ist nicht möglich, dass ein Build auf Geheimnisse des Build-Dienstes zugreift, wie den Provenance-Signierungsschlüssel, da diese außerhalb des Build-Systems gespeichert und durch einen Remote-Aufruf an ein separates System zugänglich sind. Es ist nicht möglich, dass zwei Builds, die zeitlich überlappen, sich gegenseitig beeinflussen. Jeder Build-Schritt läuft in einer isolierten Maschinenumgebung, die vom Jenkins-CI-System orchestriert wird, und Schritte jedes Builds werden durch die Verwendung verwalteter Pipelines zusammengefügt. Build-Caches werden, wo eingesetzt, rein inhaltlich adressiert, um Manipulationen zu verhindern.
Wir arbeiten weiterhin daran sicherzustellen, dass es nicht möglich ist, dass ein Build die Build-Umgebung eines nachfolgenden Builds persistiert oder beeinflusst. Jeder Teil der Umgebung ist in den Build-Skripten spezifiziert. Dies wird durch das Ausführen von Builds auf ephemeren Maschinen überall und die Überprüfung, dass die Ergebnisse identisch sind, sichergestellt.
- Provenance - Non-falsifiable
-
Die SBOM-Provenance-Informationen können nicht von Dienstbenutzern gefälscht werden, da sie maschinell durch den Build-Prozess generiert und kryptografisch vom Eclipse Foundation Code-Signing-Dienst signiert werden, um Manipulationen zu verhindern. Der Code-Signing-Dienst ist für reguläre Projekt-Committer oder Jenkins-Benutzer nicht zugänglich.
SLSA Level Vier - In Bearbeitung
Adoptium arbeitet an den Anforderungen für SLSA Level 4. Diese werden über unser Issue-Tracking-System verfolgt, und Beiträge zu diesen Aufgaben sind willkommen.
