Code Signing – Ein Leitfaden für Manager

Die Codesignierung versieht Software mit einer kryptografischen digitalen Signatur, die den Urheber verifiziert und bestätigt, dass die Software seitdem nicht manipuliert wurde. Dies ist wichtig, da die Online-Softwareverteilung – von mobilen Apps über Unternehmensupdates bis hin zu Open-Source-Paketen – keine inhärente Authentifizierung bietet: Ohne Signatur kann ein Benutzer legitime Software nicht von einer manipulierten Kopie unterscheiden. Die empfohlene Vorgehensweise: Signaturschlüssel in einem FIPS 140-2 Level 2 oder höher zertifizierten HSM speichern (ab Juni 2023 laut CA/Browser Forum obligatorisch), jede Signatur mit einem Zeitstempel versehen und den Signaturprozess zentral verwalten, anstatt ihn einzelnen Entwicklern zu überlassen.

Kurzantwort: Was ist Codesignierung und warum müssen Manager sie verstehen?

Die Codesignierung nutzt Public-Key-Kryptografie, um ein Software-Artefakt mit der Identität seines Herausgebers zu verknüpfen und ein manipulationssicheres Siegel zu erstellen, das jegliche Modifikation nach der Signierung erkennt. Sie beantwortet zwei Fragen, die Benutzer und Betriebssysteme sonst nicht beantworten können: Stammt diese Software tatsächlich von dem angegebenen Herausgeber, und wurde sie seit ihrer Veröffentlichung verändert? Führungskräfte müssen dies verstehen, da Fehler schwerwiegende Folgen für die gesamte Organisation haben: Ein kompromittierter Signaturschlüssel macht alle jemals von der Organisation signierten Versionen ungültig; wird ein kompromittiertes Zertifikat nicht widerrufen, können Angreifer weiterhin Schadsoftware im Namen der Organisation signieren; und laut dem IBM-Bericht „Cost of a Data Breach 2026“ werden die durchschnittlichen Kosten eines Datenlecks weltweit im Jahr 2026 4.99 Millionen US-Dollar erreichen. Die Codesignierung ist eine der direkten technischen Kontrollmaßnahmen, die die durch manipulierte oder imitierte Software verursachten Sicherheitslücken verhindern.

Wie wurde die Codesignierung wichtig?

Drei zusammenlaufende Trends im Softwarevertrieb schufen die Voraussetzungen dafür, dass die Codesignierung unerlässlich wurde.

Erstens wuchs die Zahl der Software entwickelnden und veröffentlichenden Unternehmen enorm, beschleunigt durch die Smartphone-Revolution und den Bedarf jeder Organisation an eigenen Anwendungen. Zweitens ersetzte der Internetvertrieb physische Datenträger (CDs, DVDs) als primären Softwarevertriebsmechanismus. Dies ermöglichte eine nahezu sofortige und großflächige Verbreitung zu minimalen Kosten, beseitigte aber die physische Nachweiskette, die Nutzern zuvor Vertrauen in die Echtheit der Software gegeben hatte. Drittens wuchs die Zahl der unabhängigen Softwareanbieter (ISVs), die Softwareanwendungen entwickeln, stetig. Einige Studien berichten von einem zehnfachen Wachstum im letzten Jahrzehnt.

Die Folge ist, dass Software nun über Kanäle vom Herausgeber zum Nutzer gelangt, auf denen sie von jedem abgefangen, verändert und weiterverbreitet werden kann. Codesignierung begegnet diesem Problem, indem sie zum Zeitpunkt des Herunterladens und Installierens einen kryptografischen Nachweis sowohl der Identität des Herausgebers als auch der Integrität der Software liefert, ohne dass die Nutzer dem Vertriebskanal selbst vertrauen müssen.

Die Dimension der Lieferkette hat die Dringlichkeit dieses Problems noch verstärkt: Der Sonatype-Bericht „State of the Software Supply Chain 2026“ identifizierte über 454,600 neue schädliche Open-Source-Pakete im Jahr 2025 – ein Anstieg von 75 % gegenüber dem Vorjahr. Die Beteiligung von Drittanbietern an Datenschutzverletzungen hat sich laut dem Verizon-Bericht „Data Breach Investigations Report 2025“ innerhalb eines Jahres von 15 % auf 30 % verdoppelt. Die Codesignierung ist das Kontrollinstrument, mit dem nachgelagerte Nutzer überprüfen können, ob ein Paket tatsächlich unverändert vom angegebenen Herausgeber stammt. Genau dieses Vertrauensverhältnis nutzen Angreifer in der Lieferkette aus.

