Best Practices für die Codesignierung im Softwareentwicklungszyklus

Moderne Software wird zusammengesetzt, nicht geschrieben. Eine einzelne Version bindet Pakete aus Open-Source-Quellen, Container-Images, SDKs externer Anbieter und automatisierte Build-Pipelines ein. Jedes dieser Elemente stellt ein potenzielles Einfallstor für Angreifer dar. In diesem Umfeld ist die digitale Signatur eines Builds häufig die letzte verifizierbare Bestätigung dafür, dass die vom Benutzer ausgeführten Dateien tatsächlich von Ihrem Unternehmen stammen.

Die Codesignierung ist das Verfahren, einem Softwareprodukt eine kryptografische digitale Signatur hinzuzufügen, sodass jeder überprüfen kann, wer es erstellt hat und dass es nicht verändert wurde. Die damit verbundenen Sicherheitsvorkehrungen – also wie Schlüssel generiert, geschützt, verwendet und außer Betrieb genommen werden – entscheiden darüber, ob die Kontrolle Angriffen standhält.

Die Risiken sind nicht theoretischer Natur. Gartner prognostizierte, dass bis 2025 weltweit 45 % der Unternehmen Opfer eines Angriffs auf ihre Software-Lieferkette werden würden – eine Verdreifachung gegenüber 2021. Diese Prognose erwies sich sogar als konservativ. Der Verizon-Bericht „Data Breach Investigations Report 2025“ ergab, dass Dritte an rund 30 % der Datenschutzverletzungen beteiligt waren – etwa doppelt so viele wie im Vorjahr.

Dieser Blog konzentriert sich darauf, wie die Codesignierung tatsächlich funktioniert, wo sie im Softwareentwicklungslebenszyklus (SDLC) ihren Platz hat, auf den gesamten Prozess, durch den Software geplant, erstellt, getestet, veröffentlicht und gewartet wird, und auf die Best Practices für die Codesignierung.

Best Practices für die Codesignierung, definiert: die Kontrollmechanismen, HSM-gestützte, nicht exportierbare Schlüssel, ein zentralisierter Signaturdienst, obligatorische Zeitstempelung, erzwungene Verifizierung bei der Bereitstellung, RBAC mit M-of-N-Genehmigung und unveränderliche Audit-Logs, die dafür sorgen, dass eine digitale Signatur eine vertrauenswürdige Ursprungserklärung bleibt und nicht zu einer Kontrolle wird, die ein Angreifer stehlen oder umgehen kann.

Wichtige Erkenntnisse

• Eine gültige Signatur beweist die Herkunft, nicht die Sicherheit. Die Vorfälle bei 3CX (2023) und NVIDIA (2022) zeigen zwei unterschiedliche Fehlermodi: eine kompromittierte Build-Pipeline, die Schadcode mit einem gültigen Schlüssel signiert, und ein gestohlener Schlüssel, der Schadsoftware direkt signiert.
• Seit dem 1. Juni 2023 schreiben die Regeln des CA/Browser Forums vor, dass private Codesignaturschlüssel generiert und nicht exportierbar in einem Hardwaremodul gemäß FIPS 140-2 Level 2+ (oder Common Criteria EAL4+) gespeichert werden müssen.
• Diese Seite enthält eine Checkliste mit Best Practices für den gesamten Softwareentwicklungszyklus (SDLC). Eine detaillierte, schrittweise Anleitung zur CI/CD-Implementierungsarchitektur, OIDC-Dienstidentität, doppelter Signatur und Verifizierungstools finden Sie hier: Stärkung der Lieferkettensicherheit mit SLSA Level 3 und Codesignatur.
• Eine Signatur, die niemand überprüft, bietet keinen Schutz; die Verifizierung muss zum Zeitpunkt der Verwendung (Bereitstellung, Zugangskontrolle, Bootloader) erzwungen werden und darf nicht nur zur Build-Zeit erfolgen.
• Die Zeitstempelung (RFC 3161) sorgt dafür, dass eine Signatur auch nach Ablauf des Zertifikats gültig bleibt; wird sie übersprungen, muss jedes Mal, wenn ein Zertifikat abläuft, die gesamte Release-Historie neu signiert werden.

Wie Codesignierung funktioniert: Die kryptografische Vertrauenskette

Im Kern verknüpft die Codesignierung ein Artefakt mithilfe asymmetrischer Kryptografie mit der Identität des Herausgebers. Das Signaturwerkzeug berechnet einen kryptografischen Hashwert (einen Digest) des Artefakts und transformiert diesen anschließend mit dem privaten Schlüssel des Herausgebers, um eine digitale Signatur zu erzeugen. Jeder kann das Ergebnis mit dem zugehörigen öffentlichen Schlüssel überprüfen, indem er den Hashwert erneut berechnet und bestätigt, dass sich nach der Signatur nichts geändert hat. Da der private Schlüssel niemals weitergegeben wird, bleibt die Verifizierung offen, während die Signatur streng kontrolliert wird.

