SLSA-Build-Herkunftsnachweis und Signierung in CI/CD-Pipelines

Die meisten Sicherheitsteams verfügen heutzutage über eine Software-Stückliste (SBOM) . Doch eine Liste der Softwarekomponenten ist nur die halbe Wahrheit. Sie zeigt zwar, was sich in der Software befindet, sagt aber nichts darüber aus, wie diese Software erstellt wurde oder ob sie zwischen Quellcode-Repository und Produktionsserver manipuliert wurde.

Die Integrität eines Software-Builds nachzuweisen und nicht nur Komponenten zu katalogisieren, ist die Lücke, die Build-Provenienz und Artefaktsignatur schließen sollen. Kurz gesagt: Build-Provenienz ist ein signierter, verifizierbarer Nachweis darüber, wie, wo und aus welcher Quelle ein Software-Artefakt erstellt wurde. Die Artefaktsignatur ist das kryptografische Siegel, das diesen Nachweis manipulationssicher macht.

Dieser Blog erklärt, was Build-Provenienz wirklich bedeutet, wie die Supply-Chain Levels for Software Artifacts (SLSA)-Framework-Ebenen in der Praxis funktionieren und wie die Artefaktsignierung in eine CI/CD-Pipeline passt.

SLSA-Build-Provenienz, definiert: eine signierte In-Toto-Bescheinigung, die von der Build-Plattform selbst und nicht von einem benutzergesteuerten Skript generiert wird und den genauen Quellcode-Commit, das Build-System und die Eingaben hinter einem Artefakt aufzeichnet, sodass ein Prüfer kryptografisch bestätigen kann, was und wie gebaut wurde, anstatt der unbestätigten Behauptung eines Entwicklers oder eines CI-Logs zu vertrauen.

Wichtige Erkenntnisse

• Eine SBOM-Liste führt die Komponenten auf; die Provenienz belegt, wie der Build-Prozess selbst ablief. Die SolarWinds-SUNBURST-Sicherheitslücke von 2020, die XZ-Utils-Backdoor von 2024 und der Shai-Hulud-npm-Wurm von 2025 bestanden alle die Komponentenprüfungen, da die Kompromittierung im Build- oder Veröffentlichungspfad und nicht in einer aufgeführten Abhängigkeit erfolgte.
• SLSA v1.2 (November 2025) ist die aktuelle stabile Version; ihr Build Track definiert drei Stufen (eine vierte Stufe, hermetisch reproduzierbare Builds, ist geplant, aber noch nicht Teil der Spezifikation).
• Diese Seite erklärt, was Provenienz ist und wie sich die SLSA-Stufen vergleichen lassen. Detaillierte Informationen zur CI/CD-Implementierung, OIDC-Dienstidentität, doppelter Signatur, Genehmigungsgates und zum Beispiel-Workflow finden Sie hier: Stärkung der Lieferkettensicherheit mit SLSA Level 3 und Codesignatur.
• Eine signierte Herkunftsangabe, die bei der Bereitstellung nicht verifiziert wird, bietet keinen Schutz; die Verifizierung muss eine erzwungene Kontrollinstanz sein, keine optionale Prüfung.

Warum SBOMs allein nicht mehr ausreichen

Eine Software-Build-Map (SBOM) ist im Wesentlichen eine Teileliste. Sie zeigt an, welche Bibliotheken, Pakete und Abhängigkeiten in Ihrer Software enthalten sind. Das ist hilfreich, um bekannte Sicherheitslücken zu verfolgen und Lizenzverpflichtungen zu verwalten. Sie sagt jedoch nichts über die Integrität Ihres Build-Prozesses selbst aus.

Angreifer kennen diese Einschränkung seit Jahren. Beim SolarWinds-SUNBURST-Vorfall waren alle Softwarekomponenten des betroffenen Builds legitim. Der Angreifer hatte die Build-Pipeline kompromittiert und Schadcode in die kompilierte Ausgabe eingeschleust. Ein SBOM hätte saubere, vertrauenswürdige Komponenten aufgelistet. Es hätte die Kompromittierung nicht erkannt, da der Angriff innerhalb des Builds und nicht in einer Abhängigkeit stattfand.