So funktioniert Code Signing

Der Begriff „Code“ im Zusammenhang mit Codesignierung kann ausführbare Dateien, Archive, Treiber, Firmware, Bibliotheken, Pakete und im Grunde jede Software umfassen, die zur Veröffentlichung und Verbreitung bestimmt ist. Um die Funktionsweise der Codesignierung zu verstehen, ist ein grundlegendes Verständnis der Public-Key-Infrastruktur (PKI) hilfreich . Diese umfasst die Rollen, Richtlinien, Hardware, Software und Verfahren, die zur Erstellung, Verwaltung, Verteilung, Verwendung, Speicherung und zum Widerruf digitaler Zertifikate verwendet werden.

Die Codesignierung verfolgt zwei Hauptziele: den Nachweis des Eigentums am Code (die Echtheit der Software vom autorisierten Herausgeber) und die Integrität des Codes (der Nachweis, dass der Code nicht manipuliert wurde). Der vierstufige Prozess, der beides gewährleistet:

1. Schlüsselgenerierung: Es werden ein privater Schlüssel und ein zugehöriges öffentliches Schlüsselpaar generiert. Der private Schlüssel muss in einem HSM gespeichert werden (siehe Abschnitt Schlüsselverwaltung weiter unten) und darf niemals in verwendbarer Form exportiert werden.
2. Codesignaturzertifikat: Beantragen Sie ein Code-Signatur-Zertifikat bei einem vertrauenswürdigen Anbieter. Zertifizierungsstelle (CA)Das Zertifikat enthält die Identität der Organisation, den öffentlichen Schlüssel, die Gültigkeitsdauer und die digitale Signatur der Zertifizierungsstelle. Seit Juni 2023 müssen öffentlich vertrauenswürdige Codesignaturzertifikate den privaten Schlüssel auf Hardware gemäß FIPS 140-2 Level 2 oder höher speichern.
3. Hashing: Das Softwareartefakt wird einer Hash-Funktion zugeführt, die einen Hashwert fester Länge erzeugt, der den Inhalt des Artefakts repräsentiert. Jede Änderung am Artefakt, selbst ein einzelnes Bit, führt zu einem völlig anderen Hashwert. SHA-256 ist der aktuelle Mindeststandard; SHA-1 und MD5 sind veraltet und dürfen nicht mehr verwendet werden.
4. Unterzeichnung: Der Hashwert wird mit dem privaten Schlüssel verschlüsselt, wodurch die digitale Signatur entsteht. Die Signatur wird zusammen mit dem Codesignaturzertifikat dem Softwarepaket für den Vertrieb beigefügt. Die Originalsoftware wird nicht verschlüsselt; lediglich der kurze Hashwert wird signiert, was den Prozess schnell und effizient macht.

Leitfaden zur Auswahl von Algorithmen und Protokollen

Komponente	Empfohlen	Mindestakzeptables	Veraltet/vermeiden	Notizen
Hash-Algorithmus	SHA-256 oder SHA-384	SHA-256	SHA-1, MD5	SHA-1 gilt laut NIST als veraltet und wird von den meisten Plattformen abgelehnt; MD5 ist für Kollisionsangriffe bekannt.
Signaturalgorithmus	RSA-3072 oder ECDSA P-256	RSA-2048 (läuft gemäß NIST IR 8547 nach 2030 ab)	RSA-1024, DSA-1024	ECDSA P-256 bietet die gleiche Sicherheit wie RSA-3072 bei kleineren Schlüssel- und Signaturgrößen.
Schlüsselaufbewahrung	FIPS 140-2 Level 2 oder Level 3 HSM	FIPS 140-2 Level 2 (verpflichtend gemäß CA/B Forum seit Juni 2023)	Software-Schlüsselspeicher, private Dateisystemschlüssel	Das CA/Browser Forum schreibt die Speicherung aller öffentlich vertrauenswürdigen Codesignaturzertifikate auf Hardwareebene vor.
Timestamp	RFC 3161-Zeitstempel von einer vertrauenswürdigen TSA	RFC 3161-Zeitstempel	Kein Zeitstempel	Ohne Zeitstempel erlischt die Gültigkeit der Signatur mit dem Ablauf des Zertifikats.
Post-Quantenzeit (Planungshorizont)	ML-DSA (FIPS 204) für neue, langlebige Signaturinfrastruktur	Derzeitiger Übergang von ECDSA/RSA zu PQC ausstehend	RSA-2048 allein für neue Infrastrukturen (quantenanfällig nach 2030)	NIST IR 8547 schlägt vor, klassische asymmetrische Algorithmen nach 2030 als veraltet zu betrachten.

