Reifegrad der Codesignatur aufgedeckt: Herausforderungen und Erkenntnisse

Fragt man die meisten Entwicklerteams, ob sie Codesignierung einsetzen, lautet die Antwort Ja. Fragt man sie jedoch, ob sie über eine zentrale Signaturrichtlinie, ein dokumentiertes Schlüsselverwaltungsverfahren, einen Prüfpfad für jeden Signaturvorgang und einen automatisierten Prozess zur Zertifikatserneuerung vor deren Ablauf verfügen, wird die Antwort komplexer.

Die Kluft zwischen „Wir signieren Code“ und „Wir verfügen über ein ausgereiftes Codesignierungsprogramm“ ist größer, als den meisten Unternehmen bewusst ist. Und im Jahr 2026 wird diese Kluft folgenreicher sein als je zuvor. Lieferkettenangriffe erreichen Rekordwerte, und laut dem Verizon-Bericht „Data Breach Investigations Report 2026 “, der über 22,000 bestätigte Datenschutzverletzungen in 145 Ländern analysierte, sind mittlerweile 48 % aller Datenschutzverletzungen auf die Beteiligung von Drittanbietern zurückzuführen – ein Anstieg von 60 % gegenüber dem Vorjahr.

Die Abstimmung des CA/Browser Forums (CSC-31) verkürzte die Gültigkeitsdauer von Codesignaturzertifikaten von 39 Monaten auf 460 Tage, gültig ab dem 1. März 2026. Das NIST veröffentlichte im Dezember 2025 einen ersten öffentlichen Entwurf der SSDF Version 1.2 (SP 800-218 Revision 1) und erhöhte damit die Anforderungen an nachweislich sichere Softwareentwicklung. Regulierungsbehörden branchenübergreifend gehen von Empfehlungen zu Durchsetzungsmaßnahmen über.

Wir werden ein praxisorientiertes Reifegradmodell für Code-Signaturen betrachten: vier Stufen, die beschreiben, wie sich Organisationen von fragmentierten, ad-hoc-Signaturverfahren zu vollständig automatisierten, richtlinienbasierten und zukunftssicheren Programmen entwickeln. Wo auch immer Ihre Organisation heute steht – zu verstehen, wo Sie stehen und wie die nächste Stufe aussieht, ist der Ausgangspunkt für den Erfolg.

Reifegrad der Codesignatur, definiert als: der Grad, in dem HSM-gestützte Schlüsselverwaltung, rollenbasierte Zugriffskontrolle mit Funktionstrennung, Genehmigungsprozesse, geplante Schlüsselrotation, unveränderliche Prüfprotokolle, getesteter Widerruf, obligatorische Zeitstempelung und isolierte Build-Umgebungen durch die Infrastruktur und nicht durch Richtliniendokumente, deren Einhaltung den Mitarbeitern anvertraut wird, durchgesetzt werden, gemessen in vier Stufen von ad hoc bis optimiert.

Wichtige Erkenntnisse

• 3CX (2023) ist der deutlichste Beweis dafür, dass nicht die Kryptographie, sondern die Reife der Systeme der übliche Schwachpunkt ist: Sowohl die Signatur als auch das Zertifikat waren echt, und die Kompromittierung erfolgte, weil keine Kontrollmaßnahme einen Angreifer daran hinderte, der Zugriff auf die Build-Umgebung erlangt hatte, einen Signiervorgang auszulösen.
• Eine Richtlinie, die technisch nicht durchgesetzt wird, ist keine Kontrollmaßnahme; die Kluft zwischen „Wir haben eine Signaturrichtlinie“ und „Unsere Infrastruktur macht es unmöglich, die Richtlinie zu umgehen“ entspricht der gesamten Distanz zwischen Phase 2 und Phase 3.
• Schlüsselrotation, Widerrufsbereitschaft und Build-Isolation fehlen häufig selbst bei ansonsten ausgereiften Programmen; siehe „Kontrollen, die nicht übersprungen werden sollten“ weiter unten, um zu erfahren, was jeweils genau erforderlich ist.
• Diese Seite dient als Diagnoserahmen: Wo steht Ihr Programm aktuell und wie geht es weiter? Eine übersichtliche, phasenunabhängige Checkliste mit einzelnen Maßnahmen finden Sie hier. Best Practices für die Codesignierung im Softwareentwicklungszyklus.
• Ein Reifegrad-Score ist ein Diagnoseinstrument, keine Sicherheitsgarantie; lesen Sie die „Einschränkungen“ weiter unten, bevor Sie ein Ergebnis der Stufe 3 oder 4 als ausreichenden Sicherheitsnachweis betrachten.

