Wir haben jedes Format gezählt, das CodeSign Secure signieren kann.

Fragt man einen Release-Ingenieur, wie viele Signaturtools sein Unternehmen verwendet, hält er inne und zählt an den Fingern ab. Signtool für den Windows-Installer. Jarsigner für den einen Java-Dienst, den niemand anfassen will. Was auch immer das Mobile-Team für APKs eingerichtet hat. Ein GPG-Schlüssel, den jemand vor drei Entwicklern für das Debian-Repository erstellt hat, und niemand weiß genau, wer ihn noch besitzt. Das ist keine bloße Annahme. Das ist der durchschnittliche Umfang an Signaturen in Unternehmen, die seit mehr als zwei Jahren Software auf mehreren Plattformen veröffentlichen. Und genau deshalb taucht die Codesignatur immer wieder in der Nachbesprechung von Sicherheitsvorfällen auf, die nichts mit dem Code selbst zu tun haben.

Und hier kommt der Grund, warum das jetzt dringlich ist und nicht erst „irgendwann“ ansteht: Die Abstimmung CSC-31 des CA/Browser Forums hat die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger Code-Signaturzertifikate von 39 Monaten auf 460 Tage verkürzt – gültig ab dem 1. März 2026. Jeder verstreute Signaturschlüssel einer Organisation, jeder USB-Stick in der Schublade, jedes Zertifikat, an dessen Ausstellung sich niemand mehr erinnert, muss nun etwa dreimal so häufig überprüft werden wie noch vor 18 Monaten. Fragmentierte Signaturen waren schon vor dieser Abstimmung problematisch. Jetzt stellen sie ein operatives Risiko dar.

Wir möchten daher die Frage beantworten, die uns in fast jedem Evaluierungsgespräch für CodeSign Secure, einer Enterprise-Codesignaturlösung, gestellt wird: „Okay, aber deckt es tatsächlich unseren gesamten Stack ab?“ Nachfolgend finden Sie die ehrliche und konkrete Antwort, Format für Format, mit genügend technischen Details, damit Sie es anhand Ihrer eigenen Release-Pipeline überprüfen können, anstatt sich einfach auf unsere Aussage zu verlassen.

Eine Enterprise-Codesignierungslösung, definiert als: eine zentrale Plattform, die private Signaturschlüssel in HSM-gestützter Hardware generiert und speichert, eine rollenbasierte Genehmigung durch mehrere Genehmiger für jede Signaturanforderung erzwingt und gültige Signaturen für jedes Format erzeugt, das ein Unternehmen ausliefert, anstatt jedes Team mit seinen eigenen lokalen Schlüsseln und Tools signieren zu lassen.

Wichtige Erkenntnisse

• CodeSign Secure signiert über 20 Formate, Windows, Apple, Java/Android, Linux, Cloud-native, PKCS#11-wrapped und Post-Quantum, von einer einzigen FIPS 140-2 Level 3 HSM-gestützten Plattform aus.
• Für jede Signieranfrage gilt unabhängig vom Format ein einheitliches RBAC-Modell und ein einheitlicher M-of-N-Genehmigungsworkflow.
• Die Abstimmung im CA/Browser Forum CSC-31 verkürzte die Gültigkeitsdauer von öffentlichen Code-Signaturzertifikaten von 39 Monaten auf 460 Tage, gültig ab dem 1. März 2026. Dadurch verdreifacht sich die Häufigkeit, mit der verstreute Signaturschlüssel neu ausgestellt werden müssen.
• CodeSign Secure unterstützt neben der klassischen RSA/ECDSA-Signatur auch detachable Post-Quantum-Signaturen (ML-DSA, LMS) auf demselben Artefakt, sodass die Einführung von PQC additiv und keine Migration vom Typ „Rip-and-Replace“ ist.
• Zu den Bereitstellungsoptionen gehören lokale, Cloud- und hybride HSM-Modelle; lesen Sie vor der Bewertung die Abschnitte Voraussetzungen und Bekannte Einschränkungen weiter unten.

Die kurze Version

CodeSign Secure signiert über 20 verschiedene Formate mit einer einzigen HSM-basierten Plattform: Windows-Binärdateien und -Skripte (Signtool, JSign, PowerShell, Appx/MSIX, ClickOnce via Mage, NuGet, HLK/HCK-Treibersignatur), Apple-Binärdateien, Java- und Android-Artefakte (jarsigner, JSign, APK), Linux- und Open-Source-Pakete (OpenSSL, XML, GPG2, Debian, RPM), Cloud-native Artefakte (Container, OVA/OVF, Firmware), reproduzierbare Builds, PKCS#11-basierte HSM-Signaturen und detachable Post-Quantum-Signaturen (ML-DSA, LMS). Ein rollenbasiertes Zugriffskontrollmodell (RBAC) und ein M-of-N-Genehmigungsworkflow steuern all dies. Letzteres ist der entscheidende Punkt, nicht die Anzahl der Formate. Eine Plattform, die zwanzig Formate über zwanzig verschiedene Vertrauensgrenzen signiert, löst das Fragmentierungsproblem nicht; sie erweitert lediglich den Funktionsumfang.

