SLSA steht für Supply-chain Levels for Software Artifacts. Es ist ein Rahmenwerk, das beschreibt, wie nachvollziehbar und manipulationssicher der Weg vom Quellcode zum fertigen Artefakt ist. Vier Stufen, von 0 bis 3, mit steigenden Anforderungen. Die Frage für einen Mittelständler ist nicht, ob SLSA gut klingt, sondern welche Stufe den eigenen Aufwand rechtfertigt.
Was die Stufen bedeuten
Level 0 ist der Ausgangszustand: kein Nachweis, wie ein Build entstanden ist. Wer von Hand baut oder auf dem Laptop kompiliert und hochlädt, ist hier. Level 1 verlangt, dass der Build automatisiert läuft und eine Herkunftsangabe erzeugt, eine sogenannte Provenance. Die sagt, welche Quelle und welcher Prozess das Artefakt produziert haben. Level 2 setzt voraus, dass dieser Build auf einem gehosteten Dienst läuft und die Provenance signiert wird, sodass sie sich nicht unbemerkt fälschen lässt. Level 3 fügt eine gehärtete Build-Umgebung hinzu, die gegen Manipulation während des Builds geschützt ist.
Der Sprung von 0 auf 1 ist klein, wenn schon eine CI-Pipeline existiert. Der Sprung von 2 auf 3 ist deutlich teurer, weil er Anforderungen an die Isolation der Build-Worker stellt, die viele Standard-Setups nicht erfüllen.
Welche Stufe für wen
Für die meisten Mittelständler ist Level 1 die richtige erste Stufe und realistisch in wenigen Tagen erreichbar, wenn die Software ohnehin über GitHub Actions oder GitLab CI gebaut wird. Eine automatisch erzeugte Provenance bei jedem Build ist die Grundlage für alles Weitere und kostet kaum laufenden Aufwand.
Level 2 lohnt sich, sobald Kunden oder Prüfer nach einem Nachweis fragen, dass ein ausgeliefertes Artefakt wirklich aus der angegebenen Quelle stammt. Die signierte Provenance ist genau dieser Nachweis. Wer Software an regulierte Branchen verkauft oder in Ausschreibungen mit Sicherheitsanforderungen steht, sollte hier landen.
Level 3 ist für die wenigsten Mittelständler nötig. Es richtet sich an Anbieter, deren Artefakte ein attraktives Ziel für gezielte Angriffe sind, etwa weit verbreitete Bibliotheken oder Infrastruktur-Software. Der Aufwand für gehärtete Build-Umgebungen rechnet sich nur, wenn ein kompromittierter Build echten Flurschaden anrichten würde.
Der häufigste Fehler
Viele Teams behandeln SLSA als Alles-oder-nichts. Sie schauen sich Level 3 an, halten es für unrealistisch und tun gar nichts. Das ist der falsche Schluss. Level 1 bringt den größten relativen Nutzen, weil es überhaupt erst Sichtbarkeit schafft. Ohne Provenance weiß niemand, welcher Commit in welchem Artefakt steckt. Mit Provenance ist diese Frage in Sekunden beantwortet, auch nach einem Vorfall.
Der zweite Fehler ist, die Provenance zu erzeugen und dann nicht zu prüfen. Eine Herkunftsangabe, die niemand verifiziert, ist Dokumentation ohne Wirkung. Der Wert entsteht erst, wenn beim Deployment geprüft wird, dass das Artefakt die erwartete Herkunft hat.
Wie man pragmatisch anfängt
Beginnen Sie mit einer ehrlichen Einordnung: Auf welcher Stufe steht Ihre Pipeline heute? Wenn Builds automatisiert laufen, fehlt für Level 1 oft nur die Provenance-Erzeugung, die sich in bestehende Workflows einbauen lässt. Danach klären Sie, ob ein Kunde oder eine Prüfung Level 2 erfordert, und ziehen die Signatur nach. Level 3 stellen Sie erst zur Diskussion, wenn ein konkretes Risiko es verlangt.
Diese Reihenfolge spart Geld, weil sie Aufwand an tatsächlichen Bedarf koppelt statt an ein abstraktes Reifegradmodell.
Unklar, auf welcher SLSA-Stufe Ihre Pipeline steht und welche realistisch ist? Der GitSecOps QuickCheck prüft Ihre Build- und Lieferkette in 3 Werktagen und liefert eine konkrete Einordnung samt nächsten Schritten. 1.990 € netto. Kontakt: mm@crank.zone.






Hinterlasse einen Kommentar