Warum die Reife der Codesignatur wichtiger ist als je zuvor

Die Codesignierung dient einem einzigen, grundlegenden Zweck: Sie ermöglicht Softwarenutzern und -plattformen die Überprüfung, ob eine Binärdatei von einer bekannten, vertrauenswürdigen Partei erstellt wurde und seit der Signierung nicht verändert wurde. Funktioniert sie korrekt, ist sie der primäre Mechanismus zur Feststellung der Softwareidentität und zur Sicherstellung der Softwareintegrität.

Wenn dies fehlschlägt, beispielsweise weil ein Signaturschlüssel gestohlen wird, ein Zertifikat ohne Autorisierung verwendet wird oder ein Signaturvorgang außerhalb eines Governance-Rahmens stattfindet, können die Folgen schwerwiegend und weitreichend sein.

Betrachten wir einen der bedeutendsten Lieferkettenangriffe der jüngeren Geschichte, um genau zu sehen, was passiert, wenn die Codesignierung missbraucht wird:

3CX (2023): Die mit Nordkorea verbundene Lazarus-Gruppe führte einen Kaskadenangriff auf die Lieferkette durch. Dabei wurde eine Finanzsoftware kompromittiert, wodurch die Entwicklungsumgebung von 3CX kompromittiert wurde. Die 3CX-Desktopanwendung, die von rund 600,000 Organisationen genutzt wird, wurde anschließend mit dem eigenen gültigen Zertifikat von 3CX signiert und als reguläres Update an die Kunden verteilt. Weder die Signatur noch das Zertifikat waren gefälscht. Das signierte Artefakt selbst war jedoch schädlich.

Dieser Angriff verdeutlicht eine wichtige Lektion: Eine gültige Signatur auf Schadcode ist kein Sicherheitsversagen auf kryptografischer Ebene, sondern ein Versagen in der Systemsteuerung und den Prozessen. Weder der Schlüssel noch das Zertifikat wurden gestohlen oder gefälscht. Der Signaturprozess enthielt schlichtweg keine Kontrollmechanismen, die einen Angreifer, der bereits Zugriff auf die Build-Umgebung erlangt hatte, daran gehindert hätten, eine Signaturoperation auszulösen.

Was ist ein Reifegradmodell für Codesignierung?

Ein Reifegradmodell ist ein Rahmenwerk, das beschreibt, wie sich eine Fähigkeit von anfänglichen, informellen Übungen bis hin zum vollständig optimierten Betrieb entwickelt. Das Capability Maturity Model (CMM), ursprünglich vom Software Engineering Institute der Carnegie Mellon University entwickelt, legte das grundlegende Muster fest, das Organisationen dazu verpflichtet, definierte Stufen zu durchlaufen, von denen jede ein höheres Maß an Prozessdisziplin, Wiederholbarkeit und Resilienz repräsentiert.

Hier sind alle Kriterien, die für die Reife von Codesignaturen relevant sind:

Abmessungen	Was es abdeckt
Schlüsselverwaltung	Wie private Signaturschlüssel generiert, gespeichert, geschützt und rotiert werden
Zugangskontrolle	Wer darf unterschreiben, was darf unterschrieben werden und welche Kontrollmechanismen regeln diesen Zugriff?
Politik und Governance	Ob die Richtlinien für die Vertragsunterzeichnung dokumentiert, durchgesetzt und überprüft werden
Zertifikatsverwaltung	Wie Zertifikate innerhalb der Organisation verfolgt, erneuert und widerrufen werden.
Pipeline-Integration	Ob die Signierung in CI/CD-Workflows eingebettet oder manuell durchgeführt wird
Audit und Überwachung	Ob jedes Signierereignis protokolliert, überprüft und über anomale Ereignisse informiert wird
Vorfallreaktion	Ob die Organisation einen Plan für kompromittierte Schlüssel oder unbefugte Signaturen hat
Zukunftsbereitschaft	Ob das Programm Post-Quanten-Kryptographie und sich entwickelnde Standards berücksichtigt

Kontrollmechanismen, die nicht außer Acht gelassen werden sollten: Rotation, Widerruf, Funktionstrennung und Gebäudeisolierung

Vier Kontrollmechanismen werden selbst in ansonsten ausgereiften Programmen oft übersehen, da sie erst dann relevant werden, wenn ein bestimmtes Ereignis sie erfordert. Durch die explizite Benennung dieser Mechanismen, anstatt sie in Kategorien wie „Schlüsselverwaltung“ oder „Zugriffskontrolle“ einzuordnen, lassen sie sich leichter überprüfen.

Schlüsselrotation