Möchten Sie die vollständige Karte vor den Details sehen? Hier ist sie.

Kategorie	Abgedeckte Formate/Tools	Dateierweiterungen
Windows	Signtool (Authenticode), JSign, PowerShell-Skripte, Appx/MSIX-Pakete, ClickOnce-Manifeste (Mage/Mage UI), NuGet-Pakete, HLK/HCK-zertifizierte Treiber	.exe, .dll, .sys, .msi, .cab, .ps1, .appx/.msix, .application, .nupkg
Apple	macOS-, iOS- und watchOS-Anwendungen	.app, .ipa
Java & Android	JAR-Dateien (jarsigner), plattformübergreifende Authentifizierung über JSign, APK-Pakete	.jar, .apk
Linux & Open Source	OpenSSL-basierte Signierung, digitale XML-Signaturen, GPG2, Debian-Pakete, RPM-Pakete	.rpm, .deb, .xml, .asc/.sig
Cloud-native und Infrastruktur	Container-/OCI-Images, OVA-/OVF-Virtualisierungsdateien, Firmware-Images	N/A (Inhaltszusammenfassung), .ova/.ovf, Firmware-Binärdateien
Integrität der Lieferkette	Reproduzierbare Builds	Nicht zutreffend (Build-Attestierung, kein einzelner Dateityp)
Post-Quantum	PQC-abtrennbare Signaturen (ML-DSA, LMS)	.sig (abgetrennt)
Hardware-Interoperabilität	PKCS#11-Wrapper-Signierung für Drittanbieter- und Legacy-Tools	Nicht zutreffend (Protokollebene, nicht dateispezifisch)

Nun wollen wir uns ansehen, was sich tatsächlich hinter jeder Zeile verbirgt, denn „Wir unterstützen X“ bedeutet nichts ohne die dazugehörige Begründung „Warum es wichtig ist“.

Windows: Hier entstehen die meisten Signaturprogramme, und hier scheitern die meisten von ihnen.

Wenn Ihre Organisation Dokumente signiert, begann dies höchstwahrscheinlich mit Windows – und hier beginnt meist auch die zunehmende Komplexität. Microsofts signtool.exe ist das Referenztool für die Authenticode-Signatur, das Verfahren, mit dem Windows PE-Dateien (.exe, .dll, .sys, .msi, .cab und Katalogdateien) als vertrauenswürdig einstuft. Der Haken: Signtool läuft nur unter Windows. Sobald Ihre Build-Pipeline einen Linux-Container oder eine gemischte CI/CD-Umgebung umfasst, ist dies nicht mehr nur eine kleine Unannehmlichkeit, sondern der Grund, warum jemand eine einzelne Windows-VM nur zum Signieren von Dokumenten betreibt. JSign, ein in Java geschriebenes Open-Source- und plattformübergreifendes Authenticode-Tool, wurde speziell entwickelt, um diese Lücke zu schließen. CodeSign Secure nutzt es als eine seiner Signatur-Engines, sodass Build-Agents für Linux und macOS gültige Authenticode-Signaturen erstellen können, ohne jemals eine VM starten zu müssen. Der private Schlüssel verbleibt dabei stets in einem FIPS 140-2 Level 3 HSM, unabhängig davon, ob die Anfrage über Signtool oder JSign eingeht.

PowerShell-Skripte werden genauso behandelt. Wenn Ihre Ausführungsrichtlinie eine gültige Authenticode-Signatur für jede .ps1-Datei erfordert (was sie unbedingt tun sollte), signiert CodeSign Secure diese Skripte über das HSM und ermöglicht deren Überprüfung mit einem einfachen Get-AuthenticodeSignature-Aufruf. Dabei gelangt kein Signaturschlüssel auf den Rechner, auf dem das Skript ausgeführt wird.

Dann gibt es noch die Paketierungsebene, auf der sich die meisten Windows-Signaturkonfigurationen stillschweigend in drei oder vier separate Arbeitsabläufe aufteilen: Appx- und MSIX-Pakete, die Windows ohne Zertifikatskette zu einer vertrauenswürdigen Stammzertifizierungsstelle nicht installiert, unabhängig davon, ob die Pakete über den Microsoft Store bereitgestellt oder manuell installiert werden; ClickOnce, das selbstaktualisierende .NET-Bereitstellungsmodell, dessen Vertrauen auf signierten Manifesten basiert, die mit Microsofts Mage- und Mage UI-Tools generiert wurden (und deren Signaturschlüssel häufig im lokalen Zertifikatsspeicher des Entwicklers landen, anstatt für das Sicherheitsteam zugänglich zu sein); und NuGet-Pakete, die seit NuGet 4.6 die Authenticode-basierte Signierung unterstützen und idealerweise einen vertrauenswürdigen Zeitstempel tragen sollten, damit die Signatur länger gültig ist als das Zertifikat. CodeSign Secure behandelt alle drei Pakete genauso wie die Binärdatei selbst: ein HSM, ein Audit-Trail, keine Ausnahmen für „es ist ja nur ein Manifest“.