Was passiert beim Herunterladen der Software?

Wenn ein Benutzer signierte Software herunterlädt, erfolgt der Verifizierungsprozess automatisch im Browser oder Betriebssystem:

1. Der Browser oder das Betriebssystem prüft, ob das Codesignaturzertifikat von einer vertrauenswürdigen Zertifizierungsstelle (CA) stammt (CA-Root-Zertifikate sind in Browsern und Betriebssystemen vorinstalliert). Stammt das Zertifikat nicht von einer vertrauenswürdigen CA, zeigt das Betriebssystem eine Warnung an und kann die Installation blockieren.
2. Der öffentliche Schlüssel wird aus dem Zertifikat extrahiert und zur Entschlüsselung der digitalen Signatur verwendet, wodurch der ursprüngliche Hashwert wiederhergestellt wird.
3. Die heruntergeladene Software (ohne Zertifikat und Signatur) wird mit demselben Algorithmus erneut gehasht.
4. Die beiden Hashwerte werden verglichen. Stimmen sie überein, ist die Software authentisch und unverändert. Stimmen sie nicht überein (weil ein Angreifer die Software nach der Signierung verändert hat), warnt das Betriebssystem den Benutzer und verweigert die Installation.

Best Practices für die Code-Signierung

1. Private Schlüssel in einem HSM speichern: die HSM Der Export privater kryptografischer Schlüssel ist nicht gestattet. Gemäß den Anforderungen des CA/Browser-Forums vom Juni 2023 ist ein nach FIPS 140-2 Level 2 (oder höher) zertifiziertes HSM nun für jedes öffentlich vertrauenswürdige Codesignaturzertifikat obligatorisch.
2. Zugriff auf private Schlüssel beschränken: Nur Personal oder automatisierte Systeme mit einem spezifischen, dokumentierten Bedarf sollten einen Signaturvorgang auslösen können. Jeder Signaturvorgang sollte einen Eintrag im Prüfprotokoll generieren, der den Auslöser, den Zeitpunkt und das signierte Dokument enthält.
3. Signierter Code immer mit Zeitstempel versehen: Ein RFC-3161-Zeitstempel einer vertrauenswürdigen Zeitstempelstelle (TSA) verknüpft das Signaturereignis mit einem bestimmten Zeitpunkt. Dadurch bleibt die Signatur auch nach Ablauf oder Widerruf des Signaturzertifikats verifizierbar, sofern das Zertifikat zum Zeitpunkt der Signatur gültig war.
4. Verwenden Sie für jede Produktlinie separate Schlüssel: Die Verwendung eines einzigen Schlüssels für alle Produkte bedeutet, dass die Kompromittierung dieses Schlüssels die Vertrauenswürdigkeit aller jemals vom Unternehmen veröffentlichten Produkte ungültig macht. Separate Schlüssel pro Produktlinie und idealerweise pro Hauptversion begrenzen die Auswirkungen einer Schlüsselkompromittierung.
5. Zentralisierung der Signaturverwaltung: Die Ad-hoc-Signierung durch einzelne Entwickler mit lokal gespeicherten Schlüsseln bietet keine Transparenz, Nachvollziehbarkeit oder Durchsetzung von Richtlinien. Eine zentrale Signaturplattform gewährleistet hingegen einheitliche Richtlinien für alle Produkte und Teams und stellt den für Compliance und Vorfallsuntersuchung erforderlichen Prüfpfad bereit.

Code Signing für die Sicherheit der Software-Lieferkette