Die Speicherung eines Schlüssels in einem HSM beantwortet die Frage nach dem Speicherort, nicht aber nach der Dauer seiner unveränderten Speicherung. Ein ausgereiftes Programm definiert einen Rotationsplan pro Schlüssel, der an die Zertifikatserneuerung innerhalb des aktuellen Gültigkeitszeitraums von mindestens 460 Tagen gekoppelt ist, und behandelt die Rotation als routinemäßigen, automatisierten Vorgang und nicht als etwas, das nur bei einem vermuteten Sicherheitsvorfall ausgelöst wird. Wenn Ihr Programm die Frage „Wann wurde dieser spezifische Signaturschlüssel zuletzt rotiert?“ nur durch Überprüfung des Zertifikatsablaufs beantworten kann, wird die Rotation nicht als eigenständige Steuerungsmaßnahme verwaltet.

Widerrufsbereitschaft

Ein dokumentierter Notfallplan ist nicht dasselbe wie ein getesteter. Die Bereitschaft zur Zertifikatssperrung bedeutet, vor einem Vorfall genau zu wissen, welche Dokumente ein bestimmtes Zertifikat signiert hat, diese Liste innerhalb einer Stunde nach dem Verdacht auf eine Kompromittierung erstellen zu können und bereits bestätigt zu haben, dass die Sperrung des Zertifikats einen Vertriebskanal, der den Sperrstatus nicht prüft, nicht unbemerkt beeinträchtigt. Die genauen Mechanismen der Sperrung, die Auswirkungen auf den Zeitstempel und die erneute Signierung nach einer Kompromittierung werden im Abschnitt „ Einrichtung eines Firmware-Signatur-Frameworks zur Einhaltung der CRA-Vorschriften“ erläutert.

Aufgabentrennung

RBAC regelt, wer signieren darf; Funktionstrennung regelt, ob eine einzelne Identität dieselbe Signieroperation anfordern und genehmigen kann. Ein Programm kann über detaillierte RBAC verfügen und dennoch die Funktionstrennung nicht erfüllen, wenn die Rolle eines Hauptentwicklers beide Berechtigungen umfasst. Die technische Prüfung ist einfach: Kann ein Konto allein ein Artefakt signieren, ohne dass eine zweite Identität beteiligt ist? Wenn ja, handelt es sich um eine Lücke in Phase 2, die durch Werkzeuge der Phase 3 behoben werden muss.

Isolierung bauen

Dies ist die Kontrollmöglichkeit, die der Build-Umgebung von 3CX fehlte, und sie wird bei den meisten Reifegrad-Selbstbewertungen vernachlässigt, da sie vorgelagert zum eigentlichen Signaturvorgang liegt. Build-Isolation bedeutet, dass die Umgebung, die das Artefakt erzeugt, temporär und einmalig verwendbar ist – kein persistenter Build-Server, den ein kompromittierter Build-Lauf für jeden nachfolgenden Build kontaminieren kann. Es handelt sich um eine Kontrolle der Build-Pipeline, nicht der Signaturplattform. Genau deshalb wird sie bei einer auf Signaturen fokussierten Reifegradbewertung leicht übersehen. Wie SLSA Level 3 diese Anforderung formalisiert, erfahren Sie unter „Stärkung der Lieferkettensicherheit mit SLSA Level 3 und Codesignatur“ .

Die vier Stufen der Reife von Codesignaturen

Phase 1: Ad hoc – Unterzeichnung ohne Struktur

In der ersten Phase findet die Codesignierung in den meisten Organisationen zwar statt, wird aber nicht als eigenständiges System verwaltet. Dies umfasst:

• Ein oder wenige Entwickler besitzen das Codesignaturzertifikat und den privaten Schlüssel, die oft auf einem lokalen Rechner, einem USB-Token oder als Datei auf einem gemeinsam genutzten Build-Server gespeichert sind.
• Es gibt keine formale Richtlinie, die festlegt, wer zur Unterzeichnung berechtigt ist, was unterschrieben werden kann oder unter welchen Bedingungen eine Unterzeichnung erfolgen soll.
• Das Ablaufdatum von Zertifikaten wird informell erfasst, je nachdem, ob sich ein Entwickler daran erinnert (oder auch nicht), und die Erneuerung erfolgt reaktiv, oft ausgelöst durch einen Signierungsfehler anstatt durch proaktives Management.
• Auf die Frage „Was haben Sie im letzten Quartal unterschrieben?“ müsste man, sofern diese Protokolle und der Prüfpfad überhaupt existieren, manuell in den Bauprotokollen suchen.
• Die Signierung ist ein manueller Schritt, der von einem Entwickler bei der Vorbereitung einer Veröffentlichung durchgeführt wird und nicht in eine automatisierte Pipeline integriert ist.
• Es gibt keinen Plan für den Fall, dass das Zertifikat kompromittiert wird oder der Entwickler, der den Signaturschlüssel besitzt, das Unternehmen verlässt.