Und dann gibt es da noch das Format, das Hardwareherstellern insgeheim Sorgen bereitet: die HLK/HCK-Treibersignatur. Um einen Treiber über das Windows Hardware Lab Kit (den Nachfolger des älteren Hardware Certification Kit) zertifizieren zu lassen, müssen signierte Pakete an Microsofts Windows Hardware Dev Center übermittelt werden. Kernelmodustreiber unter 64-Bit-Windows lassen sich ohne eine Signatur, die Microsofts aktuellen Anforderungen an EV- oder hardwaregestützte Schlüssel entspricht, schlichtweg nicht laden. Eine aufgrund einer formalen Signierungsfrage abgelehnte HLK-Einreichung kostet ein Hardware-Team wertvolle Zeit. CodeSign Secure unterstützt die Signierung gemäß diesen Anforderungen direkt. Genau das macht den Unterschied zwischen einer Einreichung, die die Prüfung besteht, und einer, die mit einer unerfreulichen Fehlermeldung zurückkommt.

Apple: Ein Ökosystem, ein strengeres Regelwerk

Apple ist in dieser Hinsicht deutlich strenger als Windows. Codesign und Gatekeeper setzen voraus, dass jede macOS-, iOS- und watchOS-Binärdatei eine Signatur eines Apple-Entwicklerzertifikats trägt. macOS fügt zusätzlich eine Notarisierung hinzu, bevor Gatekeeper den Benutzer die App ohne Warnmeldung öffnen lässt. Der häufigste Fehler liegt hier nicht in einer fehlenden Signatur, sondern in einer Apple-Entwickler-ID, die sich im Schlüsselbund eines einzelnen Entwicklers befindet, anstatt an einem zentralen Ort, wo sie vom Team rotiert oder widerrufen werden kann. CodeSign Secure signiert macOS-, iOS- und watchOS-Apps gemäß dem Standard-Apple-Verfahren und speichert diese Zertifikate im selben HSM-gesicherten Tresor wie alle anderen Plattformschlüssel. Dadurch wird der Inhaber des Apple-Signaturzertifikats nicht mehr als Single Point of Failure an einen einzelnen Laptop gebunden.

Java und Android: Der Stack, von dem jeder annimmt, dass ihn jemand anderes signiert

Jedes Unternehmen betreibt mindestens einen internen Java-Dienst, der seit Generationen unauffällig im Hintergrund läuft – schon seit einer JVM-Ära, an die sich das aktuelle Team kaum noch erinnert. jarsigner, das mit dem JDK ausgeliefert wird, signiert die JAR-Dateien, von denen diese Dienste abhängen. So kann eine JVM (oder ein Benutzer) bestätigen, dass das Archiv nicht manipuliert wurde und, falls im Manifest angegeben, wer es tatsächlich veröffentlicht hat. CodeSign Secure signiert JAR-Dateien über seinen üblichen zentralisierten Prozess. Dies ist vor allem deshalb wichtig, weil JAR-Signaturschlüssel genau die Art von Anmeldeinformationen sind, die einmalig erstellt, vergessen und nie aktualisiert werden. Auch JSign kommt hier wieder zum Einsatz und ermöglicht es Linux- und macOS-basierten CI/CD- Systemen, Signaturen im Windows-Format anzufordern, ohne dass ein dedizierter Windows-Signaturhost speziell für diese eine Pipeline-Stufe benötigt wird.

Android ist eine Sondergeschichte. Jede APK muss vor der Installation signiert werden, und das Verfahren hat sich viermal weiterentwickelt: v1 (direkt von der JAR-Signatur von Java übernommen), v2 und v3 (Signaturverfahren für ganze Dateien, die Android in den Versionen 7.0 und 9 speziell einführte, um die Lücken von v1 zu schließen und die Signatur an den exakten APK-Inhalt anstatt nur an das Manifest zu binden) und v4 (ein Streaming-Verfahren, das zusammen mit v2/v3 für inkrementelle App-Updates verwendet wird). CodeSign Secure signiert alle diese Formate mit APKSigner, das über seinen PKCS#11- Wrapper auf Build-Agents für Linux, Windows und macOS gleichermaßen geleitet wird. So erfüllt eine mobile Version die aktuellen Google Play-Anforderungen, ohne dass ein separates, unkontrolliertes mobiles Signaturtool außerhalb des restlichen Systems benötigt wird.

Linux und Open Source: Das Ökosystem mit den meisten Signaturkonventionen, nicht das mit den wenigsten

Wer behauptet, Linux-Signaturen seien „einfach nur GPG“, hat sich nicht mit RPM, Debian und der Repository-Signatur als drei grundverschiedenen Konventionen auseinandergesetzt. RPM-basierte Distributionen signieren mit `rpm --addsign` (oder `rpmsign`), wobei ein GPG-Schlüssel direkt in den Paketkopf eingebettet wird. Debian-basierte Pakete werden mit Tools wie `dpkg-sig` oder während des Build-Prozesses mit `debsign` signiert. Die Metadaten eines APT-Repositorys, die Release-Datei selbst, werden separat signiert, damit ein Paketmanager einem gesamten Repository vertrauen kann, anstatt die Pakete einzeln zu überprüfen. Drei Konventionen bedeuten üblicherweise drei GPG-Schlüsselringe, die über die Build-Infrastruktur verteilt sind und jeweils eigene Berechtigungen haben. CodeSign Secure zentralisiert alle drei unter einer einzigen Schlüsselverwaltungsebene.