Neuere Vorfälle folgen demselben Muster. Die 2024 entdeckte XZ Utils-Backdoor (CVE-2024-3094) und der 2025 entdeckte Shai-Hulud-npm-Wurm umgingen beide die Komponentenprüfungen. Der Shai-Hulud-Wurm kompromittierte dabei vertrauenswürdige Prozesse zur Paketveröffentlichung und CI/CD-Workflows. In beiden Fällen wurde der Build- oder Release-Pfad selbst manipuliert, nicht etwa eine gelistete Abhängigkeit.

Aus diesem Grund fordern Aufsichtsbehörden, Sicherheitsteams in Unternehmen und DevSecOps-Ingenieure nun präzisere Anforderungen. Sie benötigen einen kryptografischen, manipulationssicheren Nachweis, dass ein Artefakt aus einer bekannten Quelle, nach einem definierten Prozess und auf einem verifizierten Build-System erstellt wurde. Dieser Nachweis wird als Build-Provenienz bezeichnet.

NIST SP 800-204D , veröffentlicht im Februar 2024, behandelt dieses Thema direkt. Es betont kryptografisch signierte Attestierungen als grundlegenden Mechanismus zur Sicherstellung der Softwareintegrität und -herkunft in CI/CD-Pipelines. Die Publikation erklärt außerdem, dass SBOMs allein nicht für das Schwachstellenmanagement geeignet sind, da sie lediglich ein Komponenteninventar und keinen kryptografischen Nachweis darüber liefern, wie die Software erstellt wurde oder ob der Build-Prozess vertrauenswürdig war.

Diese kryptografischen Nachweise liefert genau das, was die Build-Provenienz bietet. Die praktische Frage ist dann, was genau aufgezeichnet wird und wie diese Aufzeichnung strukturiert ist.

Was versteht man unter Bauherkunft?

Die Build-Provenienz ist ein überprüfbarer Datensatz, der typischerweise kryptografisch signiert ist und vier Fragen zu einem Softwareartefakt beantwortet.

• Was: Das genaue Artefakt, identifiziert durch einen kryptografischen Hashwert (SHA-256-Digest).
• Wo: Das Quellcode-Repository und der spezifische Commit, der es erzeugt hat.
• Wann: Der Zeitpunkt, zu dem der Build durchgeführt wurde.
• Vorgehensweise: Das Build-System, die Workflow-Definition, die Runner-Umgebung und die verwendeten Eingaben.

Zusammengenommen bilden diese Details eine nachvollziehbare und verifizierbare Nachweiskette vom Code-Commit bis zum bereitstellbaren Artefakt. Im Falle eines Vorfalls lässt sich die Herkunft anhand der Aufzeichnungen zurückverfolgen. Wenn an einem Bereitstellungspunkt etwas verdächtig erscheint, kann die Behauptung kryptografisch verifiziert werden, anstatt sich auf eine Entwickleraussage oder ein CI-Protokoll zu verlassen, das jeder mit Pipeline-Zugriff manipulieren könnte.

Die Herkunft wird mithilfe des In-Toto-Attestierungsrahmens ausgedrückt. Eine In-Toto-Attestierung ist ein signiertes Dokument, das Metadaten mit einem Artefakt verknüpft. Sie besteht aus drei Teilen: dem Aussagetyp (der Art des Anspruchs), dem Subjekt (dem Artefakt, identifiziert durch seinen Digest) und dem Prädikat (den eigentlichen Metadaten, wie Repository, Workflow, Build-Eingaben und Builder-Identität). SLSA Build Provenance ist ein standardisiertes Herkunftsprädikat, das in einer In-Toto-Attestierungsaussage enthalten ist.

Die Definition der Herkunft ist das eine; die Festlegung messbarer Kriterien für deren Vertrauenswürdigkeit ist die Aufgabe des SLSA-Rahmenwerks.