Diese Signatur steht nicht für sich allein. Sie ist Teil des X.509-Zertifikats des Unterzeichners und der Zertifikatskette, die zu einem vertrauenswürdigen Stammzertifikat zurückführt. Die meisten Signaturformate, darunter Microsoft Authenticode, Java JAR-Signatur und Apples Codesignaturen, basieren auf der Cryptographic Message Syntax (CMS, RFC 5652), dem IETF-Nachfolger von PKCS #7. Der Prüfer durchläuft diese Kette gemäß RFC 5280, prüft die Gültigkeitsdaten, bestätigt, dass das Zertifikat die erweiterte Schlüsselverwendung für die Codesignatur enthält, und testet den Sperrstatus mithilfe einer CRL oder OCSP.

Ein Punkt verdient besondere Beachtung, da er die Ursache der schwerwiegendsten Vorfälle ist: Eine gültige Signatur beweist lediglich die Herkunft eines Artefakts, nicht dessen Sicherheit. Wenn ein Angreifer den privaten Schlüssel stiehlt oder die Build-Pipeline kompromittiert, die den Signierer speist, zertifiziert die Signatur fälschlicherweise Schadsoftware. Codesignierung gewährleistet Authentizität und Integrität, ist aber nur so vertrauenswürdig wie der Schlüssel und die zugrundeliegende Pipeline.

Zwei weitere Details bereiten selbst erfahrenen Teams Kopfzerbrechen. Erstens die Zertifikatswiderrufung. Wird ein Signaturschlüssel kompromittiert, muss das Zertifikat widerrufen werden. Der Widerruf schützt jedoch nur diejenigen Prüfstellen, die ihn auch tatsächlich überprüfen. Zweitens die Zeitstempelung. Ein vertrauenswürdiger Zeitstempel ist eine Gegensignatur einer Zeitstempelstelle (RFC 3161), die den Erstellungszeitpunkt einer Signatur festhält. Ohne ihn verfällt jede Signatur mit dem Zertifikat, und die erneute Signierung eines gesamten älteren Katalogs ist selten praktikabel. Mit Zeitstempel hingegen kann Software, die während der Gültigkeitsdauer des Zertifikats signiert wurde, auch nach dessen Ablauf weiterhin verifiziert werden. Wie spätere Vorfälle zeigen, liegt der Haken darin, dass Plattformen, die abgelaufene oder widerrufene Zertifikate nachsichtig akzeptieren, diese Bequemlichkeit in eine Sicherheitslücke verwandeln.

Wo Codesignierung in den SDLC und die DevSecOps-Pipeline passt

Das Verständnis der Funktionsweise von Kryptografie ist nur die halbe Wahrheit; der Zeitpunkt der Signierung im Entwicklungsprozess entscheidet darüber, ob diese Garantien tatsächlich gelten. Codesignierung ist am effektivsten als fester Bestandteil der Entwicklungspipeline und nicht als manueller Schritt vor der Veröffentlichung. Das Secure Software Development Framework des NIST betrachtet den Schutz der Integrität veröffentlichter Artefakte als Kernpraxis. Das Referenzmuster ist einfach: erst erstellen, dann signieren, dann verifizieren. Die zugrunde liegende Architektur sorgt für die Langlebigkeit.

Das Erstellen und Signieren von Dateien muss getrennt werden. Das Build-System sollte keine Signaturschlüssel speichern. Es übermittelt einen Hash oder ein Artefakt an einen dedizierten Signaturdienst, der den Schlüssel verwaltet, Richtlinien anwendet und eine Signatur zurückgibt. Dadurch bleiben die Schlüssel von den CI-Runnern fern – dem Teil der Pipeline , der am anfälligsten für Abhängigkeits- und Plugin-Kompromittierungen ist.

Signieren Sie nur, was Sie verifiziert haben. Beschränken Sie die Signierberechtigung auf Artefakte, die Integritäts-, Herkunfts- und Sicherheitsprüfungen bestanden haben. Das Signieren eines nicht verifizierten Builds verleiht lediglich Vertrauen in etwas, das Sie nie validiert haben.

Überprüfen Sie die Images nicht nur beim Verlassen, sondern auch beim Empfang. Erzwingen Sie die Signaturprüfung beim Deployment, beispielsweise durch einen Kubernetes Admission-Controller, der unsignierte oder nicht vertrauenswürdige Images ablehnt. Eine Signatur, die niemand prüft, bietet keinen Schutz.