Zwei weitere Linux-nahe Formate runden das Angebot ab. OpenSSL-Signaturen decken Fälle ab, die Paketierungstools nicht abdecken: Roh-Hashes, benutzerdefinierte Datenstrukturen und beliebige Dateien, die eine separate Signatur benötigen und keinem Standard-Paketformat entsprechen. CodeSign Secure unterstützt OpenSSL-basierte Signaturen (dgst -sign und CMS-Workflows), sodass diese Artefakte nicht auf die Option „jemand mit einer verfügbaren lokalen Schlüsseldatei“ zurückgreifen müssen. Und digitale XML-Signaturen, das W3C-standardisierte XML-DSig-Format, das SAML-Assertions, SOAP-Nachrichten und einem Großteil des regulierten Dokumentenaustauschs zugrunde liegt, werden gemäß derselben Spezifikation signiert, wenn dies aufgrund von Compliance- oder B2B-Integrationsanforderungen explizit gefordert wird.

Cloud-Native und Infrastruktur: Wo Signaturstrategien am jüngsten sind und am ehesten übersprungen werden

Dies ist eine Kategorie, für die die meisten älteren Signaturtools nie konzipiert wurden, und das merkt man.

Die Signierung von Container-Images fügt einem Image eine kryptografische Signatur hinzu, sodass jeder, der es herunterlädt, überprüfen kann, wer es veröffentlicht hat und ob es verändert wurde. Im Wesentlichen haben sich zwei Ansätze etabliert: Sigstores Cosign, das selbstverwaltete Schlüssel (auch HSM-basierte) oder schlüsselloses Signieren mittels kurzlebiger Zertifikate und eines transparenten öffentlichen Protokolls unterstützt, und Notation, basierend auf der CNCF Notary v2-Spezifikation, das PKI-basierte Vertrauensrichtlinien verwendet und von Microsoft AKS und Amazon EKS für Enterprise-Kubernetes empfohlen wird. Beide Ansätze binden die Signatur an den Content Digest des Images anstatt an ein veränderliches Tag. Genau deshalb ist Manipulation überhaupt erst erkennbar. CodeSign Secure signiert gemäß diesen aktuellen Standards, nicht gemäß dem Docker Content Trust-Modell, das Docker selbst für offizielle Images bereits als veraltet markiert hat.

Die OVA- und OVF- Signierung erfüllt denselben Zweck für virtuelle Maschinen-Appliances, die Standard-Paketformate von VMware und der umfassenderen offenen Virtualisierungsspezifikation der Distributed Management Task Force, sodass ein Team die Integrität einer VM-Appliance überprüfen kann, bevor sie auch nur in die Nähe der Produktion kommt.

Die Signierung von Firmware ist von größter Bedeutung, da Firmware unterhalb des Betriebssystems liegt. Ein manipuliertes Firmware-Image übersteht eine Neuinstallation des Betriebssystems und umgeht die meisten Endpoint-Sicherheitstools. Signierte Firmware, geprüft anhand einer sicheren Bootkette, verhindert von vornherein das Laden eines veränderten Images. Genau diese Art von langlebigem, hochwirksamem Schlüssel sollte niemals in einem Build-Skript oder einem lokalen Tool eines Herstellers enthalten sein. CodeSign Secure signiert Firmware mit demselben HSM wie alle anderen Komponenten dieser Liste – ohne Ausnahme.

Reproduzierbare Builds: Nachweis, dass die Binärdatei tatsächlich mit dem Quellcode übereinstimmt

Ein reproduzierbarer Build bedeutet, dass die Kompilierung desselben Quellcodes mit denselben Anweisungen bitgenau die gleiche Binärdatei erzeugt, unabhängig davon, wer sie erstellt oder wann. Diese Eigenschaft ermöglicht es externen Personen, eine Version unabhängig nachzubauen und zu bestätigen, dass die ausgelieferte Version der veröffentlichten Version entspricht. Dies ist derzeit einer der stärksten Schutzmechanismen gegen eine manipulierte Build-Pipeline. CodeSign Secure unterstützt Signatur-Workflows, die auf reproduzierbaren Build-Praktiken basieren. Die Signatur eines Release-Artefakts ist somit an einen überprüfbaren Build-Prozess gebunden und nicht einfach nur der Aussage des Anbieters zu vertrauen. Wie dies mit der umfassenderen Lieferketten-Attestierung zusammenhängt, erfahren Sie unter „ Stärkung der Lieferkettensicherheit mit SLSA Level 3 und Codesignatur“.

Verpflichtung nach Quantum: Diejenige, an die die meisten Teams noch nicht denken