SLSA: Ein Rahmenwerk für die Bauintegrität

SLSA ist ein offenes Framework der Open Source Security Foundation (OpenSSF) , das zunehmend strengere Anforderungen an die Softwareentwicklung sowie die Generierung und den Schutz der Herkunft definiert. Die aktuelle stabile Version ist SLSA v1.2 (November 2025), die den bestehenden Build Track um einen Source Track erweitert. Der Build Track definiert drei verschiedene Sicherheitsstufen.

SLSA-Stufe 1: Provenienz vorhanden

Der Build-Prozess generiert ein Herkunftsdokument, das die Herstellung des Artefakts beschreibt. Dieses Dokument wird zusammen mit dem Artefakt verteilt. Auf Stufe 1 ist die Herkunft nicht kryptografisch signiert. Jeder, der das Build-Skript ändern kann, kann auch die Herkunft ändern. Stufe 1 ist ein erster Schritt, der die Rückverfolgbarkeit verbessert und die Reaktion auf Sicherheitsvorfälle erleichtert, aber einen entschlossenen Angreifer nicht daran hindert, Herkunftsnachweise zu fälschen.

SLSA Level 2: Von der Build-Plattform unterzeichnet

Die Herkunftsnachweise müssen von der Build-Plattform selbst generiert und signiert werden, nicht von einem benutzergesteuerten Build-Skript. Der Signaturschlüssel wird von der Plattform verwaltet und ist für die Build-Schritte nicht zugänglich. Diese Unterscheidung ist entscheidend. Selbst wenn ein Angreifer ein Build-Skript auf Ebene 2 kompromittiert, kann er kein gültiges Herkunftsnachweisdokument fälschen, da er keinen Zugriff auf den Signaturschlüssel der Plattform hat. Ebene 2 ist für die meisten Teams das realistische Ziel. Sie lässt sich mit geringem Konfigurationsaufwand in GitHub Actions oder GitLab CI realisieren.

SLSA-Stufe 3: Gehärtete und isolierte Build-Umgebung

Die Build-Umgebung ist so gehärtet, dass der Signaturschlüssel und die geheimen Daten für die benutzerdefinierten Build-Schritte niemals zugänglich sind, selbst wenn diese Schritte vollständig kompromittiert werden. Die Build-Plattform gewährleistet Isolation auf Infrastrukturebene. Stufe 3 ist das geeignete Ziel für kritische Komponenten, Software, die in regulierten Umgebungen eingesetzt wird, und alles mit einer potenziell schwerwiegenden Angriffsfläche.

Man kann es sich einfach vorstellen: Stufe 1 ist eine Quittung. Stufe 2 ist eine Quittung mit einem offiziellen Plattformstempel, den der Entwickler unmöglich selbst gedruckt haben konnte. Stufe 3 ist eine Quittung, die in einem verschlossenen Raum erstellt wurde, in dem der Bediener keinen Zugriff auf den Stempelmechanismus hatte.

Es gibt auch eine vierte Stufe: hermetische, vollständig reproduzierbare Builds mit Zwei-Parteien-Review. Diese Stufe ist im ursprünglichen SLSA-Entwurf enthalten und für eine zukünftige Version geplant, aber nicht Teil der aktuellen Spezifikation v1.2. Daher ist Stufe 3 derzeit die höchste in der Spezifikation definierte Stufe, die eine Build-Plattform erfüllen muss.

SLSA-Streckenbau, Seite an Seite

Niveau	Herkunftsanforderung	Wer kann es schmieden?	Typischer Aufwand
Level 1	Existiert und wird zusammen mit dem Artefakt verbreitet.	Jeder, der das Build-Skript ändern kann	Niedrig; einen Herkunftsnachweis-Generierungsschritt hinzufügen.
Level 2	Generiert und signiert von der Build-Plattform, nicht vom Build-Skript.	Niemand ohne Zugriff auf den Signaturschlüssel der Plattform.	Mittel; erreichbar mit GitHub Actions oder GitLab CI und Pipeline-Konfiguration
Level 3	Erstellt in einer gehärteten, isolierten Build-Umgebung	Niemand, selbst nicht mit einem vollständigen Kompromiss beim Bauprozess.	Höher; erfordert kurzlebige, einmalig verwendbare Build-Umgebungen