In dieser Phase ist die Signaturinfrastruktur im Wesentlichen ungeschützt. Private Schlüssel an softwareseitig zugänglichen Orten sind für jeden Angreifer angreifbar, der Zugriff auf den Entwicklerarbeitsplatz oder den Build-Server erlangt. Es gibt keine Funktionstrennung; dieselbe Person, die den Code schreibt, kann ihn ohne unabhängige Prüfung signieren. Signaturvorgänge sind nicht transparent, sodass unautorisierte Signaturen unentdeckt bleiben. Und da keine dokumentierten Richtlinien existieren, gibt es keine Grundlage für Audits.

Genau diese Umgebung nutzten Angreifer bei den Angriffen auf SolarWinds und 3CX aus. Es handelte sich nicht um ausgeklügelte Zero-Day-Angriffe auf die kryptografischen Algorithmen, sondern um ungeschützten Zugriff auf den Signierungsschritt in einer unüberwachten Build-Umgebung.

Phase 2: Definiert – Richtlinien existieren, aber es bleiben Lücken bestehen

Organisationen der Stufe 2 haben erkannt, dass die Ad-hoc-Codesignierung ein Risiko darstellt und haben Maßnahmen ergriffen, um sie zu formalisieren. Es existiert ein Richtliniendokument, und die Schlüssel werden sicherer gespeichert. Die Praktiken werden jedoch nicht konsequent durchgesetzt, und es bestehen weiterhin Lücken, insbesondere in den Bereichen Automatisierung, Auditabdeckung und Zertifikatslebenszyklusmanagement. Diese Stufe umfasst Folgendes:

• Es existiert eine schriftliche Richtlinie zur Codesignierung, die die Anforderungen an die Schlüsselspeicherung, die Berechtigung zum Signieren und die Verwaltung von Zertifikaten beschreibt. Die Einhaltung dieser Richtlinie ist jedoch uneinheitlich, da sie eher durch Sensibilisierung und Konventionen als durch technische Kontrollen durchgesetzt wird.
• Die privaten Schlüssel wurden von den Entwicklerrechnern entfernt. Sie können auf USB-Hardware-Tokens gespeichert werden, die dem FIPS 140-2 Level 2-Standard entsprechen. CA / Browser-Forum Dies stellt zwar eine Anforderung dar, bringt aber logistische Herausforderungen mit sich, insbesondere im Hinblick auf die neue Gültigkeitsdauer der Zertifikate von 460 Tagen, bei der die Token etwa alle 15 Monate ersetzt werden müssen.
• Es gibt eine Zugriffskontrolle, die nicht jedem das Signieren erlaubt, und bestimmte Zertifikate sind für spezifische Umgebungen (Entwicklung vs. Produktion) vorgesehen. Diese Kontrolle ist jedoch nicht detailliert genug und wird nicht auf technischer Ebene durchgesetzt; sie beruht darauf, dass Entwickler dokumentierte Verfahren befolgen.
• Das Zertifikatsinventar existiert in irgendeiner Form, zum Beispiel als Tabellenkalkulation, als gemeinsam genutzte Kalendererinnerung oder als Ticket in einem Projektmanagementsystem, wird aber manuell gepflegt und ist anfällig dafür, zu veralten.
• Bei einigen Produkten kann die Signierung teilweise in die Build-Pipelines integriert werden, bei anderen, insbesondere bei älteren Produkten oder Produkten, die von kleineren Teams verwaltet werden, sind jedoch weiterhin manuelle Signierungsschritte erforderlich.
• Es gibt zwar einige Audit-Protokolle, in denen Signaturereignisse in Build-Protokollen erfasst werden, diese sind jedoch nicht zentralisiert, werden nicht aktiv überwacht und dienen nicht der Erkennung von Anomalien.

Das Hauptrisiko in Phase 2 liegt in der Diskrepanz zwischen Richtlinie und Praxis. Richtlinien, die nicht durchgesetzt werden, bieten keine wirklichen Kontrollmechanismen. Wenn eine Richtlinie beispielsweise besagt, dass „Schlüssel nicht auf Entwickler-Workstations gespeichert werden dürfen“, ein Entwickler aber dennoch aus Bequemlichkeit eine Schlüsseldatei auf seinen Laptop kopieren kann, vermittelt die Richtlinie trügerische Sicherheit. Ebenso ist ein Zugriffskontrollmodell, das darauf beruht, dass dokumentierte Verfahren befolgt werden, sowohl anfällig für interne Bedrohungen als auch für externe Angriffe.