Eine unangenehme Tatsache: Jede RSA- und ECDSA-Signatur, die heute für die Codesignierung verwendet wird, ist genau die Art von Signatur, die ein ausreichend leistungsfähiger Quantencomputer knacken könnte. Das NIST hat dies nicht nur theoretisch betrachtet. FIPS 204 (ML-DSA, der Modulgitterbasierte digitale Signaturstandard) und FIPS 205 (SLH-DSA, der zustandslose Hash-basierte digitale Signaturstandard) wurden im August 2024 zusammen mit den zustandsbehafteten Hash-basierten Verfahren LMS und XMSS gemäß NIST SP 800-208 finalisiert. CodeSign Secure unterstützt die abtrennbare PQC-Signatur mit ML-DSA und LMS. Das bedeutet, dass eine Post-Quanten-Signatur neben oder anstelle einer klassischen RSA/ECDSA-Signatur auf demselben Dokument verwendet werden kann. Niemand muss sein bestehendes Signaturverfahren dafür ändern. Genau darin liegt der Vorteil von „abtrennbar“: Krypto-Agilität, die Sie bereits heute in Ihre Pipeline integrieren können, anstatt erst später in einer hektischen Situation. Hier schließt sich der Kreis zu einer größeren Frage, die die meisten Teams noch nicht beantwortet haben: Welche Signaturalgorithmen werden in ihrer Umgebung überhaupt verwendet? Das ist eher eine Frage der CBOM Secure als der Codesignatur, aber beide Bereiche gehen vom selben Ausgangspunkt aus.

PKCS#11: Sicherstellen, dass veraltete Tools nicht zur Ausrede werden

Viele bestehende Signaturwerkzeuge, insbesondere ältere Versionen, wurden direkt für PKCS#11 entwickelt, die Standard-Kryptografie-API, die die meisten HSMs und Smart Tokens bereitstellen. Anstatt die Notwendigkeit zu verschärfen, jedes dieser Werkzeuge einzeln zu ersetzen, positioniert sich CodeSign Secure als PKCS#11-Anbieter. Dadurch funktionieren bestehende Skripte und Drittanbieter-Tools, die direkten Hardwarezugriff benötigen, weiterhin wie gewohnt. Der Unterschied liegt in den internen Abläufen: Jeder Signaturvorgang durchläuft nach wie vor die zentrale Richtlinien-, Protokollierungs- und Genehmigungsschicht von CodeSign Secure, anstatt unkontrolliert mit der Hardware zu kommunizieren.

In der Praxis dient der PKCS#11-Wrapper als Grundlage für die Signatur-Engines von CodeSign Secure und läuft auf allen wichtigen Build-Plattformen:

• APK-Signierung – Linux, Windows und macOS
• OpenSSL-basierte Signierung – Linux und Windows
• Digitale XML-Signaturen – Linux und macOS
• JSign-basierte Signatur – Linux, Windows und macOS
• Jarsigner (JAR-Signierung) – Linux, Windows und macOS
• GPG2-, Debian- und RPM-Paketsignierung – Linux

Wie CodeSign Secure architektonisch aufgebaut ist

Lässt man die oben genannten formatspezifischen Details außer Acht, ist die Architektur für alle Formate gleich: ein Hardware-Root of Trust, eine Reihe von Signatur-Engines, die die nativen Tools jedes Formats beherrschen, und eine Richtlinienschicht, die jede Anfrage durchlaufen muss, bevor eine Schlüsseloperation durchgeführt werden kann.

• Hardwarebasierte Vertrauensbasis: Private Schlüssel werden in einem FIPS 140-2 Level 3 HSM generiert und gespeichert, das lokal, in der Cloud oder als Hybrid aus beidem eingesetzt wird, sodass das Schlüsselmaterial selbst unabhängig vom Format niemals validierte Hardware verlässt.
• Formatspezifische Signatur-Engines: Signtool und JSign für Authenticode, jarsigner und APKSigner für Java/Android, codesign für Apple und Cosign/Notation-konforme Signierung für Container, die jeweils auf das HSM zugreifen, anstatt eine lokale Schlüsselkopie zu halten.
• PKCS#11 Interoperabilitätsschicht: Eine PKCS#11-Provider-Schnittstelle ermöglicht es, dass bestehende Skripte und Drittanbieter-Tools, die einen direkten Hardwarezugriff erwarten, weiterhin unverändert funktionieren, während jeder Anruf weiterhin über die darunter liegende Richtlinienschicht geleitet wird.
• Zentralisierte Richtlinien- und Genehmigungsebene: RBAC- und M-of-N-Multi-Approver-Workflows sind vor jeder Signatur-Engine angeordnet, sodass eine kompromittierte Build-Berechtigung allein keine vertrauenswürdige Signatur erzeugen kann.
• Integrationspunkte: CI/CD-Pipeline-Plugins, eine API/CLI und die oben genannte PKCS#11-Schnittstelle decken die typischen Methoden ab, mit denen Build-Systeme eine Signatur anfordern. Bevor Sie eine Architektur endgültig festlegen, überprüfen Sie anhand der aktuellen Bereitstellungsdokumentation von CodeSign Secure, welche CI/CD-Plattformen und Betriebssystemversionen für Ihre Umgebung genau unterstützt werden.