Nachdem die Ebenen klar definiert sind, geht es im nächsten Schritt darum zu sehen, wie Provenienz und Signierung durch eine funktionierende CI/CD-Pipeline fließen.

Wie der gesamte Workflow in CI/CD zusammengeführt wird

Hier wird der Ablauf der Herkunftsnachverfolgung und Signatur in einer typischen CI/CD-Pipeline vom Commit bis zum Deployment dargestellt.

1. Es beginnt, wenn ein Entwickler Code in einen Branch hochlädt, und dieses Push-Ereignis löst die CI-Pipeline aus.
2. Anschließend wird der Build-Prozess ausgeführt, wobei der Quellcode kompiliert oder verpackt wird und Abhängigkeiten anhand von festgelegten, auf Digests basierenden Versionen anstatt von veränderlichen Tags aufgelöst werden.
3. Die Herkunftsangabe wird von der Plattform selbst generiert, nicht vom Build-Skript. Dabei wird eine vollständige Bestätigung erstellt, die den Quell-Commit, die Workflow-Identität, die Runner-Umgebung und den SHA-256-Digest des Ausgabeartefakts erfasst.
4. Bei einer schlüssellosen Signaturimplementierung wird die Attestierung von einem Dienst signiert, der ein kurzlebiges Zertifikat ausstellt, das an die OIDC-Identität (OpenID Connect) der Build-Plattform gebunden ist. Dieses Zertifikat wird zur Signierung der Attestierung verwendet, und der Signiervorgang wird in einem öffentlichen, manipulationssicheren Transparenzprotokoll aufgezeichnet. Da das Zertifikat nur kurzlebig ist, müssen keine langlebigen privaten Schlüssel gespeichert, rotiert oder widerrufen werden.
5. Bei Veröffentlichungen auf Produktionsebene ist vor dem Signierschritt die Unterschrift eines festgelegten Quorums von Genehmigern erforderlich, damit keine einzelne kompromittierte Identität eine Veröffentlichung eigenständig durchsetzen kann.
6. Die unterzeichnete Beglaubigung wird dann zusammen mit dem Artefakt in einem Containerregistrierung oder Artefakt-Repository, in einem Transparenzprotokoll oder in beidem.
7. Abschließend erfolgt die Verifizierung am Deployment-Gate. Bevor ein Artefakt in die Staging- oder Produktionsumgebung übertragen wird, überprüft eine Richtlinienprüfung die Signatur und bestätigt, dass die Attestierung aus dem erwarteten Repository und Workflow stammt. Außerdem wird geprüft, ob der Artefakt-Digest mit dem Herkunftsdatensatz übereinstimmt. Artefakte, die die Verifizierung nicht bestehen, werden automatisch abgelehnt.

GitLab CI bietet integrierte Unterstützung für die Herkunftsnachverfolgung. Die Verifizierung kann über die GitHub-CLI, ein Signaturprüfungstool oder einen Kubernetes - Admission-Controller erfolgen, der Richtlinien für jede Pod-Bereitstellung durchsetzt.

Genehmigungstore

Nicht jeder Build erfordert eine manuelle Genehmigung; interne Builds oder Entwicklungs-Builds können die Herkunftsnachweise automatisch generieren und signieren. Für Releases der Produktionsstufe gilt dies anders: Sie benötigen eine Genehmigung durch den Master of Network (M-of-N), bevor der Signaturdienst die Herkunftsnachweise verarbeitet. Dies wird durch die Richtlinien der Signaturplattform selbst erzwungen und nicht durch eine Pipeline-Logik, die ein modifizierter Build-Schritt umgehen könnte. Legen Sie im Voraus fest, wer für jede Release-Stufe die Genehmigungsberechtigten sind und was bei einem Timeout der Genehmigung geschieht – ob die Pipeline abgebrochen wird oder auf einen langsameren, explizit manuellen Pfad zurückgegriffen wird.