Phase 3: Verwaltet – Zentralisiert, kontrolliert und geprüft

In Phase 3 hat sich die Codesignierung von einer dokumentierten Richtlinie zu einer technisch durchgesetzten, zentral verwalteten Disziplin entwickelt. Die Kontrollen sind nicht nur schriftlich festgehalten, sondern in Infrastruktur und Systemen implementiert. Der Zugriff wird durch rollenbasierte Zugriffskontrolle (RBAC) geregelt, die in einer Signaturplattform mit Schlüsseln in HSMs und nicht in Token konfiguriert und durchgesetzt wird. Zudem verfügt sie über ein umfassendes und aktiv überwachtes Audit-Trail.

• Private Signaturschlüssel werden intern generiert und verlassen niemals das System. FIPS 140-2 Level 3 zertifiziert Hardware-SicherheitsmoduleDas physische oder Cloud-basierte HSM wird vom Sicherheitsteam verwaltet und nicht von einzelnen Entwicklern. Der Schlüsselexport ist auf HSM-Richtlinienebene technisch deaktiviert.
• Eine zentrale Signaturplattform setzt eine rollenbasierte Zugriffskontrolle durch, wobei festgelegte Rollen mit definierten Berechtigungen regeln, wer einen Signaturvorgang anfordern kann, wer ihn genehmigen muss und welche Artefakte mit welchem ​​Zertifikat signiert werden können.  
• Das Lebenszyklusmanagement von Code-Signatur-Zertifikaten erfolgt systematisch. Alle Signaturzertifikate werden mit Ablaufdatum, zugeordneten Inhabern sowie zugehörigen Produkten und Pipelines in einem Managementsystem und nicht in einer Tabellenkalkulation erfasst. Benachrichtigungen zur Verlängerung werden automatisiert und rechtzeitig vor Ablauf der Zertifikate versendet.
• Die Signierung ist in die CI/CD-Pipelines für alle Produktionsartefakte integriert und stellt eine kontrollierte, richtlinienbasierte Phase in der Release-Pipeline dar, keinen manuellen Schritt, der von einem Entwickler initiiert wird. Die Zeitstempelung gemäß RFC 3161 wird bei allen Signierungsvorgängen konsequent angewendet.
• Jeder Signiervorgang erzeugt einen unveränderlichen Eintrag im Audit-Log, der den Hash des Artefakts, das verwendete Zertifikat, den Zeitstempel, die anfragende Identität und die Genehmigungskette erfasst. Die Logs werden zentral verwaltet, aktiv überprüft, und anomale Signiervorgänge generieren Echtzeitwarnungen.
• Es gibt einen dokumentierten Notfallplan für den Fall einer Kompromittierung von Signaturschlüsseln. Darin ist festgelegt, welche Schlüssel über Softwaremechanismen widerrufen und ersetzt werden können, welche einen Hardwareaustausch erfordern und wie der Kommunikations- und Abhilfezeitplan aussieht.

In Phase 3 ist die Signaturinfrastruktur äußerst missbrauchssicher. Ein Angreifer, der ein Entwicklerkonto kompromittiert, kann gesperrt und an der Durchführung von Signaturvorgängen gehindert werden. Ein Insider, der versucht, ein nicht autorisiertes Artefakt zu signieren, löst eine Anomaliewarnung aus. Ein Zertifikat, dessen Ablaufdatum bald erreicht ist, initiiert einen automatisierten Verlängerungsprozess, anstatt stillschweigend abzulaufen und einen Produktionsausfall zu verursachen. Dank eines lückenlosen Prüfprotokolls können alle Signaturvorgänge überprüft, nachverfolgt und untersucht werden.

Phase 4: Optimiert – Automatisiert, ausfallsicher und zukunftssicher

Organisationen auf diesem Niveau haben nicht nur strenge Kontrollmechanismen implementiert, sondern ein Signaturprogramm aufgebaut, das sich kontinuierlich verbessert, proaktiv auf Branchenveränderungen reagiert und so konzipiert ist, dass es auch zukünftigen Entwicklungen standhält, einschließlich der Migration zur Post-Quanten-Kryptographie und der fortlaufenden regulatorischen Weiterentwicklung.