Sicherheitskontrollen hinter jeder Unterschrift

Die Formatliste ist weniger wichtig als das, was darunter geschieht. Jedes Signierereignis, unabhängig davon, welches der über 20 oben genannten Formate es auslöst, durchläuft dieselben Kontrollmechanismen:

• Schlüsselverwahrung: Private Schlüssel werden in einem FIPS 140-2 Level 3 HSM generiert und verbleiben dort; die Signatur-Engine des jeweiligen Formats erhält keine lokale Kopie des Schlüssels.
• Rollenbasierte Zugriffskontrolle: Wer eine Signatur anfordern kann, in welchem ​​Format und unter welchem ​​Zertifikat, wird pro Rolle und nicht pro individueller Berechtigung definiert.
• M-of-N-Zulassung: Bei Signierungsvorgängen mit höherem Risiko (z. B. die Einreichung eines neuen HLK-Treibers, eines Firmware-Images oder eines Produktionscontainers) kann die Genehmigung durch ein definiertes Quorum von Genehmigern anstelle der Zustimmung eines einzelnen Entwicklers erforderlich sein.
• Zentralisierter, unveränderlicher Prüfpfad: Jedes Signierereignis in jedem Format landet in einem einzigen Protokoll, die Kontrolle über die am stärksten fragmentierten Signierkonfigurationen fehlt vollständig, anstatt eines Protokolls pro Tool (oder gar keinem Protokoll).

Was Sie vor der Bereitstellung einer Enterprise-Codesignierungslösung benötigen

Nichts davon funktioniert ohne einige vorherige Voraussetzungen. Bevor Sie eine zentrale Signaturplattform evaluieren oder implementieren, vergewissern Sie sich, dass Sie Folgendes haben:

• Ein HSM, das FIPS 140-2 Level 3 erfüllt (lokal, in der Cloud oder über HSM-as-a-Service, falls Sie noch keins betreiben).
• Erstellen Sie Agenten oder CI/CD-Runner für jede Plattform, für die Sie signieren (Windows, Linux, macOS), die die API, das CI/CD-Plugin oder die PKCS#11-Schnittstelle der Signierungsplattform erreichen können.
• Die Zertifikate werden von einer für den jeweiligen Anwendungsfall geeigneten Zertifizierungsstelle ausgestellt: eine öffentlich vertrauenswürdige Zertifizierungsstelle für Authenticode und Apple Developer Signing sowie, sofern die Richtlinien dies zulassen, eine interne Zertifizierungsstelle für interne Java-, XML- oder Paket-Repository-Signaturen.
• Eine Identitätsquelle (vorhandenes Verzeichnis oder IdP), um benannte Genehmiger in den RBAC- und M-of-N-Genehmigungsworkflow einzuordnen.
• Speziell für die Signierung von Containern wird eine Registry benötigt, die die OCI-Signaturanhängung unterstützt, sodass Signaturen im Cosign- oder Notation-Stil an den Image-Digest gebunden werden können.

Die genauen unterstützten Betriebssystemversionen, CI/CD-Plattformen und Netzwerkanforderungen variieren je nach Bereitstellungsmodell; überprüfen Sie die aktuelle Liste anhand der Bereitstellungsdokumentation von CodeSign Secure oder bei Ihrem Ansprechpartner für die Evaluierung, anstatt sich allein auf diesen Beitrag zu verlassen.

Bekannte Einschränkungen

Eine ehrliche Berichterstattung umfasst nicht nur, was die Zentralisierung der Vertragsunterzeichnung bewirkt, sondern auch, was sie nicht bewirkt:

• Die Zentralisierung des Schlüssels beseitigt nicht die Notwendigkeit plattformspezifischer Tools zur Vorbereitung des Artefakts. Die Toolchain von Xcode für die Apple-Notarisierung, die Packaging-Tools des Windows Hardware Lab Kits für die Treiberzertifizierung und ähnliche Tools laufen weiterhin auf dem Build-Agenten; CodeSign Secure stellt die Operation für den vertrauenswürdigen Schlüssel bereit, nicht den Packaging-Schritt.
• Eine lokale Bereitstellung erfordert weiterhin, dass die Organisation ein FIPS 140-2 Level 3-fähiges HSM bereitstellt oder anschließt (oder es als HSM-as-a-Service nutzt); CodeSign Secure ist eine Signatur- und Richtlinienschicht, kein Ersatz für das HSM selbst.
• Der PKCS#11-Wrapper ist oben für sechs spezifische Workflows dokumentiert (APK, OpenSSL, XML, JSign, jarsigner und GPG2/Debian/RPM-Signierung); ein älteres Tool, das nicht in dieser Liste aufgeführt ist, sollte direkt mit dem Team von CodeSign Secure abgeklärt werden, bevor Sie von einer Abdeckung ausgehen.
• Die ablösbare PQC-Signatur fügt eine zweite Signatur neben der klassischen Signatur hinzu; sie entfernt oder ersetzt nicht die RSA/ECDSA-Signatur, gegen die Ihre bestehenden Clients heute noch verifizieren. Betrachten Sie sie daher als zusätzliche Krypto-Agilität und nicht als abgeschlossene Migration.