Das Ökosystem hat sich um diese Ideen herum weiterentwickelt. Lieferketten- Frameworks wie SLSA definieren Herkunftsnachweise, In-toto-Attestierungen erfassen verifizierbare Metadaten über die Erstellung eines Artefakts, und schlüssellose Verfahren mit sehr kurzer Gültigkeitsdauer sind an OIDC-Identitäten gebunden und protokollieren Signaturen in einem öffentlichen Transparenzprotokoll. Dadurch wird der Zeitraum, in dem ein gestohlener, gültiger Schlüssel nützlich ist, stark eingeschränkt. Diese Ansätze ergänzen die Signierung veröffentlichter Binärdateien mit Zertifikaten, anstatt sie zu ersetzen. Sie alle basieren jedoch weiterhin auf der Annahme, dass der Signaturschlüssel selbst nicht kopiert werden kann – genau diese Annahme soll durch eine kürzlich erlassene Branchenverordnung durchgesetzt werden.

Das CA/Browser Forum HSM-Mandat: Was hat sich geändert und warum ist es wichtig?

Die größte operative Änderung im Bereich der öffentlich vertrauenswürdigen Codesignatur trat am 1. Juni 2023 in Kraft. Gemäß den Code Signing Baseline Requirements des CA/Browser Forums müssen private Schlüssel für sowohl Organisationsvalidierungs- (OV) als auch Extended Validation (EV) Codesignaturzertifikate nun in einem Hardware-Kryptomodul generiert und gespeichert werden, das mindestens nach FIPS 140-2 Level 2 oder Common Criteria EAL 4+ zertifiziert ist. Der Schlüssel muss zudem so gekennzeichnet sein, dass er nicht exportiert werden kann.

Es ist zu beachten, dass FIPS 140-2 mittlerweile durch den neueren Standard FIPS 140-3 ersetzt wird. Das CMVP hat die Annahme neuer Validierungsanträge nach FIPS 140-2 im September 2021 im Zuge der Umstellung auf FIPS 140-3 eingestellt. Bereits validierte Module nach FIPS 140-2 sind noch bis zum 21. September 2026 gültig. Danach werden sie in die Liste der historischen Module aufgenommen und sind in der Regel nur noch für bestehende Systeme und nicht mehr für Neubeschaffungen vorgesehen.

Zertifizierungsstellen überprüfen dies, häufig mittels Remote-Key-Attestierung, bevor sie das Zertifikat ausstellen. Der Grund dafür ist einfach: In Software gespeicherte Schlüssel können kopiert, gestohlen und wiederverwendet werden. Indem man Schlüssel in manipulationssicherer Hardware speichert, wo sie nicht exportiert werden können, wird die Angriffsfläche drastisch reduziert. Der Nachteil ist die höhere operative Komplexität. Sobald ein Schlüssel in einem HSM oder Token gespeichert ist und diesen nicht verlassen kann, muss jeder Signiervorgang auf diese Hardware zugreifen. Dies muss sorgfältig gehandhabt werden, da Token in verteilten Build-Umgebungen nicht skalierbar sind und ein schlecht integriertes HSM zum Flaschenhals wird.

Schlüsselschutz, Governance und Compliance

Hardwarebasierter Schutz ist notwendig, aber nicht ausreichend. Ein Signaturschlüssel in einem HSM, den jeder aufrufen kann, stellt nach wie vor einen kritischen Vertrauenspunkt dar. Erst durch Governance wird die Kontrolle sinnvoll.

Zugriffskontrolle und Funktionstrennung. Setzen Sie Zugriffskontrollen ein, um sicherzustellen, dass Anfordern, Genehmigen und Unterzeichnen separate Aufgaben sind. Für Ihre wichtigsten Freigabeschlüssel ist eine Vier-Augen-Regel oder die Genehmigung durch ein Quorum erforderlich, damit niemand allein unterschreiben kann.

Begrenzte Anmeldeinformationen mit kurzer Gültigkeitsdauer. Beschränken Sie die Anzahl der Schlüssel, die eine bestimmte Pipeline verwenden darf, und deren Gültigkeitsdauer. Bevorzugen Sie für CI temporäre Signaturen gegenüber dauerhaften Geheimnissen.

Vollständige, unveränderliche Prüfprotokolle. Jedes Signaturereignis wird zentral protokolliert: Wer hat welches Artefakt mit welchem ​​Schlüssel wann signiert? Dies dient sowohl der Erkennung von Sicherheitslücken als auch als Nachweisgrundlage für Audits nach ISO/IEC 27001, SOC 2 und PCI DSS.

Ein erprobter Widerrufs- und Rotationsplan. Wissen Sie im Voraus, wie Sie einen Schlüssel widerrufen, Plattformanbieter benachrichtigen und einen Ersatz ausstellen, bevor Sie ihn benötigen.

