Best Practices für die Codesignierung im Softwareentwicklungszyklus

Moderne Software wird zusammengestellt, nicht geschrieben. Eine einzelne Version bindet Pakete aus Open-Source-Quellen, Container-basierte 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 Daten tatsächlich von Ihrem Unternehmen stammen. Codesignierung ist die Praxis, einem Software-Artefakt eine kryptografische digitale Signatur hinzuzufügen, sodass jeder überprüfen kann, wer es erstellt hat und ob es 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 einem Angriff standhält.

Es geht nicht um theoretische Aspekte. Gartner prognostizierten, dass bis 2025 weltweit 45 % der Unternehmen einen Angriff auf ihre Software-Lieferkette erleben würden, eine Verdreifachung gegenüber 2021.

Im Gegenteil, diese Prognose erwies sich als konservativ. Verizon 2025 Untersuchungsbericht zu Datenschutzverletzungen Die Studie ergab, dass Dritte an rund 30 % der Verstöße beteiligt waren, etwa doppelt so viele wie ein Jahr zuvor.

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.

Wie Codesignierung funktioniert: Die kryptografische Vertrauenskette

Im Kern, Codesignatur Verknüpft ein Artefakt mithilfe asymmetrischer Kryptografie mit der Identität eines Herausgebers. Das Signaturtool 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 Unterschrift steht nicht für sich allein. Sie ist Teil der Identität des Unterzeichners. X.509-Zertifikat und die 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 mittels CRL oder OCSP.

One point deserves emphasis, because it is the root of the most damaging incidents: a valid signature proves where an artifact came from, not that the artifact is safe. If an attacker steals the private key or compromises the build pipeline that feeds the signer, the signature will faithfully certify malware. Code signing assures authenticity and integrity, and it is only as trustworthy as the key and the pipeline behind it.

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.

Build-Prozesse und Signaturprozesse trennen. 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 des Systems, der… Pipeline am stärksten von Abhängigkeiten und Kompromissen bei Plugins betroffen.

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 entwickelt. Lieferkette Frameworks wie SLSA definieren Herkunftsnachweisebenen, In-toto-Attestierungen erfassen überprüfbare Metadaten zur 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 Verfahren ergänzen die Signierung veröffentlichter Binärdateien mit Zertifikaten, anstatt sie zu ersetzen. Sie alle basieren jedoch 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 bedeutendste operative Änderung im Bereich der öffentlich vertrauenswürdigen Codesignierung trat am 1. Juni 2023 in Kraft. Gemäß den Richtlinien des CA/Browser-Forums Grundvoraussetzungen für die CodesignierungPrivate Schlüssel für sowohl Organisationsvalidierungs- (OV) als auch erweiterte Validierungs- (EV) Code-Signaturzertifikate müssen nun generiert und in einem Hardware-Kryptomodul gespeichert werden, das mindestens nach FIPS 140-2 Level 2 oder Common Criteria EAL 4+ zertifiziert ist. Der Schlüssel muss 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. Protokollieren Sie jedes Signaturereignis zentral: Wer hat welches Artefakt mit welchem ​​Schlüssel wann signiert? Dies dient sowohl der Erkennung als auch als Nachweisgrundlage für ISO/IEC 27001. SOC 2 und PCI DSS Prüfungen.

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.

In August 2024Das NIST hat seine ersten Standards zur Abwehr von Quantencomputern finalisiert: FIPS204 (ML-DSA, eine Signatur basierend auf Gitterkryptographie) und FIPS205 (SLH-DSA, eine zustandslose Signatur basierend auf Hashfunktionen).

Speziell für die Signierung von Software und Firmware hat das NIST außerdem zwei zustandsbehaftete Verfahren auf Basis von Hash-Funktionen genehmigt: LMS und XMSS. Sonderpublikation 800-208Ihre Sicherheit hängt ausschließlich von der Stärke einer Hash-Funktion ab, einer bewusst konservativen Annahme, und ihr zustandsbehaftetes Design macht sie gut geeignet, eine begrenzte, vorhersehbare Anzahl von Releases zu signieren.

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. Die NSA CNSA 2.0 Der Zeitplan sieht die Signierung von Software und Firmware als frühesten Übergang vor. Obwohl er nur nationale Sicherheitssysteme und deren Zulieferer bindet, werden diese aufgefordert, die neuen Algorithmen bis 2025 zu bevorzugen und ab 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 Design mit wenigen Signaturen bietet zwar eine hohe probabilistische Resistenz, führt aber zu extrem großen Signaturgrößen und Leistungsengpässen.

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

Die meisten Signierfehler lassen sich in zwei Kategorien einteilen: Entweder wurde der Schlüssel gestohlen oder die Datenübertragung zum Signierer war kompromittiert. Zwei gründlich dokumentierte Fälle Zwischenfälle jeweils veranschaulichen.

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.

Wie Verschlüsselungsberatung helfen kann

CodeSign Secure ist die Enterprise-Class-Codesignatur-Management-Plattform von Encryption Consulting, die entwickelt wurde, um die von 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

Jede Signierstunde in CodeSign Secure Es wird ein unveränderlicher Logeintrag erzeugt, der den Artefakt-Hash, die Schlüsselkennung, das verwendete Zertifikat, die genehmigende Identität und den RFC-3161-Zeitstempel erfasst. Die Logs 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 integriert sich mit Azure-DevOps, Jenkins, GitLab-CIund anderen wichtigen Pipeline-Plattformen über API- und Befehlszeilenschnittstellen. Die Firmware-Signierung 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.