Wie integrieren Sie ML-DSA-Code-Signierung 2026 in CI/CD?

Ihr Build ist signiert, aber ein nachgelagerter Verbraucher weist die Signatur zurück oder kann das verwendete Verfahren nicht prüfen.
Schnellster sicherer Weg: Erproben Sie ML-DSA zunächst in einer isolierten CI/CD-Pipeline, testen Sie Schlüsselverwaltung, Signatur und Verifikation durch die tatsächlichen Verbraucher und schalten Sie erst danach schrittweise um. FIPS 204 standardisiert ML-DSA; daraus folgt nicht, dass Ihre gesamte Toolchain das Verfahren bereits unterstützt.

Dieser Leitfaden richtet sich an DevSecOps- und Anwendungssicherheitsteams, die Software-Artefakte signieren.
Auch wenn Sie Veröffentlichungsinfrastruktur oder Kryptobibliotheken betreuen, erhalten Sie einen Ablauf zur Prüfung beider Enden der Signaturkette.
Als Sicherheitsverantwortliche oder Sicherheitsverantwortlicher können Sie damit Pilotumfang und Rückfallbedingungen festlegen.

Vor dem Start: Vertrauensgrenzen und Signaturobjekt festlegen

Beginnen Sie nicht mit der Auswahl eines Pipeline-Schritts, sondern mit der Frage, was genau unterschrieben werden soll und wer die Signatur später prüft. Ein Build-Artefakt, ein Update-Paket, ein Container-Image und ein Manifest sind nicht automatisch dasselbe Signaturobjekt. Wird an einer Stelle das Paket signiert, an anderer aber ein nachträglich verändertes Archiv geprüft, kann die Signatur technisch korrekt und der gesamte Veröffentlichungsweg dennoch unbrauchbar sein.

Halten Sie deshalb den Ablauf vom Erzeugen bis zum Verwenden des Artefakts fest. Markieren Sie darin den Build-Prozess, den Signaturdienst, das Veröffentlichungsziel und alle Verbraucher, die vor Installation oder Ausführung prüfen müssen. Berücksichtigen Sie auch Zwischenschritte wie Archivierung, Spiegelung, Neuverpackung und Metadatengenerierung. Jeder Schritt, der Bytes verändert oder die Zuordnung zwischen Artefakt und Signatur verlieren kann, ist eine relevante Vertrauensgrenze.

ML-DSA ist die Bezeichnung des Verfahrens im finalen NIST-Standard FIPS 204. Behandeln Sie die Bezeichnung nicht als Synonym für eine beliebige Vorabimplementierung oder einen früheren Algorithmuskandidaten. Legen Sie fest, welche Implementierung eingesetzt wird und prüfen Sie deren offizielle Dokumentation sowie Versionshinweise. Für die technische Entscheidung müssen Sie vier Ebenen auseinanderhalten:

Erstellen Sie ein Datenflussdiagramm, das zeigt, wo der private Schlüssel verfügbar ist und wie der Verbraucher den öffentlichen Schlüssel sowie die Signatur erhält. Zeichnen Sie auch den administrativen Zugriff ein: Wer darf Schlüsselmaterial anlegen, verwenden, rotieren oder widerrufen? Die NIST-Informationen zur Migration auf Post-Quanten-Kryptografie bieten einen Rahmen, um Abhängigkeiten systematisch zu erfassen. Sie ersetzen aber nicht die Prüfung Ihrer konkreten Produkte und Versionen.

Achtung: Eine erfolgreiche Signaturprüfung beantwortet nicht automatisch, ob das Artefakt aus einem vertrauenswürdigen Build stammt. Verknüpfen Sie die Signaturprüfung deshalb mit nachvollziehbaren Informationen zur Herkunft und Freigabe des Builds.

Vor der Integration: Schlüssel, Berechtigungen und Rückfall planen

Schlüsselverwaltung gehört zur Architekturentscheidung, nicht zu den letzten Einstellungen im Job. Legen Sie fest, wie das Schlüsselpaar erzeugt wird, wo der private Schlüssel geschützt bleibt, welche Identität ihn für eine Signatur verwenden darf und wie Rotation oder Widerruf ablaufen. Die genaue Umsetzung hängt von Ihrer Bibliothek und Ihrem Schlüsselverwaltungssystem ab. Übernehmen Sie daher keine generischen Befehle aus einem fremden Beispiel, wenn die offizielle Dokumentation Ihrer ausgewählten Produkte andere Abläufe oder Sicherheitsgrenzen vorgibt.