Die grundlegenden Richtlinien des NIST, das Cybersecurity White Paper Security Considerations for Code Signing, beschreiben diese architektonischen Erwartungen detailliert und sind nach wie vor eine nützliche Referenz für die Bewertung einer Signaturlösung.

Eine starke Unternehmensführung bietet Organisationen weiterhin Schutz vor den heutigen Bedrohungen. Die schwierigere Frage ist, ob die zugrunde liegenden Algorithmen auch nach der Marktreife des Quantencomputings noch Bestand haben werden – und genau hier beginnt die vorausschauende Planung.

Kryptografische Agilität und Quantenbereitschaft

Heute ausgelieferter Code, darunter Firmware, Medizinprodukte, industrielle Steuerungen und Unternehmenssoftware, die jahrelang im Einsatz ist, könnte noch laufen, wenn leistungsstarke Quantencomputer RSA- und elliptische Kurvenkryptographie knacken können. Da dieser Code anhand von Schlüsseln verifiziert werden muss, die Jahre zuvor eingebettet wurden, ist die Codesignierung einer der ersten Bereiche, in denen Unternehmen kryptografische Flexibilität aufbauen sollten.

Kryptografische Agilität bezeichnet die Fähigkeit, die Algorithmen eines Systems zu ändern, ohne das System selbst grundlegend umbauen zu müssen. Im Kontext der Signaturerstellung bedeutet dies, den Signaturalgorithmus als konfigurierbare Option und nicht als fest codierte Konstante zu behandeln: Er wird hinter einem Signaturdienst oder einer Schnittstelle abstrahiert, der verwendete Algorithmus wird in jeder Signatur und jedem Zertifikat protokolliert, und es wird sichergestellt, dass Prüfverfahren mehrere Schemata gleichzeitig akzeptieren können. Dank dieser Agilität kann ein Unternehmen einen neuen Algorithmus einführen, ihn parallel zum bestehenden betreiben und den alten Algorithmus nach eigenem Zeitplan außer Betrieb nehmen, anstatt hektisch die Firmware neu entwickeln zu müssen.

Im August 2024 finalisierte das NIST seine ersten Standards, die Quantencomputern widerstehen sollen: FIPS 204 (ML-DSA, eine Signatur basierend auf Gitterkryptographie) und FIPS 205 (SLH-DSA, eine zustandslose Signatur basierend auf Hashfunktionen).

Speziell für die Signierung von Software und Firmware hat das NIST in der Sonderveröffentlichung 800-208 zwei zustandsbehaftete Verfahren auf Basis von Hashfunktionen, LMS und XMSS, genehmigt . Ihre Sicherheit hängt ausschließlich von der Stärke einer Hashfunktion ab – eine bewusst konservative Annahme – und ihr zustandsbehaftetes Design macht sie gut geeignet für die Signierung einer begrenzten, vorhersehbaren Anzahl von Releases.

Die praktischen Auswirkungen sind real. Die von diesen Algorithmen erzeugten Schlüssel und Signaturen sind deutlich größer als die von ECDSA oder RSA, was sich auf den Firmware-Speicher, die Aktualisierungsbandbreite und die Verifizierungszeit auswirkt, wie der folgende Vergleich zeigt. Zustandsbehaftete Verfahren wie LMS und XMSS erfordern zudem ein sorgfältiges Zustandsmanagement, das auch Systemabstürze übersteht, da die Wiederverwendung eines Einmalschlüssels katastrophale Folgen hat. Daher benötigen sie dedizierte HSM-Unterstützung und einen disziplinierten Betrieb.

Ungefähre Größen von öffentlichem Schlüssel und Signatur in Bytes:

Schema	Öffentlicher Schlüssel	Signature	Sicherheitsstufe
ECDSA P-256 (klassisch)	65	64	~128 Bit
RSA-2048 (klassisch)	256 (Modulgröße)	256	~112 Bit
ML-DSA-65 (FIPS 204)	1,952	3,309	NIST Level 3
SLH-DSA-128f (FIPS 205)	32	17,088	NIST Level 1

Die Größen sind in FIPS 204 und FIPS 205 definiert.

Das kurzfristige Ziel ist nicht ein vollständiger Austausch, sondern die Bestandsaufnahme der im Code fest definierten Signaturalgorithmen, die Bestätigung der HSM- und Tooling-Unterstützung sowie die Entwicklung von austauschbaren oder hybriden Algorithmen. Der Zeitplan CNSA 2.0 der NSA sieht die Signierung von Software und Firmware als ersten Schritt vor. Obwohl er nur für nationale Sicherheitssysteme und deren Zulieferer gilt, werden diese aufgefordert, die neuen Algorithmen bis 2025 zu bevorzugen und bis 2030 ausschließlich zu verwenden, da die Firmware-Vertrauensanker nach der Bereitstellung am schwierigsten zu aktualisieren sind. Eine Feinheit ist in regulierten Umgebungen von Bedeutung.