Wird ein privater Schlüssel kompromittiert, verliert das Zertifikat seine Vertrauenswürdigkeit, wodurch die Authentizität und Integrität aller mit diesem Schlüssel signierten Software zerstört wird. Das damit verbundene Lieferkettenrisiko ist erheblich: Der Sonatype-Bericht „State of the Software Supply Chain Report 2026“ identifizierte über 454,600 neue schädliche Open-Source-Pakete im Jahr 2025 (ein Anstieg von 75 % gegenüber dem Vorjahr), und die Beteiligung von Drittanbietern an Sicherheitsvorfällen hat sich laut dem Verizon DBIR 2025 von 15 % auf 30 % verdoppelt.

Für die Sicherheit der Lieferkette sind neben der einfachen Unterzeichnung zwei weitere Kontrollmaßnahmen unerlässlich:

1. Authentifizieren Sie den Code vor der Signierung: Organisationen sollten die Anmeldung integrieren CI / CD-Pipelines Genehmigungsmechanismen verhindern, dass schädlicher oder nicht genehmigter Code den Signierschritt erreicht. Nach der Signierung müssen die Artefakte vor der Verteilung anhand der Signatur überprüft werden. Alle Signiervorgänge müssen zur späteren Überprüfung protokolliert werden.
2. Gefährdete Zertifikate umgehend widerrufen: Besteht der Verdacht, dass ein privater Schlüssel kompromittiert wurde, muss die ausstellende Zertifizierungsstelle das Zertifikat unverzüglich widerrufen. Der Widerruf signalisiert allen vertrauenden Parteien, dass dem Zertifikat nicht mehr vertraut werden kann. Ein verzögerter Widerruf bedeutet, dass Angreifer weiterhin Schadsoftware im Namen der Organisation signieren können, solange das Zertifikat gültig bleibt.

Codesignierung in Cloud-nativen und CI/CD-Umgebungen

Die Codesignierung ist in Cloud-nativen Umgebungen unerlässlich. Container-Images, Anwendungsdateien und Kubernetes-Bereitstellungsmanifeste müssen signiert werden, um eine vertrauenswürdige Artefaktkette vom Build bis zum Deployment zu gewährleisten. In Cloud-nativen Umgebungen ist die Signierung in CI/CD-Pipelines integriert , sodass jedes von der Pipeline erzeugte Artefakt automatisch während des Build-Prozesses signiert wird und nicht erst nachträglich manuell.

Ein neueres Verfahren ist die schlüssellose Signatur, die durch das Open-Source-Projekt Sigstore bekannt wurde. Anstatt dass ein Manager langlebige Zertifikate für jede Pipeline bereitstellt und rotiert, stellt die schlüssellose Signatur zum Zeitpunkt der Signatur ein kurzlebiges Zertifikat aus, das an eine OIDC-Identität (OpenID Connect), beispielsweise die Identität einer CI/CD-Workload, gebunden ist. Der private Schlüssel wird anschließend vollständig verworfen. Die Signatur und ein öffentlicher Eintrag werden in einem Transparenz-Ledger protokolliert, anstatt sich auf ein Zertifikat zu verlassen, das über Monate oder Jahre hinweg verfolgt, erneuert und widerrufen werden muss.

Traditionelle PKI-basierte Signierung vs. schlüssellose (Sigstore-ähnliche) Signierung

Aspekt	Traditionelle PKI-basierte Signatur	Schlüsselloses Signieren (im Sigstore-Stil)
Schlüssellebensdauer	Langlebig (typischerweise 1-3 Jahre), muss aktiv gemanagt werden	Kurzlebig; wird pro Unterzeichnungsereignis ausgegeben und anschließend verworfen.
Schlüsselaufbewahrung	HSM oder Hardware-Token (obligatorisch seit Juni 2023)	Kein persistenter privater Schlüssel zum Speichern
Identitätsbindung	Die Identität der Organisation wurde bei der Ausstellung von einer Zertifizierungsstelle überprüft.	Workload-/OIDC-Identität bei Vertragsunterzeichnung verifiziert
Widerruf	Manueller CA-Widerrufsprozess im Falle einer Kompromittierung	Nicht zutreffend; ein kompromittierter temporärer Schlüssel läuft fast sofort ab.
Am besten geeignet,	Ausgelieferte Desktop-Software, Treiber und Installationsprogramme, die eine langfristige Signaturgültigkeit erfordern	CI/CD-Pipelines, Container-Images, Cloud-native Artefakte werden häufig signiert