Unterscheiden Sie zwischen dem Recht, einen Build auszuführen, dem Recht, ein Artefakt freizugeben, und dem Recht, einen Signaturschlüssel zu verwenden. Wenn ein gewöhnlicher Build-Job beliebige Eingaben signieren kann, ist die Beschränkung auf einen geschützten Schlüssel allein keine ausreichende Kontrolle. Regeln Sie, welche Pipeline-Identität für welche Artefaktklasse signieren darf und wie eine Freigabe außerhalb des Build-Schritts dokumentiert wird.

Verwenden Sie keine privaten Schlüssel als Klartext in einem Pipeline-Skript, als ungeschützte Konfigurationsdatei oder in öffentlich einsehbaren Protokollen. Die Dokumentation zur sicheren Verwendung von CI/CD-Geheimnissen beschreibt Schutzmaßnahmen für Geheimnisse in einem konkreten Automatisierungssystem. Übertragen Sie daraus nur die Prinzipien, die auf Ihre Umgebung zutreffen, und prüfen Sie die dokumentierten Grenzen Ihrer eigenen Plattform. Insbesondere ist ein als Geheimnis gespeicherter Wert nicht automatisch vor jedem Job, jeder Erweiterung oder jeder berechtigten administrativen Rolle verborgen.

Wenn Build-Herkunft für Ihre Freigabeentscheidung wichtig ist, planen Sie außerdem, welche Informationen die Provenienz enthalten muss und wie sie mit dem Artefakt verknüpft wird. Die SLSA-Spezifikation zur Provenienz beschreibt ein entsprechendes Formatkonzept. Provenienz ersetzt keine kryptografische Signatur und beweist für sich allein nicht, dass Ihr Build-Prozess sicher ist. Sie kann aber dabei helfen, Build-Identität und Artefakt nachvollziehbar zu verbinden.

Während der Integration: ML-DSA-Code-Signierung in CI/CD anbinden

Binden Sie den Signaturschritt erst ein, wenn klar ist, welches Artefakt signiert wird und welche Pipeline-Identität den Schritt ausführt. Das Signieren sollte an ein konkretes Build-Ergebnis gebunden sein: Erfassen Sie den Artefakt-Digest, die Build-Identität, den Signaturschlüssel beziehungsweise dessen Referenz und das Ergebnis der Freigabeprüfung. So können Sie später untersuchen, ob die Signatur zum veröffentlichten Artefakt gehört und welcher Prozess sie erstellt hat.

Vermeiden Sie dabei eine Kopplung, bei der Signatur und Freigabe als undurchsichtiger Einzelvorgang stattfinden. Der Build sollte die vorgesehenen Artefakte und Nachweise erzeugen; ein kontrollierter Schritt sollte prüfen, ob sie signiert werden dürfen; erst anschließend sollte die Veröffentlichung erfolgen. Dieses Modell erleichtert die Fehlersuche, weil ein fehlender Schlüsselzugriff nicht mit einem fehlerhaften Build oder einem Fehler beim Veröffentlichen verwechselt wird.

Für die Ablage von Signatur und Metadaten müssen Sie ein Format wählen, das Sender und Verbraucher gleichermaßen verstehen. DSSE beschreibt ein Umschlagformat zur Signierung von Aussagen. Das macht DSSE nicht automatisch zum passenden Format für jedes Paket und garantiert nicht, dass Ihre Installationsprogramme oder Registries es akzeptieren. Prüfen Sie die konkrete Einbettung sowie die Verteilung und Zuordnung des öffentlichen Schlüssels.

Halten Sie die Protokollierung auf Nachweise beschränkt, die Sie für Audit und Fehlersuche benötigen. Dazu können Job- und Build-Identität, Artefakt-Digest, Schlüsselreferenz, Zeit der Signaturanfrage und Ergebnis gehören. Das private Schlüsselmaterial selbst gehört nicht in Protokolle. Speichern Sie Fehlermeldungen so, dass sie die Ursache eingrenzen, ohne vertrauliche Eingaben oder interne Schlüsselwerte offenzulegen.