• Die Signaturinfrastruktur ist vollständig automatisiert; Zertifikatserkennung, -erneuerung, -bereitstellung und -widerruf werden von integrierten Systemen ohne manuelles Eingreifen abgewickelt.
• Die Organisation hat Krypto-Agilität in ihrer Signaturinfrastruktur implementiert. Algorithmus- und Schlüssellängenmigrationen können für die gesamte Zertifikatsflotte durchgeführt werden, ohne dass einzelne Pipeline-Aktualisierungen oder manuelle Neukonfigurationen erforderlich sind.
• Postquantenkryptographie Die Signierung befindet sich in der Produktion oder in der aktiven Pilotphase für Artefakte mit langem Lebenszyklus. NIST hat Algorithmen wie ML-DSA finalisiert (FIPS204), SLH-DSA (FIPS205), und LMS (NIST SP 800-208) als anerkannte Post-Quanten-Signaturalgorithmen.  
• Das Codesignaturprogramm ist in den umfassenderen Sicherheitsrahmen der Organisation für die Lieferkette eingebunden und integriert sich in die Prozesse zur Generierung von Software-Stücklisten (SBOM), zur Nachverfolgung der Binärherkunft und zum Schwachstellenmanagement.
• Die Organisation führt regelmäßig Angriffstests ihrer Signaturinfrastruktur durch, beispielsweise Red-Team-Übungen, bei denen versucht wird, RBAC-Kontrollen zu umgehen, nicht autorisierte Signaturereignisse einzuführen oder Schlüsselmaterial zu extrahieren, um zu überprüfen, ob die Kontrollen unter realistischen Angriffsbedingungen wie vorgesehen funktionieren.
• Die Notfallpläne für Sicherheitslücken werden in Übungen eingeübt, wobei für jede Kategorie von Signaturschlüsseln und Zertifikaten dokumentierte Wiederherstellungszeitvorgaben festgelegt werden.

In Phase 4 schützt das Signaturprogramm nicht nur vor bekannten Angriffsmustern, sondern ist architektonisch widerstandsfähig gegen zukünftige Angriffe. Der Übergang zur Post-Quanten-Technologie, der für die meisten Organisationen Ende der 2020er-Jahre erhebliche Infrastrukturmaßnahmen erfordern wird, ist bereits im Gange. Regulatorische Änderungen, die nachweisbare Compliance-Nachweise verlangen, wie z. B. die NIST SSDF-Zertifizierung, Audit-Logs für Softwareverträge des Bundes und branchenspezifische Anforderungen, können anhand von Betriebsdaten erfüllt werden, anstatt nachträgliche Dokumentation zu erfordern.

Selbstbewertungsbogen

Bewerten Sie jede Dimension anhand der Stufe, die der aktuellen Praxis am besten entspricht, nicht der Stufe, die Sie anstreben. Seien Sie präzise: „Wir haben RBAC“ zählt nur dann als Stufe 3, wenn es formal durchgesetzt wird und die Funktionstrennung abdeckt, nicht nur dokumentiert ist.

Abmessungen	Phase 1 (Ad-hoc)	Phase 2 (Definiert)	Stufe 3 (Managed)	Stufe 4 (Optimiert)
Schlüsselverwahrung	Lokaler Rechner oder freigegebene Datei	Hardware-Token, einzeln verwahrt	HSM, Export deaktiviert	HSM mit automatisierter Rotation und Krypto-Agilität
Zugriffskontrolle	Keine Einschränkung	Informell, verfahrensbasiert	Technisch durchgesetzte rollenbasierte Kontrolle	RBAC plus geübte Trennungstests
Widerruf	Kein Plan	Dokumentiert, aber ungetestet	Geprüfter Plan, Zuordnung von Artefakt zu Zertifikat existiert	Eingeübt mit festgelegten Wiederherstellungszeitvorgaben
Isolierung aufbauen	Persistenter, gemeinsam genutzter Build-Server	Persistenter Server, einige Zugriffshärtungsmaßnahmen	Isoliert pro Build, manuell überprüft	Standardmäßig ephemer, SLSA-konform
Audit-Trail	Keine oder nur informelle Bauprotokolle	Protokolle existieren, sind aber nicht zentralisiert.	Zentralisiert, unveränderlich, aktiv überprüft	Integration mit SIEM und Anomaliewarnung

Wie man die Bewertung durchführt