Die meisten Unternehmen nutzen beide Modelle: traditionelle Zertifikate für ausgelieferte, langlebige Binärdateien und schlüssellose oder kurzlebige Signierung für häufig verwendete Artefakte, die durch CI/CD-Pipelines wandern.

Bereitstellungsbeispiele

Veröffentlichung einer Windows-Desktopanwendung: Der Entwickler übermittelt einen Build an die Signaturpipeline. CodeSign Secure berechnet einen Hash der ausführbaren Datei, sendet diesen Hash zur RSA-3072-Signierung an das HSM, ruft den signierten Hash ab, fügt einen RFC-3161-Zeitstempel vom TSA hinzu und bündelt Zertifikat, Signatur und Zeitstempel mit der Installationsdatei. Der gesamte Prozess findet innerhalb der Pipeline statt, ohne dass der private Schlüssel das HSM verlässt. Beim Herunterladen des Installationsprogramms überprüft Windows SmartScreen die Zertifikatskette anhand vertrauenswürdiger Stammzertifikate und bestätigt die Übereinstimmung des Hashs, bevor die Installation zugelassen wird.

Signierung von Container-Images in einer Kubernetes-Umgebung: Nachdem ein Container-Image erstellt und in die Registry hochgeladen wurde, ruft die CI/CD-Pipeline CodeSign Secure auf, um den Image-Digest mit dem im HSM gespeicherten ECDSA-P-256-Schlüssel der Organisation zu signieren. Der signierte Image-Digest und das Zertifikat werden zusammen mit dem Image in der Registry gespeichert. Kubernetes-Zugangscontroller (wie OPA Gatekeeper oder Kyverno) sind so konfiguriert, dass sie die Signatur überprüfen, bevor ein Container in der Produktionsumgebung bereitgestellt werden darf. Images, die nicht mit dem Schlüssel der Organisation signiert wurden, werden abgelehnt.

Open-Source-Paketveröffentlichung mit schlüsselloser Signierung (Sigstore): Der GitHub-Actions-Release-Workflow des Paketbetreuers löst das Sigstore-Tool „cosign“ aus. Dieses fordert ein kurzlebiges Zertifikat von der Fulcio-Zertifizierungsstelle von Sigstore an, das mit der GitHub-Actions-OIDC-Identität des Release-Workflows verknüpft ist. Das Paket wird mit dem temporären Schlüssel signiert, der private Schlüssel wird sofort verworfen und die Signatur im Rekor-Transparenzprotokoll von Sigstore gespeichert. Nachgelagerte Nutzer überprüfen die Signatur mithilfe von „cosign verify“ anhand des Rekor-Protokolls und bestätigen so, dass das Paket im Rahmen des legitimen Release-Workflows beim jeweiligen Commit signiert wurde.

Wie CodeSign Secure Managern hilft, dieses Risiko zu kontrollieren

Manager müssen die Kryptografie nicht selbst bedienen, benötigen aber eine Plattform, die die oben genannten Best Practices durchsetzt, ohne dass einzelne Entwickler diese im Gedächtnis behalten müssen. CodeSign Secure von Encryption Consulting erreicht dies, indem es jedes Artefakt innerhalb eines HSM signiert, sodass private Schlüssel die Hardware niemals verlassen, eine rollenbasierte Zugriffskontrolle implementiert, sodass nur autorisierte Benutzer einen Signiervorgang auslösen können, und jede Signieraktion für den erforderlichen Audit-Trail protokolliert.

CodeSign Secure verwendet clientseitiges Hashing, sodass die signierte Datei die Kundenumgebung niemals ungeschützt verlässt. Zudem wird jede Signatur mit einem Zeitstempel versehen, um zu verhindern, dass Softwaresignaturen mit dem Zertifikat ablaufen. Für Teams, die sowohl ausgelieferte Binärdateien als auch CI/CD-Pipelines verwalten, bietet CodeSign Secure eine zentrale Plattform, die sowohl die traditionelle HSM-gestützte Signierung als auch die Integration in moderne Pipeline-Signierungs-Workflows abdeckt. Dadurch entfällt die Notwendigkeit separater manueller Prozesse für jeden Artefakttyp.

Einschränkungen der Codesignierung