Danach: Signatur und Verbraucher unabhängig prüfen

Ein grüner Pipeline-Job ist kein ausreichender Abnahmetest. Führen Sie die Verifikation zusätzlich in der Umgebung aus, in der ein Artefakt später installiert, verteilt oder freigegeben wird. Verwenden Sie dafür dieselbe Bibliotheksfamilie und dasselbe Datenformat wie im vorgesehenen Betrieb, sofern Ihr Ziel nicht gerade die Kompatibilität mit einer abweichenden Verbraucherumgebung ist. Dokumentieren Sie Bibliotheksversionen und Konfiguration, damit ein positives Ergebnis reproduzierbar bleibt.

Die OpenSSL-Dokumentation zu ML-DSA-Signaturen zeigt, dass die Unterstützung an eine konkrete Bibliotheksdokumentation und deren Version gebunden ist. Lesen Sie die dort aufgeführten Voraussetzungen und Eigenschaften für genau die von Ihnen eingesetzte Version. Daraus lässt sich weder die Unterstützung eines beliebigen Paketformats noch die Kompatibilität anderer Bibliotheken ableiten. Prüfen Sie daher jede beteiligte Komponente einzeln.

Führen Sie für den Test mindestens diese Fälle aus:

1. Unverändertes Testartefakt: Signieren Sie ein isoliertes Artefakt und prüfen Sie, dass der vorgesehene Verbraucher die Signatur akzeptiert und sie dem richtigen öffentlichen Schlüssel zuordnet.
2. Verändertes Artefakt: Ändern Sie kontrolliert den Inhalt nach dem Signieren. Die Prüfung muss die Veränderung erkennen und darf das Artefakt nicht als gültig freigeben.
3. Nicht passender Schlüssel: Prüfen Sie mit einem anderen öffentlichen Schlüssel. Der Verbraucher darf eine nicht passende Signatur nicht als vertrauenswürdig behandeln.
4. Fehlende oder beschädigte Metadaten: Entfernen oder beschädigen Sie im Test die Zuordnung zwischen Signatur, Digest und Artefakt. Prüfen Sie, ob der Fehler eindeutig behandelt und protokolliert wird.
5. Realer Veröffentlichungsweg: Lassen Sie das Testartefakt den tatsächlichen Weg durch Registry, Spiegel, Archivierung und Verbraucher durchlaufen. Vergleichen Sie vor und nach jedem Format- oder Transportübergang den Digest.

Prüfen Sie außerdem, ob ein Verbraucher bei einem Fehler tatsächlich stoppt oder nur eine Warnung ausgibt. Ein Logeintrag ist keine Schutzmaßnahme, wenn die Veröffentlichung danach unverändert fortgesetzt wird. Legen Sie fest, wer Fehlermeldungen untersuchen darf und wie ein falscher Schlüssel, ein abgelaufenes Vertrauen oder ein Formatfehler behandelt werden. Wenn Sie personenbezogene oder vertrauliche Build-Daten verarbeiten, klären Sie deren Zugriff und Aufbewahrung im selben Prozess; Hinweise zu den eigenen Datenschutzinformationen finden Sie in der Datenschutzerklärung von ZavCloud.

Vor dem breiten Einsatz: Pilot, Verbraucherkompatibilität und Rückfall

Starten Sie mit einem nicht kritischen Artefakt und einem Verbraucher, dessen Verhalten Sie kontrollieren können. Ein Pilot soll nicht bloß bestätigen, dass die neue Signatur technisch erzeugt wird. Er muss zeigen, dass die tatsächliche Bereitstellungskette sie korrekt transportiert, dass Verbraucher Fehler ablehnen und dass Sie bei einer Störung zur bestehenden Freigaberoute zurückkehren können, ohne die Sicherheitsprüfung stillschweigend zu umgehen.

