Was ist SLSA?

Welches Problem löst SLSA?

Sie können jede Zeile Quellcode prüfen und trotzdem etwas anderes ausliefern, denn was Nutzer ausführen, ist das Ergebnis eines Builds. Ist der Build kompromittiert, wie bei SolarWinds, entsteht aus sauberem Quellcode ein vergiftetes Release. SLSA konzentriert sich auf diese Lücke: Lässt sich überprüfen, dass dieses Artefakt aus dieser Quelle und durch diesen Prozess entstanden ist?

SLSA-Level

SLSA gliedert seine Anforderungen in Tracks. Die aktuelle Version 1.2 hat einen Build-Track und einen Source-Track. Der Build-Track hat vier Level.

Level	Name	Was es verlangt	Was es Ihnen bringt
Build L0	Keine Garantien	Nichts	L0 ist das Fehlen von SLSA
Build L1	Provenienz vorhanden	Ein einheitlicher Build-Prozess und Provenienz, die von der Build-Plattform erzeugt und an Nutzer weitergegeben wird	Hilft, Fehler zu vermeiden, lässt sich aber leicht umgehen oder fälschen
Build L2	Gehostete Build-Plattform	Builds laufen auf einer gehosteten Plattform, die die Provenienz erzeugt und signiert, und Nutzer überprüfen sie	Das Fälschen der Provenienz erfordert jetzt einen gezielten Angriff
Build L3	Gehärtete Builds	Läufe sind voneinander isoliert, und das Signier-Secret liegt außerhalb der Reichweite benutzerdefinierter Build-Schritte	Das Fälschen der Provenienz erfordert das Ausnutzen einer Schwachstelle, was die meisten Angreifer überfordert

Level sind keine Note, die Sie maximieren müssen. Jedes schützt vor bestimmten Bedrohungen, wählen Sie also das Level, das zu Ihrem Risiko passt. Open-Source-Maintainer mit einem gehosteten CI-Dienst erreichen L2 oft ohne großen Aufwand.

Was ist Provenienz?

Provenienz ist eine Aufzeichnung darüber, wie ein Artefakt entstanden ist. In SLSA gibt sie an, welche Plattform es gebaut hat, aus welcher Quelle, durch welchen Prozess und mit welchen Top-Level-Eingaben. Ab L2 ist die Provenienz signiert, sodass Nutzer prüfen können, dass sie von der Build-Plattform stammt und nicht verändert wurde.

Stellen Sie sich eine SBOM als die Zutaten vor und die Provenienz als die Angabe, wo und wie das Gericht gekocht wurde. Beide beantworten unterschiedliche Fragen und ergänzen sich gut: Eine SBOM listet, was enthalten ist, die Provenienz sagt, woher das Artefakt stammt.

So führen Sie SLSA ein

1. Im CI bauen, jedes Mal auf dieselbe Weise. Hören Sie auf, von Laptops zu veröffentlichen. Das ist der größte Teil der Arbeit, um L1 zu erreichen.
2. Provenienz erzeugen. Auf GitHub erzeugen Artifact Attestations signierte Provenienz. Siehe wie Attestations mit SBOMs in GitHub Actions funktionieren.
3. Dort überprüfen, wo es zählt. Signierte Provenienz, die niemand prüft, schützt niemanden. Ergänzen Sie die Überprüfung in Ihrem Deployment-Schritt oder Admission Controller.
4. Den Build härten. Isolieren Sie Läufe und halten Sie Signierschlüssel von Build-Schritten fern. Siehe Runner-Sicherheit im Vergleich.
5. Ihre Abhängigkeiten einbeziehen. Bevorzugen Sie Pakete, die Provenienz veröffentlichen, was Registries wie npm inzwischen unterstützen.

Was SLSA nicht abdeckt

• Schwachstellen. Ein perfekt gebautes Artefakt kann einen Fehler enthalten. SLSA sagt nichts darüber, ob der Code sicher ist.
• Bösartiger Quellcode. Committet ein Angreifer ins Repository, zeichnet die Provenienz getreu einen Build dieses Codes auf. Der Source-Track geht einen Teil davon an.
• Was der Build geladen hat. Provenienz listet Top-Level-Eingaben. Nichts im Build-Track verlangt eine vollständige Liste der Abhängigkeiten, und genau dafür gibt es die SBOM.
• Vertrauenswürdige Insider. Die xz-Hintertür kam über einen vertrauenswürdigen Maintainer, und SLSA allein hätte sie nicht gestoppt.

SLSA und andere Frameworks

SLSA geht bei der Build-Integrität in die Tiefe. Das NIST SSDF ist deutlich breiter: Es behandelt sichere Entwicklung als Ganzes, einschließlich einer Praktik zum Schützen und Archivieren von Releases, die SLSA-Provenienz unterstützt. SLSA ist ein Projekt der OpenSSF, und viele Teams nutzen beide zusammen. Das Gesamtbild finden Sie unter Was ist Software-Lieferkettensicherheit.

Wo CRACI ansetzt

CRACI erzeugt keine signierte Provenienz und beansprucht kein SLSA-Level. Wenn Sie eines brauchen, nutzen Sie GitHub Artifact Attestations oder einen ähnlichen Dienst. CRACI ergänzt das, was SLSA auslässt: eine vollständige Aufzeichnung dessen, was jeder GitHub-Actions-Job geladen hat. Jeder Job läuft in einer eigenen isolierten virtuellen Maschine, jedes Paket, das er lädt, landet in einer SBOM, und eine Egress-Richtlinie blockiert Verbindungen, die der Build nicht braucht. Siehe SBOM-Generierung zur Build-Zeit.

SLSA: häufig gestellte Fragen

Wofür steht SLSA?

Supply-chain Levels for Software Artifacts. Es wird wie „Salsa“ ausgesprochen.

Was sind die SLSA-Level?

Der Build-Track hat vier: L0, keine Garantien; L1, Provenienz vorhanden; L2, eine gehostete Build-Plattform, die die Provenienz signiert; und L3, gehärtete Builds mit isolierten Läufen und geschützten Signier-Secrets. Version 1.2 ergänzt außerdem einen Source-Track.

Was ist SLSA-Provenienz?

Eine Aufzeichnung darüber, wie ein Artefakt gebaut wurde: welche Plattform, aus welcher Quelle, durch welchen Prozess und mit welchen Top-Level-Eingaben. Ab Build L2 ist sie signiert, sodass Nutzer sie überprüfen können.

Was ist der Unterschied zwischen SLSA und einer SBOM?

Eine SBOM listet, was in einer Software enthalten ist. SLSA-Provenienz beschreibt, wie und wo sie gebaut wurde. In der Regel wollen Sie beides.

Ist SLSA verpflichtend?

Nein. Es ist ein freiwilliges Framework der OpenSSF-Community. Manche Kunden und Organisationen fragen vielleicht nach einem Level, aber es ist kein Gesetz.

Welches SLSA-Level sollte ich anstreben?

Beginnen Sie mit Build L1, indem Sie im CI bauen und Provenienz erzeugen, und gehen Sie dann zu L2 auf einer gehosteten Plattform über, was viele Teams schnell erreichen. L3 eignet sich für Releases, von denen viele andere abhängen oder die ein hohes Risiko tragen.