• Die Codesignierung dient der Überprüfung von Integrität und Identität, nicht von Korrektheit: Ein signiertes Artefakt beweist, dass es unverändert vom angegebenen Herausgeber stammt. Es beweist jedoch nicht, dass der Code frei von Schwachstellen, Hintertüren oder Schadcode ist, der vor der Signierung vorhanden war. Ein Entwickler kann selbstgeschriebenen Schadcode signieren. Codesignierung und Anwendungssicherheitstests decken unterschiedliche Bedrohungskategorien ab.
• Der entscheidende Kompromiss ist katastrophal und schwer einzudämmen: Wird ein Signaturschlüssel kompromittiert, ist jedes jemals mit diesem Schlüssel signierte Artefakt verdächtig. Der Widerruf signalisiert Misstrauen gegenüber den vertrauenden Parteien, doch bereits auf Benutzersystemen installierte Artefakte bleiben signiert. Daher sind Schlüsselmanagement, HSM-Speicherung und das Prinzip der minimalen Berechtigungen für Signaturvorgänge so wichtig.
• Die Widerrufsprüfung weist Lücken auf: Der Zertifikatswiderruf funktioniert nur, wenn die vertrauenden Parteien den Widerrufsstatus tatsächlich überprüfen. OCSP-Stapling und CRL-Verteilung verbessern die Abdeckung, aber einige Plattformen und Umgebungen führen Widerrufsprüfungen nicht zuverlässig durch. Das bedeutet, dass ein widerrufenes Zertifikat in Umgebungen, die keine Widerrufsprüfung durchführen, weiterhin akzeptiert werden kann.
• Die schlüssellose Signierung ist von der Transparenzprotokollinfrastruktur abhängig: Die schlüssellose Signierung mit Sigstore verlagert das Vertrauen auf das Rekor-Transparenzprotokoll und die Fulcio-Zertifizierungsstelle. Dies sind neue Infrastrukturkomponenten mit eigenen Verfügbarkeits- und Vertrauensanforderungen. Organisationen, die die schlüssellose Signierung für kritische Artefakte einsetzen, sollten diese Abhängigkeiten verstehen.

Fazit

Die Codesignierung ist ein wesentlicher Bestandteil des Softwareentwicklungszyklus, und die Rahmenbedingungen haben sich in den letzten Jahren deutlich verändert. Die Speicherung in einem HSM ist für öffentlich vertrauenswürdige Zertifikate mittlerweile obligatorisch. Die Angriffsfläche in der Lieferkette hat sich drastisch vergrößert. Neue Signaturmodelle wie die schlüssellose und die pipelineintegrierte Signatur verändern die Art und Weise, wie Unternehmen mit dem Vertrauen in Artefakte in großem Umfang umgehen.

Für Manager sind die wichtigsten Entscheidungen organisatorischer Natur: Wer kontrolliert die Signaturschlüssel, welche Zugriffskontrollen steuern Signaturvorgänge, wie wird die Signatur geprüft und wie reagiert das Unternehmen, wenn ein Schlüssel kompromittiert wird? Diese Entscheidungen betreffen sowohl die Unternehmensführung als auch die technischen Aspekte und erfordern dieselbe Sorgfalt wie jedes andere privilegierte System im Unternehmen. Wenn Sie Ihre aktuelle Codesignatur-Strategie bewerten oder die Signatur mit HSM-gestütztem Schlüsselschutz in Ihre CI/CD-Pipelines integrieren möchten, kontaktieren Sie Encryption Consulting, um die nächsten Schritte zu besprechen.

Häufig gestellte Fragen

Was sind die beiden Hauptziele der Codesignierung?

Codebesitz, der beweist, dass die Software vom angegebenen Herausgeber stammt, und Codeintegrität, die beweist, dass sie seit der Signierung nicht verändert wurde. Alles andere im Codesignaturprozess dient der Unterstützung eines dieser beiden Ziele.

Welche vier Schritte umfasst der Codesignierungsprozess?

Die Schlüsselerzeugung umfasst das Beschaffen eines Codesignaturzertifikats von einer Zertifizierungsstelle, das Hashen des Codes und das Signieren dieses Hashwerts mit dem privaten Schlüssel. Der signierte Hashwert und das Zertifikat werden anschließend mit dem Softwarepaket übertragen.

Warum müssen private Codesignaturschlüssel in einem HSM gespeichert werden?