Für die Signierung von Software und Firmware genehmigt CNSA 2.0 ML-DSA, LMS und XMSS, jedoch nicht SLH-DSA, obwohl auch SLH-DSA auf Hashing basiert. Dessen zustandsloses, hashbasiertes Signaturverfahren bietet zwar eine hohe probabilistische Resistenz, führt aber zu extrem großen Signaturgrößen und Leistungsengpässen.

Beispielhafter Workflow: Vom Build zur verifizierten Bereitstellung

Die vorangegangenen Abschnitte zusammen ergeben, dass eine konforme Freigabe in jedem Softwareentwicklungszyklus (SDLC) demselben allgemeinen Ablauf folgt. Dies ist das Muster, das jedes Team implementieren sollte. Die vollständig ausgearbeitete CI/CD-Version mit OIDC-basierter Dienstidentität, doppelter klassischer/Post-Quanten-Signatur und spezifischen Verifizierungswerkzeugen finden Sie unter „ Stärkung der Lieferkettensicherheit mit SLSA Level 3 und Codesignatur“.

1. Der Build erzeugt ein Artefakt und dessen Inhalts-Hash; die Build-Umgebung speichert niemals einen Signaturschlüssel.
2. Integrität, Herkunft und Sicherheit werden bei dem Artefakt geprüft; nur Artefakte, die diese Prüfungen bestehen, kommen zur Signierung in Frage.
3. Die Pipeline übermittelt den Hash an den zentralen Signaturdienst unter Verwendung eines zeitlich begrenzten, kurzlebigen Berechtigungsnachweises, nicht eines dauerhaften Geheimnisses.
4. Der Signaturdienst prüft RBAC und verlangt für Produktionsversionen die Genehmigung durch den Master of Network (MofN), bevor der Signaturvorgang innerhalb des HSM durchgeführt wird.
5. Die Signatur wird zurückgegeben, dem Artefakt beigefügt und mit einem Zeitstempel versehen (RFC 3161), sodass sie auch nach Ablauf des Zertifikats überprüfbar bleibt.
6. Das Signierungsereignis, der Artefakt-Hash, die Schlüssel-ID, der Genehmiger und der Zeitstempel werden in ein unveränderliches, zentral gespeichertes Protokoll geschrieben.
7. Bei der Verwendung, Bereitstellung, Zugangskontrolle oder beim Hochfahren des Geräts wird eine Überprüfung erzwungen, bevor dem Artefakt vertraut wird; dies wird nicht allein aufgrund des Vorhandenseins einer Signatur angenommen.

Häufige Fehler: Zwei Lehren aus realen Vorfällen

Die meisten Fehlschläge bei der Datenunterzeichnung lassen sich in zwei Kategorien einteilen: Entweder wurde der Schlüssel gestohlen oder die Datenübertragung zum Unterzeichner war manipuliert. Zwei detailliert dokumentierte Vorfälle veranschaulichen die jeweiligen Fälle.

Gestohlene Schlüssel (NVIDIA, 2022). Nachdem die Lapsus$-Gruppe zwei NVIDIA-Codesignaturzertifikate veröffentlicht hatte, nutzten Angreifer diese, um Schadsoftware wie Cobalt-Strike-Beacons und Remote-Access-Trojaner zu signieren. Die Zertifikate waren bereits abgelaufen, dennoch akzeptierte Windows sie weiterhin für die Treibersignatur. Dies verdeutlicht, dass Widerrufs- und Plattformvertrauensrichtlinien genauso wichtig sind wie der Schlüssel selbst.

Eine kompromittierte Build-Pipeline (3CX, 2023). Angreifer drangen in die Build-Umgebung von 3CX ein und infizierten die Desktop-Anwendung mit einem Trojaner. Der manipulierte Build war mit einem gültigen Zertifikat von 3CX signiert, und die macOS-Version war sogar von Apple notariell beglaubigt. Dadurch konnte die kompromittierte Software Vertrauensprüfungen bestehen und potenziell die über 600,000 Kunden von 3CX erreichen. Es wurde kein Schlüssel gestohlen, und die Signatur war echt. Dies ist der deutlichste Beweis dafür, dass eine gültige Signatur die Herkunft, nicht aber die Sicherheit beweist, und zeigt, warum die Build-Pipeline als eines der sensibelsten Systeme geschützt werden muss.