Das ist der Teil, den wir Ihnen tatsächlich in einem Telefonat erzählen würden.

Die Anzahl der von einer Signaturplattform unterstützten Formate ist nicht die entscheidende Kennzahl. Das betonen wir in fast jedem Evaluierungsgespräch, und es überrascht diejenigen, die weniger Erfahrung in diesem Bereich haben, mehr als man denken würde. Die wirklich interessante Zahl ist, wie viele Signaturschlüssel eines Unternehmens derzeit außerhalb einer zentralen, HSM-gestützten Kontrollebene liegen – jeder mit eigener Zugriffsliste, eigenem Prüfprotokoll (oder dessen völligem Fehlen) und eigenem Erneuerungskalender, der zentral nicht überwacht wird.

Diese Zahl zu ignorieren, ist nun deutlich teurer geworden. Dank der neuen maximalen Gültigkeitsdauer von 460 Tagen müssen alle diese verstreuten Schlüssel etwa dreimal so häufig neu ausgestellt und bereitgestellt werden wie vor März 2026. Ein manueller Signiervorgang pro Tool, der vor 18 Monaten lediglich lästig war, verschlingt nun jedes Quartal wertvolle Entwicklungszeit. Besonders problematisch ist die Situation für alle, die noch physische USB-Token zum Signieren versenden, anstatt die Daten über ein Netzwerk- oder Cloud-HSM zu leiten.

Die Lösung besteht also nicht darin, einfach das Tool mit dem umfangreichsten Funktionsumfang auf seiner Website auszuwählen. Vielmehr muss sichergestellt werden, dass jedes Signaturformat, das eine Organisation tatsächlich verwendet, durch ein einziges HSM, ein einziges RBAC-Modell und einen einzigen M-of-N-Genehmigungsworkflow geschützt ist. So kann ein kompromittierter Build-Server oder ein gephishtes Entwicklerkonto keine vertrauenswürdige Signatur erzeugen, egal welches der über zwanzig oben genannten Formate er ausprobiert.

Evaluierungs-Checkliste für eine Enterprise-Codesignierungslösung

Verwenden Sie diese Fragen in der angegebenen Reihenfolge, wenn Sie eine zentrale Signaturplattform mit Ihrer eigenen Liste von Formaten und Tools vergleichen:

1. Wird jedes Format, das Sie tatsächlich versenden, über einen einzigen HSM-gestützten Vertrauensstamm geleitet, oder verbirgt die Formatanzahl einen separaten Schlüsselspeicher pro Tool?
2. Wird die RBAC- und M-of-N-Genehmigung für jedes Format durchgesetzt oder nur für die wenigen IT-Systeme, die zuerst eingerichtet wurden?
3. Kann man bei Bedarf einen Prüfpfad für ein bestimmtes Signaturereignis in jedem Format abrufen, ohne die Protokolle eines zweiten oder dritten Tools zu überprüfen?
4. Unterstützt die Plattform bereits jetzt die detachable Post-Quantum-Signatur, oder ist das noch in Planung?
5. Entspricht das Bereitstellungsmodell (lokal, Cloud oder hybrid) Ihren Anforderungen an HSM-Eigentum und Datenspeicherung?
6. Veröffentlicht der Anbieter für jedes Tool, auf das Ihre Teams angewiesen sind und das einen direkten Zugriff auf PKCS#11-Hardware voraussetzt, genau, welche Workflows aktuell unterstützt werden, anstatt nur allgemein anzugeben, dass es „PKCS#11-kompatibel“ ist?

Unabhängige Validierung

Betrachten Sie die Formatliste auf dieser Seite nicht als alleinigen Beweis. Überprüfen Sie sie anhand von Quellen außerhalb von Encryption Consulting:

• ABI Research zählte CodeSign Secure in seiner unabhängigen Marktanalyse zu den Marktführern im Bereich Codesignierung; siehe ABI Research zählt CodeSign Secure zu den Marktführern im Bereich Codesignatur..
• Der Grund für die Dringlichkeit dieses Beitrags liegt in der Änderung der Zertifikatsgültigkeit, die direkt von der Normungsorganisation dokumentiert wird: CA/Browser Forum Abstimmung CSC-31: Reduzierung der maximalen Gültigkeit.
• Die oben genannten Post-Quanten-Signaturstandards FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) werden direkt vom NIST veröffentlicht und nicht aus zweiter Hand zusammengefasst.
• Die Sicherheitsarchitektur von Encryption Consulting (ISO/IEC 27001:2022, SOC 2, PCI DSS) ist dokumentiert auf der Trust Center, unabhängig von den Angaben zu einem einzelnen Produkt.

Wenn Sie es bis hierher geschafft haben