1. Bewerten Sie jede Dimension in der obigen Tabelle unabhängig voneinander; die meisten Organisationen befinden sich auf verschiedenen Dimensionen in unterschiedlichen Stadien, was normal ist und aussagekräftiger als eine einzige Gesamtbewertung.
2. Ermitteln Sie die Dimension mit der niedrigsten Punktzahl, nicht den Durchschnitt; ein Programm der Stufe 3 mit Widerrufsbereitschaft der Stufe 1 birgt das Risiko eines Vorfalls der Stufe 1.
3. Überprüfen Sie jede Bewertung anhand einer externen Frist, die die Dringlichkeit unterstreicht: Die Gültigkeitsdauer des Zertifikats von 460 Tagen wirkt sich auf die Bewertung der Schlüsselverwaltung und -rotation aus; die bevorstehenden NIST SSDF-Attestierungsanforderungen wirken sich auf die Bewertung des Prüfpfads und der Richtlinien aus.
4. Erstellen Sie einen Fahrplan, der zuerst die Dimension mit der niedrigsten Punktzahl abschließt, nicht die einfachste; ein schneller Erfolg bei einer Dimension, die sich bereits in Phase 3 befindet, reduziert Ihr tatsächliches Risiko nicht.

Einschränkungen

Ein Reifegrad-Score ist eine Selbsteinschätzung, kein Prüfungsergebnis, und seine Genauigkeit hängt von der Ehrlichkeit der Bewertenden ab. Eine Überprüfung der technischen Kontrollen oder eine Red-Team-Übung (Bestandteil von Phase 4) deckt Schwachstellen auf, die eine Selbsteinschätzung nicht erkennt. Das Erreichen von Phase 3 oder 4 macht eine Organisation nicht immun gegen Angriffe, sondern erschwert lediglich die Ausnutzung bestimmter, bekannter Schwachstellen (z. B. gemeinsam genutzte Schlüssel, nicht durchgesetzte rollenbasierte Zugriffskontrolle, unüberwachte Signaturen). Neue oder unerwartete Angriffstechniken bleiben unabhängig von der Phase möglich.

Wie kann CodeSign Secure von Encryption Consulting helfen?

CodeSign Secure ist die zentrale, richtlinienbasierte Codesignatur-Plattform von Encryption Consulting. Sie unterstützt Unternehmen in jeder Phase ihrer Entwicklung hin zu mehr Reifegraden und bietet die Infrastruktur und Kontrollen, die für Stufe 3 erforderlich sind, sowie die erweiterten Funktionen für Stufe 4.

CodeSign Secure bietet Organisationen, die bisher nur ad hoc oder teilweise definierte Signaturverfahren anwenden, einen direkten Weg zu den grundlegenden Kontrollmechanismen, die Stufe 3 kennzeichnen:

HSM-gestütztes Schlüsselmanagement: Private Signaturschlüssel werden intern generiert und verlassen niemals FIPS 140-2 Level 3-zertifizierte Hardware-Sicherheitsmodule. CodeSign Secure ist mit Thales Luna, Entrust nCipher, Utimaco, Securosys sowie Cloud-HSMs von AWS und Azure kompatibel. Der Schlüsselexport ist auf Richtlinienebene deaktiviert. Das USB-Token-Modell mit all seinen Herausforderungen in Bezug auf Erneuerung und Zugriffsverwaltung wird durch eine zentrale, API-zugängliche Signaturinfrastruktur ersetzt.

Durchsetzung von RBAC und Genehmigungsworkflows: Das rollenbasierte Zugriffskontrollmodell von CodeSign Secure ermöglicht Administratoren die präzise Definition, wer eine Signatur anfordern darf, was signiert werden darf, welches Zertifikat verwendet wird und welche Autorisierungsschritte vor der Signatur abgeschlossen sein müssen. Diese Kontrollen werden programmatisch durchgesetzt und sind nicht von der Einhaltung dokumentierter Verfahren durch Benutzer abhängig.

Verwaltung von Code-Signatur-Zertifikaten: Die Plattform führt ein zentrales Verzeichnis aller verwalteten Zertifikate. Eine automatische Benachrichtigung über anstehende Verlängerungen ist konfiguriert, um den Teams im Rahmen der neuen Gültigkeitsdauer von 460 Tagen ausreichend Vorlaufzeit zu geben.

Für Organisationen, die bereits grundlegende Kontrollmechanismen eingerichtet haben und auf Optimierung und Stufe 4 hinarbeiten:

CI/CD-Pipeline-Integration: CodeSign Secure lässt sich nativ in Azure DevOps , Jenkins , GitLab CI und andere gängige Pipeline-Systeme integrieren. Signaturvorgänge werden über eine API gesteuert und durch die Integration mit Signaturtools von Drittanbietern unter Einhaltung der RFC-3161-Zeitstempelung ermöglicht.

Unterstützung für Post-Quanten-Kryptographie: CodeSign Secure v3.02 bietet produktionsreife Unterstützung für ML-DSA (FIPS 204, verfügbar auf den Sicherheitsstufen ML-DSA-44, ML-DSA-65 und ML-DSA-87) als abtrennbare Signaturen und ermöglicht es Unternehmen, mit dem Übergang zu PQC zu beginnen.