Die zugrundeliegenden Fehlerquellen sind bekannt: Schlüssel werden auf Entwickler-Laptops oder in Build-Skripten gespeichert; Signaturen werden ohne Zeitstempel signiert, sodass sie stillschweigend ablaufen; es fehlt eine Übersicht über vorhandene Schlüssel und Zertifikate sowie deren Ablaufdatum; und Code von Drittanbietern wird ohne Rücksicht auf Verluste signiert. Jede dieser Fehlerquellen vergrößert unmerklich die Kluft zwischen „signiert“ und „vertrauenswürdig“. Die gute Nachricht: Alle diese Fehlerquellen sind vermeidbar, und die folgenden Best Practices zeigen, wie diese Kluft geschlossen werden kann.

Bewährte Methoden zur Code-Signierung

Die nachfolgend beschriebenen Praktiken umfassen: die Generierung und den Schutz von Signaturschlüsseln, die Steuerung und Verifizierung der Signatur sowie die Anpassungsfähigkeit des Systems an sich ändernde Algorithmen. Betrachten Sie diese als Grundlage für die Bewertung Ihrer aktuellen Codesignaturpraktiken und nicht als einmalige Einrichtung.

1. Schlüssel in Hardware, nicht exportierbar. Signaturschlüssel werden innerhalb der HSMs generiert und als nicht exportierbar gekennzeichnet, sodass sie die Hardware niemals verlassen können. Schlüssel werden pro Produktlinie oder Vertrauensdomäne auf HSM-Partitionsebene isoliert, sodass ein Angreifer, der einen Schlüssel kompromittiert, niemals einen anderen signieren kann.
2. Zentralisieren Sie die Signatur hinter einem dedizierten Dienst. Dieser verwaltet die Schlüssel, setzt Richtlinien durch und gibt ausschließlich eine Signatur zurück. Halten Sie private Schlüssel von CI-Runnern, Entwickler-Laptops und Build-Skripten fern – den Pipeline-Komponenten, die am anfälligsten für Abhängigkeits- und Plugin-Kompromittierungen sind.
3. Signieren Sie nur verifizierte Artefakte. Signieren Sie nur Artefakte, die Integritäts-, Herkunfts- und Sicherheitsprüfungen bestanden haben, und fügen Sie maschinenlesbare Herkunftsnachweise wie SLSA- oder In-Toto-Attestierungen hinzu. Das Signieren eines nicht verifizierten Builds überträgt das Vertrauen lediglich auf etwas, das Sie nie validiert haben.
4. Jede Signatur sollte mit einem Zeitstempel versehen werden. Verwenden Sie für jede Signatur einen RFC-3161-konformen, vertrauenswürdigen Zeitstempel, damit die Authentifizierung auch nach Ablauf des Zertifikats weiterhin gewährleistet ist. Ohne Zeitstempel müssten Sie bei jedem Zertifikatsablauf alle bisherigen Versionen erneut signieren, was bei jahrelang ausgelieferten Produkten unpraktisch ist.
5. Überprüfen Sie die Signatur und die Richtlinien direkt bei der Verwendung. Erzwingen Sie die Überprüfung direkt bei der Verwendung, nicht nur während des Build-Prozesses. Dies gilt beispielsweise, wenn ein Kubernetes Admission-Controller nicht vertrauenswürdige Images ablehnt oder ein Bootloader unsignierte Firmware zurückweist. Eine Signatur, die niemand überprüft, bietet keinen Schutz.
6. Funktionstrennung und Genehmigung durch den Master of Network (M-of-N). Anfordern, Genehmigen und Signieren von Vorgängen sollten gemäß rollenbasierter Zugriffskontrolle (RBAC) unterschiedliche Rollen darstellen. Für Produktions- und Freigabeschlüssel ist die Genehmigung durch den Master of Network (M-of-N) (Quorum) erforderlich, sodass keine einzelne Person einen Signiervorgang initiieren und genehmigen kann. Die Zugriffsrichtlinie selbst muss versionskontrolliert und auditierbar sein.
7. Unveränderlicher, detaillierter Prüfpfad. Jedes Signaturereignis wird in einem separaten, nicht anhängbaren Speicher aufgezeichnet, der unabhängig von der Signaturinfrastruktur geführt wird. Erfasst werden der Artefakt-Hash, die Schlüsselkennung, das Zertifikat, die Identität des Genehmigenden und der Zeitstempel. Dies dient sowohl der Erkennung von Sicherheitslücken als auch als Nachweisgrundlage für ISO/IEC 27001, SOC 2, PCI DSS und neuere Standards wie die EU-Richtlinien. Cyber-Resilienz-Gesetz.
8. Schützen Sie Ihre Build-Pipeline. Behandeln Sie die Build- und Signatur-Pipeline wie eines Ihrer sensibelsten Systeme – mit gehärteten Runnern, minimalen Service-Identitäten und manipulationssicherer Protokollierung. Wie der 3CX-Datenskandal gezeigt hat, kann selbst eine gültige Signatur auf einem kompromittierten Build Schadsoftware enthalten.
9. Planen Sie Widerruf und Rotation von Schlüsseln. Dokumentieren, automatisieren und üben Sie, wie Sie einen Schlüssel widerrufen, Plattformanbieter benachrichtigen und einen Ersatz ausstellen, bevor ein Vorfall dies erfordert. Bevorzugen Sie nach Möglichkeit kurzlebige oder ephemere Signaturidentitäten, bei denen das Zertifikat nur kurz gültig ist und der private Schlüssel direkt nach der Signierung verworfen wird, sodass kein Schlüssel mehr vorhanden ist, der rotiert, widerrufen oder gestohlen werden könnte.
10. Schaffen Sie kryptografische Flexibilität. Sorgen Sie für kryptografische Flexibilität im Hinblick auf den Übergang zur Post-Quanten-Ära: Erstellen Sie eine Bestandsaufnahme der im Code fest definierten Signaturalgorithmen (eine CBOM ist hilfreich), bestätigen Sie die Unterstützung von HSM und Tools für ML-DSA (FIPS 204) und die Hash-basierten Verfahren in SP 800-208 und entwickeln Sie Lösungen für austauschbare oder hybride klassische und PQC-Signaturen. Auch heute noch ausgelieferte, langlebige Firmware muss mit Algorithmen kompatibel sein, die zukünftigen Quantencomputern widerstehen. Migrieren Sie daher im Rahmen des CNSA-2.0-Zeitplans und nicht erst unter Zeitdruck.