Fehlerbehandlung und Rollback

Ein Herkunfts- oder Signaturfehler sollte die Veröffentlichung verhindern und nicht nur eine Warnung ausgeben. Kann die Plattform keine Herkunftsnachweise generieren, wird die Genehmigung nicht erteilt oder ist der Signaturdienst nicht erreichbar, darf das Artefakt nicht veröffentlicht werden. Da schlüssellose Signaturzertifikate nur kurzlebig sind und keine dauerhafte Berechtigung darstellen, ist der Rollback in diesem Fall enger gefasst als bei einem Schlüsselkompromittierungsszenario: Stellt sich später heraus, dass ein signiertes und verifiziertes Artefakt aus einem kompromittierten Quellcode-Commit erstellt wurde, wird das Vertrauen in dieses spezifische Artefakt gemäß der Verifizierungsrichtlinie widerrufen (der entsprechende Digest wird blockiert) und die Bereitstellungen werden auf das letzte bekannte, fehlerfreie und unabhängig verifizierte Artefakt zurückgesetzt. Die Signaturinfrastruktur selbst wird nicht verändert.

Problemlösung

Symptom	Wahrscheinliche Ursache	Was zu überprüfen
Die Verifizierung schlägt fehl, obwohl das Artefakt legitim ist.	Die Bestätigung wurde durch einen Build-Schritt anstatt durch die vertrauenswürdige Steuerungsebene der Plattform generiert.	Stellen Sie sicher, dass die native Herkunftsnachweisfunktion der CI-Plattform aktiviert ist und nicht ein benutzerdefiniertes Skript die Attestierung generiert.
Beglaubigung vorhanden, aber Unterschriftenprüfung schlägt fehl	Der Verifizierer prüft den falschen OIDC-Aussteller oder einen abgelaufenen Transparenzprotokolleintrag.	Prüfen Sie, ob die erwartete Zertifikatsidentität und der Aussteller mit der tatsächlich verwendeten Build-Plattform übereinstimmen.
Diskrepanz zwischen Artefakt und Herkunftsnachweis	Das Artefakt wurde nach der Herkunftsermittlung neu aufgebaut oder neu verpackt.	Stellen Sie sicher, dass die Signierung genau auf dem Artefakt erfolgt, das veröffentlicht werden soll, ohne nachträgliche Änderungen.
Die Abhängigkeit von Drittanbietern hat keine zu überprüfende Herkunft.	Das Upstream-Paket veröffentlicht keine SLSA-Herkunftsdaten.	Behandeln Sie die Lücke als bekannt; bewerten Sie das Risiko anhand der Rolle dieser Komponente, anstatt eine Gleichwertigkeit mit einer verifizierten Komponente anzunehmen.

Die Integration in eine einzelne Pipeline ist unkompliziert; die Ausrollung in einer gesamten Organisation erfordert ein überlegteres Vorgehen.

Überlegungen zur Unternehmensimplementierung

Beginnen Sie mit den wichtigsten Artefakten, nicht mit allem.

Nicht jedes Artefakt in einem großen Unternehmen benötigt von Anfang an SLSA Level 3. Beginnen Sie damit, die Softwarekomponenten zu identifizieren, die kundenorientiert sind, in regulierten Umgebungen eingesetzt werden oder Teil kritischer Infrastrukturen sind. Wenden Sie SLSA Level 2 zunächst auf diese an, richten Sie die entsprechenden Prüfmechanismen ein und führen Sie die Anwendung anschließend flächendeckend ein. Dieser schrittweise Ansatz hält den Aufwand überschaubar und liefert schnell einen Mehrwert hinsichtlich der Compliance.

Die Überprüfung ist genauso wichtig wie die Unterzeichnung.