Mehr als zwanzig Formate sind keine bloße Eitelkeitskennzahl, sondern spiegeln ehrlich wider, wie vielfältig moderne Softwareunternehmen ihre Produkte ausliefern: Code, Skripte, Pakete, Container, Firmware und nun auch Post-Quantum-Signaturen – oft über denselben Release-Prozess. Die Teams, die darunter leiden, sind nicht diejenigen, denen ein Signaturtool fehlt. Sie sind diejenigen, die sechs verschiedene Tools parallel betreiben, deren Schlüssel jeweils an einem unbeaufsichtigten Ort liegen – und das zu einem Zeitpunkt, an dem die Gültigkeitsdauer von Zertifikaten um das Dreifache gesunken ist.

Wenn Ihre eigene Signaturpräsenz bereits mehr als zwei oder drei der oben genannten Formate umfasst, ist das in der Regel der Punkt, an dem die Konsolidierung auf eine HSM-gestützte Plattform kein Projekt für die Zukunft mehr ist, sondern das Entscheidende zwischen einer routinemäßigen Veröffentlichung und einer sehr schlechten Woche darstellt.

Erfahren Sie, wie CodeSign Secure jeden dieser Arbeitsabläufe zentralisiert: Entdecken Sie die CodeSign Secure-Plattform.

Häufig gestellte Fragen

Benötigt CodeSign Secure für jedes Signaturformat ein anderes HSM?

Nein. Alle von CodeSign Secure unterstützten Formate, von Authenticode über Container-Images bis hin zu PQC-ablösbaren Signaturen, laufen über dieselbe zentralisierte HSM-Infrastruktur, die lokal, in der Cloud oder als Hybrid bereitgestellt wird, sodass ein Unternehmen nur einen Hardware-Vertrauensstamm anstatt eines pro Tool verwalten muss.

Kann CodeSign Secure sowohl klassische (RSA/ECDSA) als auch Post-Quanten-Signaturen auf demselben Artefakt erstellen?

Ja. CodeSign Secure unterstützt neben der klassischen Signatur auch abtrennbare PQC-Signaturen mittels ML-DSA und LMS, sodass einer Release eine Post-Quantum-Signatur hinzugefügt werden kann, ohne die klassische Signatur zu entfernen, auf die Clients zur Verifizierung weiterhin angewiesen sind.

Warum benötigt die Signierung von HLK/HCK-Treibern einen speziellen Workflow anstelle der standardmäßigen Authenticode-Signierung?

Für Einreichungen im Rahmen des Windows Hardware Lab Kit gelten eigene Zertifikats- und Einreichungsanforderungen, die an das Windows Hardware Dev Center von Microsoft gebunden sind. Kernelmodustreiber unter 64-Bit-Windows lassen sich ohne eine Signatur, die diesen spezifischen Anforderungen entspricht, nicht laden. Daher muss der Signierungsablauf dem Treiberzertifizierungsprozess von Microsoft entsprechen und nicht den allgemeinen Authenticode-Regeln.

Ist Docker Content Trust noch eine unterstützte Methode zum Signieren von Containern?

Docker hat Content Trust für offizielle Images als veraltet markiert. Stattdessen werden nun Sigstore Cosign oder Notation (Notary v2) verwendet, die Signaturen an den Content Digest eines Images binden. CodeSign Secure signiert nach diesen aktuellen Standards und nicht mehr nach dem veralteten Modell.

Was hat sich im Jahr 2026 hinsichtlich der Gültigkeit von Codesignaturzertifikaten geändert?

Gemäß der CA/Browser Forum-Abstimmung CSC-31 wurde die maximale Gültigkeitsdauer für öffentlich vertrauenswürdige Code-Signaturzertifikate mit Wirkung zum 1. März 2026 von 39 Monaten auf 460 Tage gesenkt, was die Häufigkeit der Neuausstellung von Zertifikaten erheblich erhöht, insbesondere für Organisationen, die noch immer auf physische Hardware-Token anstatt auf zentralisierte HSM-Signatur angewiesen sind.

Was benötige ich vor der Implementierung einer Enterprise-Codesignierungslösung wie CodeSign Secure?

Mindestens erforderlich sind ein FIPS 140-2 Level 3 HSM (lokal, in der Cloud oder als Service), Build-Agenten oder CI/CD-Runner für jede Plattform, für die Sie Lizenzen vergeben, entsprechend ausgestellte Zertifikate für jeden Anwendungsfall sowie eine Identitätsquelle zur Zuordnung von Genehmigern zum RBAC- und M-of-N-Workflow. Die genauen unterstützten Betriebssystemversionen und CI/CD-Integrationen sollten anhand der aktuellen Bereitstellungsdokumentation überprüft werden.

Macht die Zentralisierung der Codesignierung plattformspezifische Signaturwerkzeuge überflüssig?

Nein. Tools wie die Xcode-Toolchain für die Apple-Notarisierung oder die Packaging-Tools des Windows Hardware Lab Kits für die Treiberzertifizierung laufen weiterhin auf dem Build-Agenten, um das Artefakt vorzubereiten. CodeSign Secure ändert den Speicherort des privaten Schlüssels und die Art der Autorisierung der Signierungsanfrage, nicht aber den plattformeigenen Packaging-Schritt selbst.