Fehlerbehandlung und Rollback

Ein Signiervorgang sollte fehlschlagen: Wird die Genehmigung nicht erteilt, ist das HSM nicht erreichbar oder eine erforderliche Prüfung nicht bestanden, wird das Artefakt nicht veröffentlicht, nicht mit einem Fallback-Pfad signiert und trotzdem ausgeliefert. Ein Rollback, wenn sich ein bereits ausgeliefertes Artefakt als problematisch erweist, ist etwas anderes als ein Zertifikatswiderruf, und die beiden werden oft verwechselt. Ein Widerruf macht das Zertifikat für die Zukunft ungültig; er entfernt das bereits im Einsatz befindliche Artefakt nicht. Ein Rollback bedeutet, die letzte bekannte, fehlerfreie signierte Version erneut bereitzustellen und, sofern die Plattform dies unterstützt, einen Rollback-Schutz (einen monotonen Versionszähler) zu verwenden, um sicherzustellen, dass die vorherige, fehlerfreie Version auch nach der Auslieferung einer neueren, kompromittierten Version weiterhin installiert werden kann. Planen Sie beides ein: Ein Zertifikatsproblem erfordert einen Widerruf, eine fehlerhafte Version einen Rollback-Pfad; keines ersetzt das andere.

Problemlösung

Symptom	Wahrscheinliche Ursache	Was zu überprüfen
Die Signatur ist gültig, aber das Artefakt besteht die Vertrauensprüfung der Plattform weiterhin nicht.	Das Zertifikat weist Mängel in der Verwendung des erweiterten Schlüssels auf, oder die Schlüsselkette kann auf dieser Plattform nicht zu einem vertrauenswürdigen Stammzertifikat aufgebaut werden.	Bestätigen Sie die EKU für die Code-Signatur und validieren Sie die vollständige Kette anhand des Truststores der Zielplattform.
Ältere Versionen werden plötzlich als ungültig angezeigt.	Das Signaturzertifikat war abgelaufen und die Unterschriften wurden nicht mit einem Zeitstempel versehen.	Fügen Sie zukünftig die Zeitstempelung gemäß RFC 3161 hinzu; bereits versendete, ungestempelte Signaturen können in der Regel nicht nachträglich korrigiert werden.
Ein bereits widerrufenes Zertifikat scheint bei einigen Clients weiterhin zu funktionieren.	Der Verifizierer prüft nicht den Widerruf (CRL/OCSP) oder speichert einen veralteten Status zwischen.	Prüfen Sie, welche Ihrer Verifizierer die Widerrufsprüfung überhaupt durchführen; gehen Sie nicht davon aus, dass die Widerrufsprüfung allgemein durchgesetzt wird.
Signieranfragen schlagen unter Last zeitweise fehl.	Durchsatzgrenzen von HSM oder Signaturdiensten, insbesondere bei größeren PQC-Signaturen.	Führen Sie einen Lasttest für den Signierdurchsatz unter Ihrem tatsächlichen Algorithmus und Volumen durch, bevor Sie sich in der Hektik des Veröffentlichungstages darauf verlassen.