Viele Teams implementieren Signierung und gehen davon aus, dass damit alles erledigt ist. Die Herkunftsnachweise bieten jedoch nur dann echten Sicherheitsnutzen, wenn sie aktiv zum Zeitpunkt der Bereitstellung überprüft werden. Fügen Sie daher jedem Bereitstellungs-Pipeline einen Verifizierungsschritt hinzu. Konfigurieren Sie Ihren Kubernetes Admission Controller oder Ihr Deployment Gate so, dass Artefakte ohne gültige, richtlinienkonforme Attestierung abgelehnt werden. Ein Artefakt, dessen Herkunft nicht mit dem erwarteten Quell-Repository, Branch oder Workflow übereinstimmt, darf niemals in die Produktion gelangen.

Abhängigkeiten an Digests anheften

Die Herkunft Ihres Builds lässt sich nur dann präzise dokumentieren, wenn die Eingaben stabil sind. Löst Ihre Pipeline Abhängigkeiten dynamisch anhand veränderlicher Versionskennzeichnungen auf, kann ein bösartiges Update eines öffentlichen Registry-Pakets den Inhalt Ihres Artefakts verändern, ohne dass Sie Ihren Quellcode anpassen müssen. Binden Sie Abhängigkeiten daher an spezifische SHA-256-Hashwerte anstatt an Versionskennzeichnungen. Dadurch werden Ihre Builds reproduzierbar und Ihre Herkunft aussagekräftig.

Langlebige Signaturen erfordern Zeitstempel

Kurzlebige Signaturzertifikate eignen sich gut für die Signatur während des Build-Prozesses, bei der die Verifizierung kurz nach der Signatur erfolgt. Müssen Sie Release-Artefakte Jahre nach ihrer Signatur verifizieren, reichen kurzlebige Zertifikate allein nicht aus, da das Zertifikat lange vor der Verifizierung abgelaufen ist. In diesen Fällen benötigen Sie zusätzlich einen RFC-3161-Zeitstempel von einer vertrauenswürdigen Zeitstempelstelle. Dieser bindet die Signatur an einen Zeitpunkt, der unabhängig von der Zertifikatsgültigkeit verifiziert werden kann. Für maximale Sicherheit sollten Sie Ihre Signaturschlüssel in einem HSM (Hardware-Sicherheitsmodul) verankern , um das Auslesen der Schlüssel zu verhindern und die physische Sicherheit Ihrer Signaturinfrastruktur zu gewährleisten.

Selbst Teams, die diese Vorgehensweisen genau befolgen, können Fehler machen. Deshalb lohnt es sich, die Fehler aufzuzeigen, die in der Praxis am häufigsten die Nachvollziehbarkeit von Bauwerken beeinträchtigen.

Wo die Herkunftsbestimmung schiefgeht

• Herkunftsnachweise im Build-Skript generieren: Wenn das Build-Skript den Generator für Herkunftsnachweise steuert, kann ein Angreifer, der das Skript kompromittiert hat, die Herkunftsangaben verfälschen. Die Herkunftsnachweise müssen von der Build-Plattform und außerhalb der vom Benutzer gesteuerten Schritte generiert werden. Diese Abgrenzung unterscheidet SLSA Level 2 von Level 1.
• Signieren ohne Verifizierungsmechanismen: Signierte Atteste zu erstellen, ohne sie beim Deployment zu überprüfen, erzeugt ein trügerisches Sicherheitsgefühl. Jeder Produktionspfad muss einen Verifizierungsschritt beinhalten, der nicht konforme Artefakte ablehnt.
• Die Verwendung langlebiger Schlüssel ohne HSM-Schutz oder Rotationspläne kann die gesamte Vertrauenskette ungültig machen. Statische, softwaregespeicherte Schlüssel müssen durch HSMs geschützt und durch dokumentierte Rotations- und Widerrufsverfahren unterstützt werden.
• Die Herkunftsprüfung als reine Dokumentationsübung zu betrachten, ist nicht sinnvoll, da sie nur dann einen Mehrwert bietet, wenn sie Entscheidungen zur Zugriffskontrolle und Reaktion auf Sicherheitsvorfälle steuert. Wird Ihre Verifizierungsrichtlinie nicht automatisch durchgesetzt, dient sie lediglich der Erfüllung der Compliance-Vorgaben und bietet keine tatsächliche Sicherheit.
• Ignorieren der Herkunft von Drittanbieterabhängigkeiten: Ihr eigener Quellcode mag sauber sein, aber Ihre Drittanbieterabhängigkeiten möglicherweise nicht. Wenn ein Upstream-Paket die Herkunft gemäß SLSA veröffentlicht, überprüfen Sie diese. Und wenn dies nicht der Fall ist, bewerten Sie, ob diese Lücke angesichts der Rolle der Komponente in Ihrer Software ein akzeptables Risiko darstellt.