Erfassen Sie für jeden eingesetzten Verbraucher dessen Bibliothek, Signaturformat, Schlüsselverteilung und Verhalten bei unbekanntem Algorithmus. Dazu gehören auch ältere Clients, Wartungswerkzeuge und externe Freigabeschritte, die in normalen Builds nicht immer sichtbar sind. Fragen Sie nicht nur, ob ein System „ML-DSA unterstützt“, sondern welche genaue Version es unterstützt, auf welche Weise der Schlüssel konfiguriert wird und ob der Verbraucher dieselbe Signaturrepräsentation versteht wie der signierende Prozess.

Nutzen Sie für die Pilotentscheidung diese bedingten Pfade:

• Wenn Signieren und Verifizieren in Ihrer ausgewählten Implementierung dokumentiert sind, die Verbraucher das Artefaktformat akzeptieren und Negativtests zuverlässig scheitern, dann erweitern Sie den Pilot auf eine weitere unkritische Artefaktklasse.
• Wenn die Pipeline signiert, aber ein benötigter Verbraucher die Signatur nicht prüfen kann, dann veröffentlichen Sie das betroffene Artefakt nicht über den neuen Weg und behalten die etablierte Prüfung bei, bis die Kompatibilität nachgewiesen ist.
• Wenn Schlüsselzugriff, Rotation oder Widerruf nicht nachvollziehbar geregelt sind, dann stoppen Sie die Einführung und schließen Sie zuerst die Zuständigkeits- und Berechtigungslücken.
• Wenn ein verändertes Artefakt oder ein falscher Schlüssel akzeptiert wird, dann brechen Sie den Pilot ab und behandeln den Befund als Fehler in der Verifikationskette, nicht als kosmetisches Protokollproblem.
• Wenn eine Rückkehr nur möglich wäre, indem Sie eine Signaturprüfung deaktivieren, dann ist der Rückfallplan nicht freigabefähig. Halten Sie stattdessen den bisherigen geprüften Veröffentlichungsweg verfügbar.

Damit der Rückfall nicht zum unkontrollierten Dauerzustand wird, bestimmen Sie vor dem Pilot eine verantwortliche Rolle für die Fortsetzung oder den Abbruch. Halten Sie fest, welche Artefaktklasse betroffen ist, welche Prüfungen fehlgeschlagen sind und welche Nachweise vor einem erneuten Start erforderlich sind. Ein Rückfall sollte außerdem die bestehende Schlüsselzuordnung und Signaturprüfung erhalten. Vermeiden Sie eine Übergangsregel, die jedes Artefakt akzeptiert, sobald die neue Prüfung Schwierigkeiten bereitet.

Checkliste für die Freigabe des Piloten

• [ ] Signaturobjekt und Digest sind eindeutig festgelegt.
• [ ] Vertrauensgrenzen zwischen Build, Signatur, Veröffentlichung und Verbraucher sind dokumentiert.
• [ ] ML-DSA-Implementierung, Bibliotheksversion und Artefaktformat sind anhand der jeweiligen offiziellen Dokumentation geprüft.
• [ ] Private Schlüssel sind weder als Klartext in Skripten noch in öffentlichen Protokollen verfügbar.
• [ ] Berechtigungen für Build, Freigabe und Schlüsselverwendung sind voneinander abgegrenzt.
• [ ] Positive und negative Verifikationstests sind durchgelaufen.
• [ ] Ältere oder abweichende Verbraucher sind erfasst und praktisch getestet.
• [ ] Abbruchkriterien, Zuständigkeit und Rückfallweg sind vor dem Pilot beschlossen.

Häufige Fragen zur ML-DSA-Einführung

Eignet sich ML-DSA für die Signierung von Software-Artefakten?

Ja, ML-DSA ist ein standardisiertes digitales Signaturverfahren und kann für Software-Artefakte eingesetzt werden, wenn Ihre Kryptobibliothek, das Signaturformat und die prüfenden Verbraucher es unterstützen. Der Standard allein macht ein Paketformat oder einen Veröffentlichungsdienst jedoch nicht kompatibel. Prüfen Sie daher den vollständigen Weg vom signierenden Job bis zur Installation, bevor Sie produktive Veröffentlichungen umstellen.

Wie prüfen Sie ML-DSA-Signieren und Verifizieren in einer CI/CD-Pipeline?