Manuelle vs. zentrale Unterzeichnung: Ein kurzer Vergleich

Aspekt	Manuelle / Ad-hoc-Unterzeichnung	Zentralisierter Signaturdienst
Schlüsselstandort	Entwickler-Laptop, Build-Skript oder USB-Token	FIPS 140-2 Level 2+ HSM, nicht exportierbar
Die Anerkennung	Wer den Schlüssel hat, kann unterschreiben	RBAC mit M-of-N-Zulassung für Produktionsstufen
Audit-Trail	Inkonsistent oder nicht vorhanden	Unveränderliches Protokoll pro Signierungsereignis
Zeitstempeln	Oft übersprungen	Wird automatisch auf jede Unterschrift angewendet
Widerrufsbereitschaft	Ad hoc, während eines Vorfalls entdeckt	Dokumentierter, eingeübter Prozess

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.

Fazit

Die Beschreibung der Codesignierung ist trügerisch einfach, erfordert aber für eine erfolgreiche Anwendung im großen Maßstab die Expertise von Fachleuten. Die Kryptografie selbst ist der einfache Teil. Die dauerhafte Kontrolle ergibt sich aus dem Schutz der Schlüssel, der Integration der Signatur in den Softwareentwicklungszyklus (SDLC), der Durchsetzung der Verifizierung und der Steuerung und Vorbereitung des gesamten Systems auf zukünftige Entwicklungen. Mit der richtigen Architektur – Schlüssel in Hardware gespeichert, ein zentralisierter Signaturdienst, obligatorische Zeitstempelung, erzwungene Verifizierung, starke Governance und ein Fahrplan für kryptografische Flexibilität – wird eine Signatur zu einem vertrauenswürdigen Versprechen und nicht zu einer Schwachstelle, die gestohlen oder gefälscht werden kann.

Wenn Ihre Organisation überdenkt, wie sie Software über den gesamten Lebenszyklus hinweg signiert und schützt, lohnt es sich, zu überprüfen, wo Ihre aktuellen Praktiken im Vergleich zu diesen Benchmarks stehen und zu entscheiden, wo Sie sie als Nächstes verbessern können.

Häufig gestellte Fragen

Worin besteht der Unterschied zwischen Widerruf und Rollback?

Der Widerruf macht ein Zertifikat für die Zukunft ungültig; bereits ausgelieferte Artefakte werden dadurch nicht entfernt. Ein Rollback bedeutet die erneute Bereitstellung der letzten als gültig bekannten signierten Version. Bei einer Zertifikatskompromittierung ist ein Widerruf erforderlich; bei einer fehlerhaften Version ist ein Rollback notwendig. Die beiden Verfahren lösen unterschiedliche Probleme und ersetzen sich nicht gegenseitig.

Spielt der Zeitstempel eine Rolle, wenn mein Zertifikat jetzt nur noch 460 Tage gültig ist?

Es ist wichtiger, nicht weniger wichtig. Eine kürzere Zertifikatsgültigkeit bedeutet, dass Artefakte eher überprüft werden, nachdem ihr ursprüngliches Signaturzertifikat abgelaufen ist. Ein gemäß RFC 3161 vertrauenswürdiger Zeitstempel gewährleistet die Verifizierbarkeit der Signatur in jedem Fall.

Ist eine gültige Codesignatur ein Beweis dafür, dass ein Artefakt sicher ist?

Nein. Eine Signatur beweist Herkunft und Integrität seit der Unterzeichnung, nicht aber Sicherheit. Der 3CX-Vorfall ist das deutlichste Beispiel: Eine Build-Pipeline wurde kompromittiert, und die daraus resultierende Malware wurde mit einem gültigen Zertifikat von 3CX signiert und sogar von Apple beglaubigt.

Wo finde ich eine detaillierte Anleitung zur CI/CD-Implementierung, nicht nur eine Checkliste?

Die vollständige Architektur – OIDC-basierte Dienstidentität, duale klassische/Post-Quanten-Signatur und spezifische Verifizierungswerkzeuge – finden Sie unter Strengthening Supply Chain Security with SLSA Level 3 and Code Signing .

Ersetzen kurzlebige Signaturidentitäten die Notwendigkeit eines HSM?

Nein. Eine kurzlebige Signaturidentität begrenzt die Gültigkeitsdauer eines Anmeldeinformationszertifikats; die Operation mit dem privaten Schlüssel selbst muss weiterhin innerhalb eines nicht exportierbaren, hardwaregeschützten Moduls erfolgen, um die Anforderungen des CA/Browser Forums zu erfüllen und Schlüsseldiebstahl zu verhindern.