Die Vermeidung dieser Fallstricke ist der Unterschied zwischen einem Herkunftsnachweisprogramm, das das Risiko tatsächlich reduziert, und einem, das nur auf dem Papier existiert.

Hier zahlt sich die fachliche Beratung aus, insbesondere da sich die der Build-Sicherheit zugrunde liegende Kryptographie zu verändern beginnt.

Wie Verschlüsselungsberatung helfen kann

CodeSign Secure ist die Enterprise-Codesignatur-Managementplattform von Encryption Consulting, die entwickelt wurde, um die von verschiedenen Branchen benötigten Infrastrukturkontrollen bereitzustellen.

HSM-gestütztes Schlüsselmanagement

CodeSign Secure speichert alle privaten Signaturschlüssel in FIPS 140-2 Level 3-zertifizierten Hardware-Sicherheitsmodulen (HSMs) und ist mit Thales Luna, Entrust nCipher, Utimaco, Securosys sowie Cloud-HSMs von AWS und Azure kompatibel. Die Schlüsselisolation pro Produkt wird auf HSM-Partitionsebene gewährleistet: Jede Produktlinie erhält einen eigenen, dedizierten Schlüssel, der in der Hardware generiert und niemals exportiert wird.

Unterzeichnungsbeschlussfähigkeit und RBAC der M-of-N

Das rollenbasierte Zugriffskontrollmodell der Plattform erzwingt die Genehmigungsanforderungen (M-von-N) für die Signierung von Produktions-Firmware. Keine einzelne Person kann einen Signiervorgang initiieren und genehmigen. Signieranfragen, Genehmigungen und Ablehnungen werden protokolliert. Die RBAC-Konfiguration selbst ist auditierbar und versionskontrolliert und stellt somit die dokumentierte Signierrichtlinie bereit, die für CRA-Konformitätsbewertungen erforderlich ist.

Unveränderliche Audit-Protokollierung

Jeder Signaturvorgang in CodeSign Secure erzeugt einen unveränderlichen Protokolleintrag, der den Artefakt-Hash, die Schlüsselkennung, das verwendete Zertifikat, die genehmigende Identität und den RFC-3161-Zeitstempel erfasst. Die Protokolle werden zentral und getrennt von der Signaturinfrastruktur gespeichert.

Unterstützung für plattformübergreifende Firmware-Formate

CodeSign Secure unterstützt die Signierung von Firmware-Artefakten in allen Formaten, die ein vielfältiges Produktportfolio erfordert: .bin, .img, .hex, .fw, .dfu und .efi. Damit wird die Anforderung der CRA nach einheitlichen Kontrollen über alle Produktlinien hinweg erfüllt, ohne dass die Signaturinfrastruktur für jede Plattform neu aufgebaut werden muss.

Unterstützung für Post-Quanten-Kryptographie

CodeSign Secure v3.02 unterstützt produktionsreife ML-DSA (FIPS 204, Sicherheitsstufen ML-DSA-44, ML-DSA-65 und ML-DSA-87) und SLH-DSA (FIPS 205) als abtrennbare Signaturen neben klassischen Algorithmen. Für Hersteller von Produkten mit mehr als fünf Jahren CRA- Supportverpflichtungen bietet die PQC-Signaturarchitektur heute Schutz vor der HNDL-Bedrohung, bevor eine CRQC-Zertifizierung verfügbar ist.