Audit-Protokollierung und Berichterstellung: Jedes Signaturereignis in CodeSign Secure erzeugt einen unveränderlichen Protokolleintrag, der Artefakt-Hash, Zertifikat, Zeitstempel, anfragende Identität und Genehmigungskette erfasst. Die Protokolle werden über Opentelemetry in SIEM-Plattformen wie Splunk und Grafana Loki integriert, um Anomalien in Echtzeit zu erkennen.

Egal, ob Sie bei Phase 1 beginnen und schnell grundlegende Kontrollen einrichten müssen oder sich in Phase 3 befinden und auf vollständige Automatisierung und Post-Quanten-Bereitschaft hinarbeiten, CodeSign Secure bietet die Infrastruktur, um diesen Weg zu unterstützen.

Fazit

Reife im Bereich der Codesignatur ist kein Ziel, sondern ein Prozess, der erreicht werden muss. Jede Organisation befindet sich auf diesem Weg, und jede Verbesserungsstufe reduziert Risiken und operative Gefährdungen spürbar.

Wir bei Encryption Consulting haben CodeSign Secure entwickelt , um diesen Übergang in jeder Phase zu vereinfachen. Die Frage „Sind Ihre Codesignierungsprozesse ausgereift?“ lässt sich nicht einfach mit Ja oder Nein beantworten. Aber sie erfordert konkrete Maßnahmen: Ermitteln Sie Ihren aktuellen Stand, identifizieren Sie die Komponenten mit den größten Entwicklungslücken und erstellen Sie einen priorisierten Fahrplan, um diese zu schließen.

Im Jahr 2026 wird die Dringlichkeit dieses Fahrplans durch Branchenentwicklungen wie die 460-tägige Gültigkeitsdauer von Zertifikaten, die ein manuelles Lebenszyklusmanagement unmöglich macht, Lieferkettenangriffe, die weiterhin schwache Signatur-Governance ausnutzen, die NIST SSDF-Anforderungen, die nachweislich sichere Entwicklungspraktiken fordern, und den bevorstehenden Übergang nach der Quantencomputertechnologie, der Infrastrukturänderungen erfordern wird, mit denen die meisten Organisationen noch nicht begonnen haben, definiert.

Häufig gestellte Fragen

Kann eine Organisation hinsichtlich verschiedener Kontrollmechanismen unterschiedliche Reifegrade aufweisen?

Ja, und dies ist eher der Normalfall als die Ausnahme. Ein Programm verfügt oft über eine starke, HSM-gestützte Schlüsselverwaltung (Phase 3), während sein Widerrufsplan nie getestet wurde (Phase 2) oder seine Build-Umgebung nicht isoliert ist (Phase 1 oder 2). Bewerten Sie jede Dimension einzeln, anstatt eine Gesamtzahl zu vergeben.

Reicht eine schriftliche Richtlinie zur Codesignierung aus, um Stufe 3 zu erreichen?

Nein. Eine schriftliche Richtlinie, die technisch nicht durchgesetzt wird und deren Umgehung somit nicht verhindert wird, ist ein Merkmal von Stufe 2. Stufe 3 erfordert die Implementierung von Kontrollmechanismen in der Infrastruktur (HSM-Richtlinie, RBAC-Durchsetzung, automatisierte Zertifikatsverfolgung), anstatt sich darauf zu verlassen, dass Mitarbeiter dokumentierte Verfahren befolgen.

Warum war die Gebäudeisolation nicht Teil der ursprünglichen acht Dimensionen?

Die Build-Isolation ist dem eigentlichen Signiervorgang vorgelagert, also in der Build-Pipeline und nicht auf der Signierplattform selbst. Genau deshalb wird sie bei Reifegradanalysen mit Fokus auf Signierung oft vernachlässigt. Es ist die Kontrollmöglichkeit, die der Build-Umgebung von 3CX fehlte, und sie muss in jede Bewertung einfließen, die diesen Fehlerfall tatsächlich verhindern und nicht nur die Schlüsselverwaltung verbessern will.

Worin besteht der Unterschied zwischen diesem Reifegradmodell und einer Checkliste mit Best Practices?

Eine Checkliste listet die zu übernehmenden Praktiken auf; ein Reifegradmodell analysiert Ihren aktuellen Stand in Bezug auf jede einzelne und zeigt den nächsten konkreten Schritt auf. So konzentriert man sich zunächst auf die Dimension mit der niedrigsten Punktzahl, anstatt die Anstrengungen gleichmäßig auf eine flache Liste zu verteilen. Die flache Checklistenversion finden Sie unter „ Best Practices für die Code-Signierung im SDLC“.