Jahrelang drehte sich die Sicherheitsdebatte um Softwareverteilung um eine einzige Frage: Ist diese Binärdatei signiert? Eine gültige digitale Signatur galt als Vertrauenssiegel, als Beweis dafür, dass ein Artefakt tatsächlich von dem angegebenen Absender stammte und nicht verändert worden war. Diese Annahme war jedoch stets unvollständig, und die Lieferkettenangriffe der letzten Jahre haben genau das offengelegt.
Die unangenehme Wahrheit ist, dass eine Signatur nur den letzten Schritt beweist. Sie bestätigt, dass der Inhaber des Signaturschlüssels das finale Artefakt freigegeben hat. Sie sagt nichts darüber aus, ob der Quellcode, der in dieses Artefakt eingeflossen ist, tatsächlich von den Entwicklern geschrieben wurde, ob die Build-Umgebung kompromittiert wurde oder ob zwischen dem Commit und der kompilierten Ausgabe ein schädlicher Schritt eingeschleust wurde.
Genau diese Lücke soll das SLSA-Framework (Supply-chain Levels for Software Artifacts) schließen. Insbesondere SLSA Level 3 ermöglicht durch Codesignierung die Erstellung einer nachvollziehbaren Herkunftskette vom Quellcode bis zur Binärdatei. Dieser Blogbeitrag erläutert die Anforderungen von SLSA Level 3, die enge Zusammenarbeit mit Codesignierung und wie Unternehmen die für die Sicherheit moderner Software- Lieferketten unerlässliche, nachvollziehbare Herkunft aufbauen können.
Warum genügt eine Unterschrift allein nicht mehr?
Um zu verstehen, warum SLSA wichtig ist, ist es hilfreich, genau zu definieren, was eine Codesignatur beweist und was nicht. Wenn eine Binärdatei signiert wird, stellt die Signatur zwei Dinge sicher: dass das Artefakt von einer Entität mit dem zugehörigen privaten Schlüssel genehmigt wurde und dass das Artefakt seit der Signierung nicht verändert wurde. Beide Garantien sind wertvoll, und die Codesignatur bleibt eine wesentliche Sicherheitsmaßnahme.
Es beweist jedoch nicht, dass der in die Binärdatei kompilierte Quellcode mit dem Quellcode in Ihrem Repository übereinstimmt. Es beweist auch nicht, dass der Build in einer sauberen, sicheren Umgebung ausgeführt wurde. Es beweist nicht, dass kein unautorisierter Build-Schritt zusätzlichen Code eingefügt hat. Und es beweist nicht, dass die Person oder das System, das den Signierungsvorgang ausgelöst hat, zur Freigabe dieses speziellen Artefakts berechtigt war. Eine Signatur ist eine Aussage über das fertige Objekt, nicht über den Weg, auf dem es entstanden ist.
Die verheerendsten Angriffe auf Lieferketten nutzen genau diese Schwachstelle aus. Sie greifen nicht die Signatur selbst an, da dies schwierig und gut abgesichert ist. Stattdessen attackieren sie den Build-Prozess vor der Signaturerstellung, sodass Schadcode durch die legitime Pipeline gelangt und mit einer scheinbar gültigen Signatur wieder auftaucht. Die Signatur ist zwar echt, doch das damit verbundene Vertrauen ist fehlgeleitet, da das zu signierende Objekt bereits vor dem Signierschritt manipuliert war.
Organisationen benötigen – und Softwarenutzer fordern zunehmend – verifizierbare Nachweise über den gesamten Produktionsprozess, nicht nur über die finale Freigabe. Sie müssen Fragen beantworten können wie: Welcher Commit genau hat diese Binärdatei erzeugt? Welche Build-Plattform hat sie kompiliert? Welche Eingaben wurden verwendet? Und lässt sich all dies kryptografisch beweisen, anstatt es nur zu behaupten? Diese verifizierbaren Nachweise werden als Provenienz bezeichnet, und die Generierung manipulationssicherer Provenienz ist der Kernzweck des SLSA-Frameworks.
Was ist SLSA und warum gibt es sie?
SLSA steht für „Supply-chain Levels for Software Artifacts“ und ist ein herstellerneutrales Sicherheitsframework, das ursprünglich 2021 von Google vorgeschlagen und nun als Projekt der Open Source Security Foundation (OpenSSF) weitergeführt wird. Ziel ist es, einen branchenweit anerkannten Standard für die Beschreibung und Verifizierung der Softwareentwicklung bereitzustellen, sodass Hersteller und Anwender die Integrität der Lieferkette anhand einer gemeinsamen Terminologie beurteilen können.
Das Framework basiert auf einem zentralen Konzept: Provenienz. Provenienz sind verifizierbare Metadaten, die dokumentieren, wo, wann und wie ein Softwareartefakt erstellt wurde. Ein vollständiger Provenienzdatensatz identifiziert das Quellcode-Repository und den exakten Commit, die Build-Plattform, die verwendeten Eingaben und Parameter sowie einen kryptografischen Hash des resultierenden Artefakts. Wird diese Provenienz von einem vertrauenswürdigen Build-System generiert und so signiert, dass die Build-Schritte selbst sie nicht manipulieren können, dient sie als fälschungssicherer Beweis für die Entstehung des Artefakts.
Es ist wichtig, klar zu verstehen, was SLSA ist und was nicht. SLSA ist kein Tool, Scanner oder Produkt, das installiert wird. Es ist eine Spezifikation, die definiert, wie „Sicherheit“ auf verschiedenen Reifegraden aussieht, und ist so konzipiert, dass sie automatisch durch Richtlinien-Engines durchgesetzt werden kann. SLSA ergänzt andere Sicherheitspraktiken, anstatt sie zu ersetzen. Schwachstellenscans identifizieren bekannte Schwachstellen in Code und Abhängigkeiten, während SLSA überprüft, ob der Build selbst manipuliert wurde. Beide Ansätze bekämpfen unterschiedliche Bedrohungen und entfalten ihre volle Wirkung in Kombination.
Das Framework hat sich deutlich weiterentwickelt. SLSA v1.0 wurde im April 2023 veröffentlicht und konzentrierte sich in der Spezifikation auf den Build Track mit den Stufen 0 bis 3. SLSA v1.1 wurde im April 2025 offiziell verabschiedet und präzisierte die Anforderungen, indem mehrere frühere Empfehlungen in strengere normative Anforderungen umgewandelt wurden. SLSA v1.2, das den Source Track zur Sicherstellung der Integrität des Quellcodes selbst einführte, folgte im November 2025. Das Framework reift kontinuierlich, doch der Build Track bleibt die stabile und weit verbreitete Grundlage und stellt den direktesten Bezug zur Codesignierung dar.
Der SLSA Build Track definiert vier aufeinander aufbauende Stufen, nummeriert von 0 bis 3. Jede Stufe baut auf der darunterliegenden auf, d. h. um Stufe 3 zu erreichen, müssen auch die Anforderungen der Stufen 1 und 2 erfüllt sein. Diese kumulative Struktur ist bewusst gewählt, da sie es Unternehmen ermöglicht, SLSA schrittweise einzuführen, anstatt ihre Build-Pipelines auf einmal komplett umzugestalten.
| Niveau | Kernanforderung | Hauptbedrohung beseitigt |
|---|---|---|
| Level 0 | Keine Herkunftsnachweise | Kein Schutz; keine überprüfbaren Beweise dafür, wie die Artefakte hergestellt wurden. |
| Level 1 | Es gibt eine Provenienz, die beschreibt, wie das Artefakt hergestellt wurde. | Versehentliche Verbreitung falscher Versionen; grundlegende Rückverfolgbarkeit |
| Level 2 | Die Herkunftsangabe wird von einer gehosteten Build-Plattform signiert und generiert. | Verhindert, dass der Bauherr die Herkunft verfälscht. |
| Level 3 | Gehärtete, isolierte Build-Plattform mit Signaturgeheimnissen, die für die Build-Schritte unzugänglich sind. | Verhindert gefälschte Herkunftsnachweise selbst bei kompromittierten Zugangsdaten oder Bedrohungen durch Insider. |
Was genau ist für SLSA Level 3 erforderlich?
SLSA Level 3 stellt zwei anspruchsvolle Anforderungen, die weit über die einfache Unterzeichnung eines Herkunftsnachweises hinausgehen. Deren genaues Verständnis ist der Schlüssel zum Verständnis, wie Level 3 eine lückenlose Nachweiskette aufbaut.
Die erste Voraussetzung ist die Build-Isolation . Die Build-Schritte müssen in einer isolierten Umgebung ausgeführt werden, die nicht von anderen Build-Prozessen beeinflusst werden kann. Diese Umgebung darf nicht zwischen Builds wiederverwendet werden. In der Praxis bedeutet dies kurzlebige, abgeschottete Umgebungen wie neu erstellte Container oder virtuelle Maschinen, die speziell für einen einzelnen Build bereitgestellt und anschließend gelöscht werden. Diese Isolation verhindert, dass ein Build-Lauf einen anderen beeinträchtigt, selbst innerhalb desselben Projekts. Dadurch wird eine ganze Reihe von Angriffen verhindert, bei denen ein kompromittierter Build nachfolgende Builds verunreinigt.
Die zweite und wichtigste Anforderung ist die Unfälschbarkeit der Herkunftsnachweise . Es muss für die Benutzer der Build-Plattform, einschließlich derjenigen, die die Build-Schritte definieren, unmöglich sein, Herkunftsinformationen zu verfälschen. Dies wird dadurch erreicht, dass alle Herkunftsnachweise vom Build-Service innerhalb einer vertrauenswürdigen Steuerungsebene generiert werden und – ganz entscheidend – dass das zum Signieren der Herkunftsnachweise verwendete geheime Material niemals für benutzerdefinierte Build-Schritte zugänglich ist. Die Signaturschlüssel gehören der Build-Plattform, nicht der Build-Konfiguration, die von den Benutzern kontrolliert wird.
Diese zweite Anforderung macht Level 3 so leistungsfähig und sorgt dafür, dass die Verbindung zur Codesignierung strukturell und nicht nur zufällig wird. Auf Level 3 kann selbst ein böswilliger Insider mit vollem Zugriff auf die Build-Konfiguration die Herkunft nicht fälschen, da der Signaturschlüssel, der diese Herkunft belegt, in einem für den Insider unzugänglichen Teil des Systems gespeichert ist. Die Signatur der Herkunft ist daher eine vertrauenswürdige Aussage über den Build und nicht das Ergebnis eines kompromittierten Build-Schritts.
Das Ergebnis ist, dass die Herkunftsnachweise der Stufe 3 Fragen beantworten, die eine Signatur allein nicht beantworten kann. Sie sagen nicht einfach nur „Dieses Artefakt wurde genehmigt“. Sie sagen vielmehr: „Dieses Artefakt wurde aus genau diesem Quellcode-Commit, auf dieser gehärteten Plattform und durch diesen Prozess erstellt, und hier ist ein kryptografischer Beweis, der von einem System generiert wurde, das während der Build-Schritte selbst nicht manipuliert werden konnte.“
Wie Verschlüsselungsberatung helfen kann
Der Aufbau einer lückenlosen Nachweiskette vom Quellcode bis zur Binärdatei vereint genau die Disziplinen, die die Expertise von Encryption Consulting ausmachen: den Schutz von Signaturschlüsseln, die Kontrolle ihrer Verwendung und die Erstellung der von Sicherheit und Compliance geforderten, nachvollziehbaren Nachweise. Der Zusammenhang zwischen SLSA Level 3 und Codesignierung ist nicht zufällig, denn beides basiert letztlich auf der Integrität der Signaturinfrastruktur – und genau darauf konzentriert sich unsere Arbeit.
Unsere CodeSign Secure- Plattform bildet die Grundlage für die Signaturverarbeitung und damit für eine Level-3-Nachweiskette. Sie schützt private Signaturschlüssel in FIPS 140-3- und FIPS 140-2-Level-3-validierten Hardware-Sicherheitsmodulen (HSM) von Herstellern wie Thales , Entrust , Utimaco und Securosys . Dadurch wird sichergestellt, dass das zum Signieren von Artefakten und deren Herkunft verwendete Schlüsselmaterial niemals in Softwareform vorliegt und nicht durch einen kompromittierten Build-Schritt extrahiert werden kann.
Dies erfüllt direkt die SLSA-Level-3-Anforderung, dass Signaturgeheimnisse für benutzerdefinierte Build-Schritte unzugänglich bleiben müssen. Die Plattform erzwingt eine rollenbasierte Zugriffskontrolle darüber, wer Signaturvorgänge anfordern und genehmigen darf, verwendet RFC-3161-Zeitstempel, sodass Signaturen über den gesamten Lebenszyklus der veröffentlichten Software verifizierbar bleiben, und protokolliert jedes Signaturereignis in einem unveränderlichen Audit-Trail, der festhält, was, wann, von wem und in welcher Pipeline-Phase signiert wurde.
Dieser Prüfpfad liefert den überprüfbaren Nachweis, der die Integrität eines Builds für Verbraucher und Aufsichtsbehörden nachvollziehbar macht. Da CodeSign Secure direkt in CI/CD -Plattformen wie Azure DevOps , Jenkins und GitLab integriert ist , wird die Signierung zu einem geregelten, richtlinienkonformen Schritt im Workflow anstatt zu einem manuellen Vorgang – genau das Modell, das der automatisierte, buildplattformbasierte Ansatz von SLSA erfordert.
Über die Plattform selbst hinaus unterstützen unsere Beratungsteams Organisationen bei der Gestaltung der umfassenderen Architektur, die eine verifizierbare Nachweiskette erfordert. Dies reicht von der Bewertung des aktuellen Reifegrads Ihrer Build- und Signierungspipeline im Hinblick auf die SLSA-Stufen über die Strukturierung der Schlüsselverwaltungs- und Isolationskontrollen, die Stufe 3 verlangt, bis hin zur Angleichung der daraus resultierenden Nachweise an die regulatorischen Rahmenbedingungen wie NIST SSDF , Executive Order 14028 und den EU Cyber Resilience Act , die dies zunehmend erwarten.
Für Organisationen, die zusätzlich den zugrunde liegenden Hardware-Schlüsselschutz als verwaltete Funktion benötigen, bietet unser HSM as a Service- Angebot einen FIPS-validierten, herstellerunabhängigen Schlüsselschutz, der sowohl die Signierung von Artefakten als auch die Herkunftssignierung ermöglicht, ohne dass die Hardware im eigenen Haus betrieben werden muss.
Fazit
Die Zeiten, in denen eine gültige Signatur als ausreichender Beweis für die Vertrauenswürdigkeit von Software galt, sind vorbei. Die verheerendsten Lieferkettenangriffe der letzten Jahre haben nicht die Signaturen selbst beschädigt, sondern den Build-Prozess vor der Signierung manipuliert, sodass Schadcode mit einer völlig legitimen Signatur in Umlauf geriet. Um diese Lücke zu schließen, sind verifizierbare Beweise für den gesamten Weg vom Quellcode zur Binärdatei erforderlich. Genau dafür wurde SLSA, insbesondere SLSA Level 3, entwickelt.
Die zentrale Erkenntnis liegt im Zusammenhang zwischen SLSA Level 3 und der Codesignatur. Es handelt sich nicht um konkurrierende Ansätze, sondern um sich ergänzende Ebenen einer einzigen Nachweiskette. Die Herkunftsnachweise belegen, wie ein Artefakt erstellt wurde und beweisen, dass es selbst von einem Insider nicht gefälscht worden sein kann, während die Codesignatur die Authentizität und Unveränderlichkeit des Artefakts und seiner Herkunft sicherstellt.
Da regulatorische Rahmenbedingungen zunehmend nachweisbare statt selbstbehauptete Integrität fordern und Unternehmen sowie Behörden als Beschaffungsbedingung Mindeststandards für Software-Sicherheitszertifikate (SLSA) festlegen, entwickelt sich die Fähigkeit, für jede Binärdatei eine lückenlose Nachweiskette zu erstellen, von einem Sicherheitsideal zu einer geschäftlichen Notwendigkeit. Organisationen, die diese Fähigkeit jetzt aufbauen – beginnend mit der Signaturgrundlage und schrittweise bis hin zu Level 3 –, werden diejenigen sein, die beweisen und nicht nur versprechen können, dass ihre Software vertrauenswürdig ist.
Bei Encryption Consulting ist unsere CodeSign Secure- Plattform und unsere Beratungsleistungen genau darauf ausgelegt, diese Grundlage zu schaffen. Wenn Sie eine nachweisbare Herkunftskette für Ihre Software-Lieferkette anstreben, unterstützen wir Sie gerne.