CI/CD-Pipeline-Integration

CodeSign Secure lässt sich über API- und Befehlszeilenschnittstellen in Azure DevOps , Jenkins , GitLab CI und andere gängige Pipeline-Plattformen integrieren. Die Signierung der Firmware ist ein kontrollierter, richtlinienkonformer Schritt in der Build-Pipeline und kein manueller Vorgang.

Häufig gestellte Fragen

Liefert mir ein SBOM bereits die Build-Herkunft?

Nein. Ein SBOM listet die Komponenten eines Artefakts auf; es sagt nichts darüber aus, wie der Build-Prozess selbst durchgeführt wurde oder ob dieser manipuliert wurde. SolarWinds SUNBURST ist das deutlichste Beispiel: Jede aufgeführte Komponente war legitim, aber die Build-Pipeline selbst war kompromittiert.

Worin besteht der praktische Unterschied zwischen SLSA Level 1 und Level 2?

Wer kann die Herkunft fälschen? Auf Stufe 1 kann jeder, der das Build-Skript ändern kann, auch den Herkunftsnachweis ändern. Auf Stufe 2 wird die Herkunft von der Build-Plattform selbst generiert und signiert, außerhalb der vom Benutzer gesteuerten Build-Schritte. Daher kann ein kompromittiertes Skript sie nicht fälschen.

Gibt es ein SLSA-Level 4?

Nicht in der aktuellen Spezifikation v1.2 enthalten. Eine vierte Stufe, die hermetische, vollständig reproduzierbare Builds mit Zwei-Parteien-Review umfasst, existiert im ursprünglichen SLSA-Entwurf und ist für eine zukünftige Version geplant, aber Stufe 3 ist die höchste in der aktuellen Spezifikation definierte Stufe.

Was passiert, wenn eine Drittanbieterabhängigkeit die SLSA-Herkunft nicht veröffentlicht?

Das ist eine bekannte Sicherheitslücke, die man nicht ignorieren sollte. Bewerten Sie das Risiko anhand der Rolle dieser Komponente in Ihrer Software, anstatt anzunehmen, sie sei einer überprüfbaren Abhängigkeit gleichwertig.

Fazit

SBOMs geben Sicherheitsteams Einblick in die Softwareentwicklung. Build-Provenienz und Artefaktsignatur gehen den nächsten Schritt. Sie liefern kryptografische Beweise für die Softwareentwicklung und tragen dazu bei, dass die Software unverändert in die Produktion gelangt. Das SLSA-Framework setzt diese Idee in einen praktischen, stufenweisen Ansatz um. Anstatt Teams zu überfordern, alles auf einmal zu lösen, definiert es klare Stufen, die schrittweise implementiert werden können.

Stufe 1 erfordert die Generierung und Bereitstellung der Build-Herkunft, um Teams einen Nachweis darüber zu geben, wie jedes Artefakt erstellt wurde. Stufe 2 erhöht die Sicherheit, indem die Build-Plattform selbst diese Herkunft generiert und signiert. Dies verhindert, dass ein kompromittiertes Build-Skript sie fälscht, und ist auf den meisten modernen CI-Plattformen realisierbar. Stufe 3 härtet die Build-Umgebung für kritische Workloads und sicherheitskritische Software weiter ab. Für viele Organisationen bietet das frühzeitige Erreichen von Stufe 2 eine solide Sicherheitsgrundlage, während Stufe 3 im Laufe der Zeit eingeführt werden kann, wenn höhere Sicherheitsanforderungen bestehen. Organisationen, die diesen Weg jetzt beschreiten, sind gut aufgestellt, da die verifizierbare Integrität von Builds zur Grundvoraussetzung wird.

Wenn Sie wissen möchten, wo Ihre Organisation heute in Bezug auf Herkunftsnachweise, Artefaktsignatur oder PQC-Bereitschaft für Ihre Lieferkette steht, kontaktieren Sie uns, um das Gespräch zu beginnen.