Ein Hardware-Sicherheitsmodul verhindert, dass der private Schlüssel jemals in verwendbarer Form exportiert wird – genau das, was ein Angreifer benötigt, um Schadcode überzeugend zu signieren. Seit dem 1. Juni 2023 schreibt das CA/Browser Forum die Speicherung des Schlüssels in Hardware für jedes öffentlich vertrauenswürdige Codesignaturzertifikat vor.

Was passiert, wenn der private Schlüssel eines Codesignaturzertifikats kompromittiert wird?

Das Zertifikat verliert sein Vertrauen vollständig. Jede Software, die jemals mit diesem Schlüssel signiert wurde, wird verdächtig. Deshalb muss die Zertifizierungsstelle das kompromittierte Zertifikat unverzüglich widerrufen, und Sicherheitsteams empfehlen, Signaturschlüssel regelmäßig zu wechseln, anstatt einen Schlüssel für viele Produktlinien wiederzuverwenden.

Wie hoch sind die durchschnittlichen Kosten einer Datenschutzverletzung und warum ist das für die Codesignierung relevant?

Laut dem IBM-Bericht „Cost of a Data Breach 2026“ erreichten die weltweiten durchschnittlichen Kosten einer Datenschutzverletzung im Jahr 2026 4.99 Millionen US-Dollar, ein Anstieg von 12 % gegenüber dem Vorjahr. Codesignierung ist eine der direkten Kontrollmaßnahmen, um diese spezielle Art von Datenschutzverletzung zu verhindern, die durch manipulierte oder nachgeahmte Software verursacht wird.

Warum ist die Codesignierung besonders wichtig für die Sicherheit der Software-Lieferkette?

Sonatype identifizierte im Jahr 2025 über 454,600 neue schädliche Open-Source-Pakete, ein Anstieg von 75 % gegenüber dem Vorjahr. Laut dem Verizon DBIR 2025 hat sich die Beteiligung von Drittanbietern an Sicherheitsvorfällen auf 30 % verdoppelt. Die Codesignierung ermöglicht es nachgelagerten Nutzern zu überprüfen, ob ein Paket unverändert vom angegebenen Herausgeber stammt – genau dieses Vertrauen in der Lieferkette nutzen Angreifer aus.

Worin besteht der Unterschied zwischen der traditionellen PKI-basierten Codesignierung und der schlüssellosen Signatur?

Die traditionelle Signierung verwendet ein langlebiges Zertifikat, das in einem HSM gespeichert und über die Zertifizierungsstelle erneuert und widerrufen wird. Die schlüssellose Signierung stellt ein temporäres Zertifikat aus, das zum Zeitpunkt der Signierung an eine Workload-Identität gebunden ist, und verwirft den Schlüssel sofort. Dadurch wird die langfristige Schlüsselverwaltung durch die ereignisbasierte Ausstellung über ein Transparenzprotokoll ersetzt.

Spielt die Zeitstempelung eine Rolle, wenn mein Codesignaturzertifikat abläuft?

Ja. Ohne Zeitstempel erlischt die Gültigkeit einer Signatur mit dem Zertifikat. Ein Zeitstempel gemäß RFC 3161 ermöglicht die weitere Überprüfung signierten Codes als authentisch, selbst nachdem das ursprüngliche Zertifikat seine Gültigkeit verloren hat, sofern das Zertifikat zum Zeitpunkt der Signierung gültig war.

Wie lässt sich Codesignierung in CI/CD- und Cloud-native Umgebungen integrieren?

Die Codesignierung ist direkt in die Pipeline integriert und wird nicht als manueller letzter Schritt angewendet. Container-Images und Binärdateien werden automatisch während ihrer Erstellung signiert. Viele Cloud-native Teams kombinieren die traditionelle HSM-gestützte Signierung für langlebige Binärdateien mit schlüsselloser oder kurzlebiger Signierung für häufig verwendete Pipeline-Artefakte.

Wie hilft CodeSign Secure Managern bei der Kontrolle des Codesignierungsrisikos?

Es signiert jedes Artefakt innerhalb eines HSM, sodass die Schlüssel die Hardware niemals verlassen, erzwingt eine rollenbasierte Zugriffskontrolle darüber, wer ein Signierungsereignis auslösen kann, versieht jede Signatur mit einem Zeitstempel und protokolliert jede Aktion zu Prüfungszwecken, wodurch die Best Practices in diesem Leitfaden in ein erzwungenes Plattformverhalten umgesetzt werden.