Lassen Sie die Pipeline ein eindeutig identifiziertes Testartefakt erzeugen und signieren, und prüfen Sie die Signatur anschließend mit dem vorgesehenen Verbraucher. Ergänzen Sie Negativtests mit einem veränderten Artefakt und einem nicht passenden öffentlichen Schlüssel. Halten Sie Build-Identität, Artefakt-Digest, Schlüsselreferenz, Prüfergebnis und Freigabeentscheidung in getrennten, nachvollziehbaren Protokollen fest.

Können ältere Clients nach dem Wechsel weiterhin Signaturen prüfen?

Das lässt sich nicht aus der ML-DSA-Standardisierung ableiten. Ein älterer Client kann am Algorithmus, an der Bibliotheksversion, am Zertifikats- oder Signaturformat oder an der Verteilung des öffentlichen Schlüssels scheitern. Ermitteln Sie deshalb die tatsächlich eingesetzten Client-Versionen und testen Sie deren Verifikation mit dem konkreten Artefaktformat. Solange ein kritischer Verbraucher nicht geprüft ist, sollte die bestehende Verifikationsroute erhalten bleiben.

Welche Rückfallbedingungen gehören in einen ML-DSA-Pilot?

Definieren Sie vor dem Start, welche Fehler die Veröffentlichung stoppen: etwa eine nicht verifizierbare Signatur, fehlende Schlüsselzuordnung, unerwartete Änderungen am Artefakt oder ein nicht unterstützter Verbraucher. Legen Sie außerdem fest, wer den Pilot abbrechen darf und wie Sie zur bisherigen Freigaberoute zurückkehren. Ein Rückfall darf keine ungeprüften Artefakte freigeben oder die bestehende Signaturprüfung stillschweigend umgehen.

Wenn Ihre Testumgebung begrenzt: erst Kompatibilität, dann Infrastruktur wählen

Ein Wechsel der Entwicklungsumgebung löst keine Lücke in der Kryptobibliothek und belegt keine Unterstützung durch den Verbraucher. Für den ML-DSA-Pilot sind deshalb zuerst die konkreten Laufzeitabhängigkeiten, Berechtigungen und Datenflüsse maßgeblich. Wenn Sie die Pipeline auf einer Mac-Umgebung testen möchten, prüfen Sie vorher, ob benötigte Bibliotheken, Werkzeuge und Verbraucher dort in den tatsächlich eingesetzten Versionen verfügbar sind. ZavCloud kann als gemietete Mac-Umgebung eine Option sein, wenn Sie vorübergehend eine getrennte Entwicklungs- oder Testumgebung benötigen; daraus folgt keine Zusage, dass eine bestimmte ML-DSA-Konfiguration bereits unterstützt wird.

Gegenüber einer kurzfristig improvisierten Umgebung kann eine gemietete Mac-Umgebung den Aufwand für eigene Beschaffung und Bereitstellung vermeiden. Sie bringt aber weiterhin Aufgaben mit sich: Sie müssen Abhängigkeiten installieren und prüfen, Zugriffe begrenzen, Testdaten schützen und die Eignung für Ihren konkreten Signaturpfad selbst verifizieren. Für dauerhaft stark ausgelastete Builds, besondere physische Schnittstellen oder streng kontrollierte lokale Schlüsselprozesse kann ein eigener Mac oder eine andere vorhandene Infrastruktur besser passen. Wenn Sie eine zeitlich begrenzte Umgebung benötigen, prüfen Sie die Mietoptionen für Mac mini bei ZavCloud und klären Sie offene Fragen über das ZavCloud Hilfe-Zentrum, bevor Sie vertrauliche Build-Daten übertragen.

Für Ihre Post-Quanten-Kryptografie-Migration zählt letztlich nicht, ob ein einzelner Signaturschritt einen grünen Status zeigt, sondern ob alle beteiligten Verbraucher eine überprüfbare Signatur zuverlässig akzeptieren und Fehler sicher ablehnen. Erfassen Sie zuerst Bibliotheks- und Formatkompatibilität; nutzen Sie anschließend eine begrenzte Testumgebung, wenn sie zu Ihren Datenschutz- und Betriebsanforderungen passt, und erweitern Sie den Pilot erst nach bestandenem Rückfalltest.