Codesignierung 101: Absicherung Ihrer Software-Lieferkette

Jedes Mal, wenn Sie ein Software-Update herunterladen, eine Browsererweiterung installieren oder eine Unternehmensanwendung ausführen, setzen Sie großes Vertrauen in diese Software. Doch woher wissen Sie wirklich, dass sie nicht manipuliert wurde – dass sie tatsächlich vom angegebenen Hersteller stammt und nicht von einem Angreifer? Die Antwort lautet: Codesignatur. 

Als führende Sicherheitsorganisationen haben Unternehmen jahrelang die Anwendungssicherheit, Cloud-Kontrollen und Identitätsmanagement verbessert. Doch einer der am meisten vernachlässigten Vertrauensanker im Softwarelebenszyklus ist nach wie vor die Codesignatur. Viele stehen weiterhin vor demselben Problem: Sie investieren massiv in sichere Entwicklung, lassen den finalen Release-Prozess aber fragmentiert, manuell und schwer steuerbar.  

Die zunehmende Verbreitung von Cyberangriffen, die Software-Schwachstellen ausnutzen, erfordert robuste Mechanismen zur Gewährleistung der Authentizität und Sicherheit von Softwarecode. Durch die Implementierung von Codesignaturen können Entwickler Vertrauen bei den Nutzern aufbauen und ihnen versichern, dass die installierte Software legitim und frei von Schadsoftware ist. Mit der Weiterentwicklung der Branche gewinnen neue Verfahren an Bedeutung – wie beispielsweise die schlüssellose Signatur (bei der kurzlebige Zertifikate langlebige private Schlüssel ersetzen und somit die Schlüsselverwaltung vollständig überflüssig machen). Software-Stückliste (SBOM) Die Integration (die ein maschinenlesbares Inventar aller Komponenten eines Softwareartefakts bereitstellt) verändert die Gestaltung umfassender Signaturstrategien grundlegend. Um ihre entscheidende Rolle zu verstehen, ist es unerlässlich, die komplexen Prozesse zu untersuchen, insbesondere jene, die Transparenz, Gültigkeit und Sicherheit betreffen. 

Was ist Codesignierung und warum ist sie wichtig? 

Im Kern ist die Codesignierung der Prozess des Anwendens eines Digitale Unterschrift für Software – sei es eine ausführbare Datei, ein Skript, ein Treiber, ein Firmware-Image oder ein Container. Diese Signatur erfüllt zwei wesentliche Zwecke: 

1. Authentifizierung — Es beweist, wer die Software erstellt oder veröffentlicht hat. 
2. Integrität — Es garantiert, dass der Code seit seiner Unterzeichnung nicht verändert wurde. 

Laut demselben CleanStart-Bericht werden im Jahr 2025 35 % der Lieferkettenangriffe auf kompromittierte Softwareabhängigkeiten zurückzuführen sein, 22 % zielten auf CI/CD-Pipelines und Build-Umgebungen ab und 20 % betrafen manipulierte oder nicht verifizierte Container-Images. Sie stellten außerdem fest, dass Angriffe auf die Software-Lieferkette Weltweit haben sich die Verluste bis 2025 mehr als verdoppelt und erreichen 60 Milliarden US-Dollar. Über 70 % der Unternehmen berichten in diesem Jahr von mindestens einem Sicherheitsvorfall im Zusammenhang mit der Lieferkette. Besonders alarmierend ist, dass Angreifer nicht mehr nur die Perimeter angreifen, sondern sich während des Produktionsprozesses selbst Zugang verschaffen.  

Beim Signieren von Code ist es wichtig zu wissen, dass die Signatur nur so lange gültig ist wie das Signaturzertifikat. Software ist jedoch oft länger gültig als ihr Zertifikat. Ein vertrauenswürdiger Zeitstempel, der von einer RFC-3161-konformen Timestamp Authority (TSA) zum Zeitpunkt der Signierung ausgestellt wird, verknüpft die Signatur kryptografisch mit einem bestimmten Zeitpunkt. Das bedeutet, dass die Signatur auch nach Ablauf des Signaturzertifikats gültig bleibt – denn der Zeitstempel beweist, dass die Signierung stattfand, als das Zertifikat noch gültig war. Ohne Zeitstempel könnte Ihre gesamte signierte Version mit dem Ablauf des Zertifikats ihre Vertrauenswürdigkeit verlieren. 

Ein weiterer wichtiger Punkt ist, dass bei Kompromittierung eines Signaturschlüssels das zugehörige Zertifikat unverzüglich widerrufen werden muss. Zertifikatssperrlisten (CRLs) sind regelmäßig veröffentlichte Listen widerrufener Zertifikate. Online Certificate Status Protocol (OCSP) Es bietet Echtzeit-Prüfungen auf Zertifikatssperrung. Betriebssysteme und Sicherheitstools nutzen diese Mechanismen, um vor dem Vertrauen in eine Signatur zu überprüfen, ob ein Zertifikat gesperrt wurde. Ein robustes Codesignaturprogramm muss einen getesteten Sperrplan enthalten – nicht nur die Möglichkeit zur Sperrung, sondern auch einen dokumentierten Prozess für Sperrung, Neusignierung und schnelle Weiterverteilung betroffener Artefakte. 

Die Durchsetzung von Plattformrichtlinien fügt eine weitere Ebene der Vertrauensvalidierung hinzu. Unter Windows bewertet SmartScreen die Reputation signierter ausführbarer Dateien. EV-signierte Software mit etablierter Reputation umgeht die Warnung „Unbekannter Herausgeber“, die Nutzer abschrecken und das Vertrauen untergraben kann. Unter macOS prüft Gatekeeper, ob Anwendungen mit einem von Apple ausgestellten Entwickler-ID-Zertifikat signiert sind und die Notarisierung – Apples automatisierten Malware-Scan – bestanden haben. Unter Linux überprüfen Paketmanager wie apt und dnf die GPG-Signaturen von Paketen vor der Installation. Das Verständnis dieser plattformweiten Kontrollen hilft Sicherheitsteams bei der Entwicklung von Signatur-Workflows, die eine reibungslose und vertrauenswürdige Softwarebereitstellung ermöglichen. 

Ohne Codesignatur haben Benutzer und Systeme keine zuverlässige Möglichkeit, legitime Software von bösartigen Nachahmungen zu unterscheiden. Man sollte sich jedoch auch darüber im Klaren sein, dass Codesignatur keine Garantie für die Sicherheit, Unbedenklichkeit oder Fehlerfreiheit von Software bietet. Eine gültige Signatur beweist Integrität und Herkunft, nicht Qualität oder Absicht. Selbst wenn ein Signaturschlüssel kompromittiert wird oder fehlerhafter Code von einem legitimen Herausgeber signiert wird, kann die Signatur dennoch erfolgreich validiert werden. Für Entscheidungsträger ist diese Unterscheidung wesentlich: Codesignatur ist eine notwendige Kontrollmaßnahme, muss aber Hand in Hand mit sicherer Entwicklung, Härtung der Entwicklungspipeline, Zugriffskontrolle und Überwachung erfolgen. 

Anfang 2025 wurden Cyberkriminelle dabei ertappt, wie sie Microsofts Trusted Signing-Dienst missbrauchten, um Schadsoftware mit kurzlebigen, dreitägigen Zertifikaten zu signieren. Dadurch wirkten die Schadprogramme wie vertrauenswürdig und umgingen herkömmliche Sicherheitskontrollen. Die Zertifikate waren technisch gültig und korrekt verifiziert; das Problem lag nicht in der Infrastruktur, sondern darin, dass Angreifer Zugriff darauf erlangt hatten. Dies verdeutlicht die zentrale Einschränkung der Codesignierung: Eine gültige Signatur beweist lediglich, dass jemand mit entsprechenden Berechtigungen die Software erstellt hat – nicht, dass die Software sicher ist. Die Signaturinfrastruktur muss gehärtet, der Zugriff streng kontrolliert und verdächtige Signaturaktivitäten nahezu in Echtzeit erkannt werden, denn sobald die Signaturpipeline kompromittiert ist, wird die Signatur zur mächtigsten Waffe des Angreifers. 

Die kryptographische Stiftung 

Um die Codesignierung wirklich zu verstehen, benötigen Sie ein grundlegendes Verständnis von Public-Key-Infrastruktur (PKI) und asymmetrische Kryptographie. 

Asymmetrische Schlüsselpaare 

Jede Codesignatur-Identität basiert auf einem Schlüsselpaar: 

• A privater Schlüssel — wird vom Softwarehersteller geheim gehalten. Dies dient dazu erstellen die Unterschrift. 
• A Öffentlicher Schlüssel — offen geteilt. Dies wird verwendet, um überprüfen die Unterschrift. 

Die mathematische Beziehung zwischen diesen beiden Schlüsseln ist unidirektional: Man kann mit dem privaten Schlüssel signieren und mit dem öffentlichen Schlüssel verifizieren, aber man kann den privaten Schlüssel nicht vom öffentlichen Schlüssel ableiten. Die Wahl des Algorithmus ist daher von entscheidender Bedeutung. Die drei heute am häufigsten verwendeten Algorithmen für die Codesignierung sind: 

RSA (Rivest–Shamir–Adleman) — Der etablierteste Algorithmus, typischerweise verwendet mit 2048-Bit- oder 4096-Bit-Schlüsseln. RSA wird von allen Betriebssystemen und Tools universell unterstützt, aber aufgrund der größeren Schlüssellängen ist es langsamer als moderne Alternativen bei vergleichbarem Sicherheitsniveau. 

ECDSA (Elliptic Curve Digital Signature Algorithm) — Nutzt elliptische Kurvenmathematik, um mit deutlich kleineren Schlüssellängen die gleiche Sicherheit wie RSA zu erreichen. Ein 256-Bit-Verschlüsselungssystem ECDSA Der P-256-Schlüssel bietet annähernd die gleiche Sicherheit wie ein 3072-Bit-RSA-Schlüssel, ermöglicht aber eine schnellere Signaturerstellung und -verifizierung. ECDSA wird in leistungssensiblen und ressourcenbeschränkten Umgebungen zunehmend bevorzugt. 

EdDSA (Edwards-Kurven-Algorithmus für digitale Signaturen) EdDSA ist die neueste der drei Methoden und basiert auf verdrehten Edwards-Kurven (meist Ed25519). Sie bietet hervorragende Leistung, hohe Sicherheit und ist resistent gegen bestimmte Seitenkanalangriffe, die ECDSA-Implementierungen beeinträchtigen können.  

Der Unterzeichnungsprozess  

1. Hashing: Der Softwarehersteller prüft den Code mithilfe einer kryptografischen Hash-Funktion – mindestens SHA-256, da SHA-1 kryptografisch unsicher und veraltet ist. NIST SHA-256 ist seit 2011 in Gebrauch (und seit 2016 von den großen Zertifizierungsstellen für die Codesignierung verboten). Es erzeugt einen „Fingerabdruck“ des Codes fester Länge – den sogenannten Digest. Schon die Änderung eines einzigen Bits im Code führt zu einem völlig anderen Hashwert. 
2. Signieren des Hash: Der Herausgeber verschlüsselt den Hashwert mit seinem privaten Schlüssel. Dieser verschlüsselte Hashwert ist die digitale Signatur. 
3. Anbringen der Unterschrift: Die Unterschrift, zusammen mit dem Verleger Bescheinigung (welches den öffentlichen Schlüssel enthält) ist in der Software enthalten. 

Der Verifizierungsprozess 

Wenn ein Benutzer die Software herunterlädt und ausführt, wird das Betriebssystem oder das Sicherheitstool wie folgt ausgeführt: 

1. Extrahiert die Signatur und das Zertifikat aus der Datei. 
2. Validiert die Zertifikatskette, indem geprüft wird, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde, ob es nicht abgelaufen ist und ob es nicht widerrufen wurde (mittels CRL oder OCSP). 
3. Prüft den Zeitstempel, d. h. bestätigt, dass die Signatur angewendet wurde, als das Zertifikat noch aktiv war, und stellt so sicher, dass die Signatur auch nach Ablauf des Zertifikats gültig bleibt. 
4. Verwendet den öffentlichen Schlüssel im Zertifikat, um die Signatur zu entschlüsseln und den ursprünglichen Hash wiederherzustellen. 
5. Erstellt unabhängig Hashwerte für die heruntergeladene Software. 
6. Vergleicht die beiden Hashwerte. Stimmen sie überein, ist die Software intakt und stammt tatsächlich vom angegebenen Herausgeber. Stimmen sie nicht überein – Verifizierung fehlgeschlagen! Die Software wurde manipuliert. 

Die Rolle der Zertifizierungsstellen (CAs) 

Nun ist es entscheidend zu wissen und zu verstehen, was einen Angreifer daran hindert, einfach ein eigenes Schlüsselpaar zu erstellen und sich als Microsoft oder Adobe auszugeben. 

Das ist wo Zertifizierungsstellen (CAs) Kommen wir zur Sache. Eine Zertifizierungsstelle (CA) ist eine vertrauenswürdige Drittpartei (wie DigiCert, Sectigo oder GlobalSign), die Code-Signatur-Zertifikate erst nach Überprüfung der Identität des Antragstellers ausstellt. Die Signatur der CA auf dem Zertifikat verleiht ihm Gültigkeit. Die Vertrauensinfrastruktur reicht jedoch weit über eine einzelne CA hinaus. 

Root-CA vs. Intermediate-CA-Hierarchie 

Das PKI Das Vertrauensmodell ist hierarchisch aufgebaut. An der Spitze steht die Root-CA – eine hochsichere, oft offline betriebene Instanz, deren Zertifikat selbstsigniert ist und deren öffentlicher Schlüssel von Anbietern wie Microsoft, Apple und Mozilla direkt in Betriebssysteme und Browser eingebettet wird. Da die Kompromittierung einer Root-CA katastrophale Folgen hätte, werden die privaten Root-Schlüssel in voneinander getrennten HSMs (Heavy-Gap-Systemen) aufbewahrt und nur selten zur direkten Zertifikatsausstellung verwendet. 

Stattdessen stellen Stammzertifizierungsstellen (Root CAs) Zertifikate an Zwischenzertifizierungsstellen (Intermediate CAs, auch Subordinate CAs genannt) aus, die online sind und die tägliche Aufgabe der Ausstellung von Codesignaturzertifikaten an Herausgeber übernehmen. Dadurch entsteht eine Vertrauenskette: Stammzertifizierungsstelle → Zwischenzertifizierungsstelle → Herausgeberzertifikat. Bei der Überprüfung einer Signatur durchläuft das System diese Kette und verifiziert die Signatur jedes Zertifikats anhand seiner übergeordneten Zertifizierungsstelle bis hin zur vertrauenswürdigen Stammzertifizierungsstelle. 

Trust Stores 

Ihr Betriebssystem wird mit einem vorinstallierten Truststore ausgeliefert – einer Liste vertrauenswürdiger Stammzertifizierungsstellen (Root CA-Zertifikate). Windows verwendet das Microsoft Trusted Root Certificate Program, macOS und iOS den Truststore von Apple, und Linux-Distributionen greifen auf das Paket „ca-certificates“ zurück (oftmals aus dem Mozilla-Programm). Browser wie Chrome und Firefox können eigene Truststores unabhängig vom Betriebssystem verwalten. Wenn die Zertifikatskette eines Codesignaturzertifikats zu einer Stammzertifizierungsstelle im Truststore zurückverfolgt werden kann, gilt die Signatur als vertrauenswürdig. Kann die Kette nicht zu einer vertrauenswürdigen Stammzertifizierungsstelle zurückverfolgt werden, wird die Signatur abgelehnt. 

Signaturzertifikate für Extended Validation (EV) -Codes 

Nicht alle Code-Signatur-Zertifikate sind gleichwertig. Standardmäßige OV-Zertifikate (Organisationsvalidierung) erfordern zwar von der Zertifizierungsstelle die Überprüfung der rechtmäßigen Existenz der Organisation des Antragstellers, der Prüfprozess ist jedoch vergleichsweise unkompliziert. EV-Zertifikate (Erweiterte Validierung) hingegen erfordern ein deutlich strengeres Verfahren. 

• Nachweis der Rechtspersönlichkeit – die Organisation muss eine eingetragene juristische Person mit einwandfreiem Leumund in ihrem Zuständigkeitsbereich sein. 

• Physische Adresse und operative Existenz – die Zertifizierungsstelle überprüft den physischen Standort und die operative Präsenz der Organisation. 

• Identität des Zertifikatsanforderers – die Person, die das Zertifikat anfordert, muss als autorisierter Vertreter der Organisation verifiziert werden. 

• Telefonische Verifizierung – die Zertifizierungsstelle kontaktiert die Organisation über eine unabhängig verifizierte Telefonnummer, um die Anfrage zu bestätigen. 

• Überprüfung zur Bekämpfung von Geldwäsche und Sanktionen – die Organisation und ihre Verantwortlichen werden anhand von staatlichen und aufsichtsrechtlichen Überwachungslisten überprüft. 

Das Ergebnis ist ein Zertifikat mit deutlich höherer Identitätssicherheit. Unter Windows baut EV-signierte Software sofort eine SmartScreen-Reputation auf – die Warnung „Unbekannter Herausgeber“ wird umgangen –, da Microsoft größeres Vertrauen in die verifizierte Identität hinter dem Zertifikat hat. EV-Zertifikate erfordern außerdem, dass private Schlüssel in einem Hardware-Sicherheitsmodul (HSM), was die Hürde für den Schlüsseldiebstahl im Vergleich zu OV-Zertifikaten, die in Software gespeichert werden können, deutlich erhöht. 

Selbstsignierte Zertifikate Intern erstellte Zertifikate ohne Zertifizierungsstelle (CA) sind für interne Testumgebungen, in denen Sie die Vertrauensbasis vollständig kontrollieren, völlig ausreichend. Sie sollten jedoch niemals für öffentlich verteilte Software verwendet werden. Es fehlt die Vertrauenskette; Endbenutzersysteme erkennen sie nicht als legitim an, und sie bieten keine Garantie für die Identität des Herausgebers. 

Die Software-Lieferkette 

Bisher haben wir über die Signierung einer einzelnen Softwarekomponente gesprochen. Die moderne Softwareentwicklung ist jedoch weitaus komplexer. Ihr Produkt umfasst wahrscheinlich Folgendes: 

• Open-Source-Bibliotheken und -Pakete (npm, PyPI, Maven, NuGet usw.) 
• SDKs und Komponenten von Drittanbietern 
• CI/CD-Pipeline-Artefakte 
• Container-Images 
• Infrastruktur-als-Code-Skripte 
• Firmware und Treiber 
• Software-Stückliste (SBOM) 
• Container-Images und Docker-Artefakte 

Jeder dieser Punkte stellt ein potenzielles Einfallstor für einen Lieferkettenangriff dar, und Signaturstrategien müssen alle abdecken, nicht nur die finalen ausführbaren Dateien. Container-Images sollten mit Tools wie cosign signiert und bei der Bereitstellung verifiziert werden. Die Artefaktsignierung von Build-Ausgaben (JARs, Wheels) stellt sicher, dass das Ergebnis des Build-Systems dem erstellten Ergebnis entspricht. Die SBOM-Signierung fügt dem Inventar selbst eine zusätzliche Attestierungsebene hinzu und ermöglicht es nachgelagerten Nutzern, nicht nur die Software, sondern die vollständige Liste ihrer Bestandteile zu überprüfen. 

• Komplexität des Ökosystems

  Das Open-Source-Ökosystem steht heute unter intensiverer Beobachtung als je zuvor – und das aus gutem Grund. Die schiere Anzahl an Abhängigkeiten von Drittanbieterpaketen schafft eine enorme Angriffsfläche. Die meisten Unternehmensanwendungen binden Hunderte oder Tausende transitiver Abhängigkeiten (Pakete, die von anderen Paketen abhängen) ein, von denen viele von Einzelpersonen mit begrenzten Sicherheitsressourcen verwaltet werden.

  Der vierteljährliche Open-Source-Malware-Index von Sonatype verzeichnete im Jahr 2025 einen kontinuierlichen Anstieg: Im ersten Quartal wurden fast 18,000 neue Schadsoftwarepakete entdeckt, im dritten Quartal waren es 34,319 – ein Anstieg von 140 % gegenüber dem zweiten Quartal. Bis zum vierten Quartal 2025 identifizierte Sonatype unglaubliche 394,877 neue Open-Source-Malwarepakete in nur einem Quartal, vorwiegend bedingt durch automatisierte, sich selbst replizierende Kampagnen. Die Gesamtzahl der seit 2019 von Sonatype identifizierten Schadsoftwarepakete hat 877,000 überschritten.

• Bedrohungseskalation

  Noch besorgniserregender ist, dass 56 % der im ersten Quartal 2025 entdeckten Malware für Datenexfiltration entwickelt wurde. Ihr Hauptziel waren Entwicklerzugangsdaten, CI/CD-Geheimnisse und Cloud-API-Schlüssel, die an vorhersehbaren Orten auf Entwicklerrechnern gespeichert sind. Diese Daten sind, sobald sie erlangt wurden, der Schlüssel zur Kompromittierung einer gesamten Signaturpipeline. Ein Angreifer, der Zugriff auf ein CI/CD-Geheimnis oder Entwicklerzugangsdaten hat, kann potenziell Schadcode in den Build-Prozess einschleusen, ihn mit einem gültigen Schlüssel signieren und über offizielle Kanäle verbreiten – alles, ohne jemals das Netzwerk der Zielorganisation zu berühren.

Daher muss eine umfassende Codesignierungsstrategie die gesamte Kette abdecken, von den Open-Source-Paketen, die Sie verwenden, bis hin zu den Artefakten, die Sie erstellen und verteilen. 

Das SLSA-Framework 

Das von Google entwickelte SLSA-Framework (Supply Chain Levels for Software Artifacts) bietet ein gestaffeltes Modell zur Bewertung und Verbesserung der Lieferkettenintegrität. Es reicht von Stufe 1 (grundlegende Dokumentation) bis Stufe 4 (strengste Kontrollen). Die Codesignierung ist ein entscheidender Faktor für das Erreichen höherer SLSA-Stufen. Im Folgenden wird die praktische Bedeutung der einzelnen Stufen erläutert: 

SLSA Stufe 1Der Build-Prozess ist dokumentiert und skriptbasiert. Quellinformationen und Metadaten zur Erstellung der Artefakte sind verfügbar, aber nicht authentifiziert. Dies schafft eine Grundlage für die Nachvollziehbarkeit. 

SLSA Stufe 2Der Build-Prozess läuft auf einem gehosteten Build-Service (nicht nur auf dem Laptop eines Entwicklers), und der Quellcode wird vom Build-Service signiert. Das bedeutet, dass ein Angreifer den Build-Service kompromittieren müsste, nicht nur den Rechner eines Entwicklers, um die Herkunft zu fälschen. 

SLSA Stufe 3Der Build-Service bietet stärkere Isolationsgarantien, und die Ursprungsdaten enthalten Informationen über die Build-Umgebung. Der Quellcode muss aus einem Versionskontrollsystem stammen, und der Build-Prozess muss gesichert und geschützt sein. 

SLSA-Stufe 4: Erfordert eine Überprüfung aller Änderungen durch zwei Personen, einen reproduzierbaren Build und umfassende Informationen zum Quellcode. Auf dieser Ebene ist die gesamte Kette vom Quellcode bis zum Artefakt manipulationssicher und nachvollziehbar. 

Eine der wichtigsten und zugleich größten Herausforderungen moderner Codesignaturen ist deren Integration in automatisierte Build-Pipelines. Hier scheitern viele Unternehmen. Laut einer Studie aus dem Jahr 2025 überwachen derzeit weniger als 50 % der Unternehmen mehr als 50 % ihrer erweiterten Software-Lieferkette. Das bedeutet, dass Angreifer regelmäßig in Bereichen agieren, deren Existenz den Unternehmen gar nicht bewusst ist. 

Zu den häufigsten Fehlern gehören: 

• Speichern von privaten Schlüsseln in Umgebungsvariablen oder Konfigurationsdateien — Das ist ein schwerwiegender Fehler. Private Schlüssel, die in einer CI/CD-Umgebung im Klartext gespeichert werden, sind nur eine einzige Fehlkonfiguration der Zugriffskontrolle von einer vollständigen Kompromittierung entfernt.  
• Gemeinsame Nutzung von Signaturinformationen über Teams hinweg — Wenn alle Teams in Ihrer Organisation denselben Signaturschlüssel verwenden, könnte ein einziges kompromittiertes Entwicklerkonto zu böswillig signierten Releases führen. 
• Unterzeichnung zum falschen Zeitpunkt — Eine zu frühe Signierung im Verarbeitungsprozess bedeutet, dass ungetesteter Code signiert wird. Eine zu späte Signierung kann Lücken erzeugen, die es unsignierten Artefakten ermöglichen, systemübergreifend verbreitet zu werden. 
• Keine Schlüsselrotationsstrategie Signaturschlüssel sollten regelmäßig (mindestens jährlich und unmittelbar nach jedem Verdacht auf Kompromittierung) ausgetauscht werden. Viele Organisationen richten eine Signaturinfrastruktur ein und überprüfen diese anschließend nicht mehr, wodurch Schlüssel jahrelang veralten und potenziell gefährdet sind. 
• Keine Trennung der Aufgaben Die Funktionstrennung stellt sicher, dass ein kompromittiertes Entwicklerkonto nicht eigenmächtig Schadcode signieren und veröffentlichen kann. Beispielsweise sollte der Entwickler, der den Code schreibt, nicht dieselbe Person sein, die ihn ohne Überprüfung durch einen anderen Entwickler signiert und freigibt. 
• Mangelnde Durchsetzung der Unterzeichnungsrichtlinie Ohne verbindliche Richtlinien erfolgt die Signatur nach dem Zufallsprinzip. Teams signieren möglicherweise mit den falschen Zertifikaten, lassen die Zeitstempelung aus oder signieren in der falschen Build-Phase. Zentralisierte Signaturplattformen wie unsere CodeSign Secure setzen Richtlinien programmatisch durch und ermöglichen Benutzern die Kontrolle über ihre Signaturprozesse und -umgebungen. 
• Keine Korrelation der Audit-Logs Signierereignisse sollten protokolliert und diese Protokolle mit Ereignissen des Build-Systems korreliert werden. Ein unerwartetes Signierereignis außerhalb einer normalen Build-Pipeline ist ein starkes Indiz für eine Kompromittierung. 

Sie fragen sich vielleicht: „Warum sollten sich CISOs, DevSecOps-Leiter und Sicherheitsverantwortliche mit der Implementierung von Codesignaturen in ihren Pipelines befassen?“ Die moderne Software-Lieferkette umfasst weit mehr als nur den Quellcode. Sie beinhaltet Build-Systeme, CI/CD-Pipelines, Artefakt-Repositories, Paketmanager, Update-Kanäle, Zertifikate und die Infrastruktur, die zur Bereitstellung von Software für Kunden und Mitarbeiter verwendet wird. Genau aus diesem Grund ist die Codesignatur zu einem Schwerpunkt wichtiger regulatorischer und politischer Rahmenbedingungen geworden.  

• NIST SSDF (SP 800-218)Das Secure Software Development Framework fordert explizit die Überprüfung der Integrität von Softwarekomponenten, den Schutz von Signaturschlüsseln und die Implementierung von Prozessen zur Erkennung von Manipulationen in der Build-Pipeline. Es ist direkt mit der Codesignierung als Kontrollmaßnahme verknüpft. 
• CISA Secure by DesignDie Richtlinien der CISA drängen Softwarehersteller dazu, die Verantwortung für die Sicherheitsergebnisse zu übernehmen und sicherzustellen, dass die an Kunden ausgelieferte Software auf Authentizität und Unverändertheit überprüft werden kann. Codesignatur ist ein zentraler Mechanismus für diese überprüfbare Zustellung. 
• Präsidialverordnung 14028 (Verbesserung der Cybersicherheit der Nation)Die im Mai 2021 unterzeichnete Executive Order 14028 verpflichtete Bundesbehörden und ihre Softwarelieferanten zur Einhaltung spezifischer Sicherheitsanforderungen an die Software-Lieferkette. Dazu gehören die Generierung von Software-Build-Objekten (SBOM), sichere Entwicklungsumgebungen und die Überprüfung der Integrität von Artefakten. Diese Anordnung machte Lieferkettensicherheit und Codesignierung faktisch zu einer Compliance-Anforderung für alle Organisationen, die mit der US-Bundesregierung Geschäfte tätigen. 

Wenn Angreifer die Anwendung nicht direkt kompromittieren können, zielen sie häufig auf die Produktions- oder Vertriebskette ab. Daher ist die Codesignierung eine strategische Kontrollmaßnahme und keine bloße taktische Nebensache. Sie ermöglicht Plattformen, Sicherheitstools und Endnutzern die Überprüfung, ob die Software vom erwarteten Herausgeber stammt und nach der Veröffentlichung nicht verändert wurde. Für das Management bedeutet dies, dass die Codesignierung das Risiko manipulierter Software, schädlicher Updates und Vertrauensverluste in der Releasekette reduziert. Sie unterstützt sowohl die Sicherheit als auch die operative Glaubwürdigkeit. 

Bei der Integration von Codesignierung in die Lieferkette müssen Organisationen und Teams die untenstehende Checkliste befolgen, um ihre Umgebungen sicher zu halten: 

• Verwenden Sie EV-Zertifikate für alle produktionssignierten, öffentlich vertriebenen Softwareprodukte.
• Jedes signierte Artefakt sollte stets mit einem vertrauenswürdigen TSA-System mit einem Zeitstempel versehen werden.
• Private Schlüssel in einem HSM speichern — niemals in Dateien, Umgebungsvariablen oder auf Entwicklerrechnern.
• Integrieren Sie die Signatur in CI/CD zum richtigen Zeitpunkt. (Nach dem Test, vor der Veröffentlichung).
• Rollenbasierten Zugriff implementieren — Nicht jeder benötigt Schreibrechte.
• Protokollieren Sie jeden Signiervorgang und überwachen Sie ihn auf Anomalien.
• Ablauf von Zertifikaten verfolgen und Erneuerungserinnerungen automatisieren nach 90, 60 und 30 Tagen.
• Haben Sie einen Widerrufsplan? — genau wissen, wie man einen Schlüssel widerruft und neu signiert, falls dieser kompromittiert wurde.
• Rotieren Sie die Schlüssel regelmäßig — mindestens einmal jährlich und unverzüglich nach jedem Verdacht auf Kompromittierung oder Personalwechsel.
• Verwenden Sie separate Signaturschlüssel pro Umgebung — Die Schlüssel für Entwicklung, Staging und Produktion sollten unterschiedlich sein, um im Falle einer Kompromittierung den Schadensradius zu begrenzen.
• Verwenden Sie nach Möglichkeit kurzlebige Signaturzertifikate. — insbesondere für Workflows zur schlüssellosen Signatur, die die Verwaltung langlebiger Schlüssel vollständig überflüssig machen.

CodeSign Secure von Encryption Consulting 

CodeSign Secure ist eine zentrale, sichere und skalierbare Codesignatur-Plattform, die Unternehmen dabei unterstützt, Code sicher und ohne Kompromisse bei Sicherheit oder Geschwindigkeit zu signieren. Sie ist für moderne DevOps-Umgebungen konzipiert und lässt sich in gängige Systeme integrieren. CI / CD-Pipelines wie Azure DevOps, Jenkins und GitLab, wobei strenge Zugriffskontrollen und Genehmigungsworkflows durchgesetzt werden, um einen sauberen und konformen Signaturprozess zu gewährleisten. 

Hauptfunktionen

• HSM-gestützte Schlüsselsicherheit

  CodeSign Secure nutzt ein FIPS 140-2 Level 3 HSM für die sichere Schlüsselspeicherung, die den Schutz privater Schlüssel jederzeit gewährleistet. Die Plattform lässt sich in verschiedene Systeme integrieren. Hardware-Sicherheitsmoduleeinschließlich Entrust nCipher, Thales Luna, Utimaco und Securosys, die sicherstellen, dass kryptografische Schlüssel immer auf einem manipulationssicheren, sicheren Hardwaregerät gespeichert werden, egal ob Sie lokale Hardware oder Cloud-HSMs bevorzugen.

• Richtlinienbasierte Zugriffskontrolle

  Das Zugriffskontrollsystem von CodeSign Secure integriert sich in Microsoft Active Directory und Keycloak, um Benutzer zu registrieren und deren Anmeldeinformationen und Berechtigungen zentral zu verwalten. Die Plattform bietet ein detailliertes rollenbasiertes Zugriffskontrollsystem (RBAC) mit anpassbaren Workflows für eine präzise Kontrolle der Codesignierungsprozesse, wodurch unberechtigter Zugriff verhindert und Sicherheitsrisiken minimiert werden.

  Die Richtlinien für die Signatur werden programmatisch auf Plattformebene durchgesetzt. Das heißt, kein Artefakt kann signiert werden, solange es nicht alle vordefinierten Kriterien erfüllt: den korrekten Zertifikatstyp, die korrekte Signaturstufe und die erforderlichen Genehmigungen. Die Funktionstrennung wird durch mehrstufige Genehmigungsworkflows gewährleistet: Entwickler können zwar eine Signaturanfrage stellen, diese muss jedoch von Release-Managern oder Sicherheitsbeauftragten genehmigt werden, bevor die Signatur angewendet wird. Dadurch wird das Risiko ausgeschlossen, dass ein einzelnes kompromittiertes Konto eigenständig und ohne Aufsicht Software signiert und veröffentlicht. Zudem werden alle Genehmigungen, Ablehnungen und Signaturvorgänge in Audit-Trails und Protokollen erfasst – so erhalten Sicherheitsteams die notwendigen Nachweise für Compliance-Berichte und die Untersuchung von Sicherheitsvorfällen.

• Nahtlose CI/CD-Integration

  Die Plattform erzwingt Sicherheitsprüfungen und Integritätsvalidierungen, um zu verhindern, dass unsignierte Artefakte in die Produktion gelangen, und ermöglicht die zentrale Nachverfolgung mit sofortigen Warnmeldungen bei unautorisierten Signierversuchen. CodeSign Secure ist für schnelle Entwicklungszyklen und CI/CD-Prozesse (Continuous Integration/Continuous Deployment) konzipiert, einschließlich Azure DevOps, Jenkins, GitLab und mehr.

• Breite Format- und Plattformunterstützung

  Die Lösung unterstützt das Signieren verschiedener Formate, darunter .exe, .dll, .jar, .apk, .dmg, Docker-Container, Firmware-Binärdateien und mehr. So wird sichergestellt, dass alle Software-Artefakte auf verschiedenen Betriebssystemplattformen wie Windows, Linux und macOS sicher signiert werden können. Sie lässt sich nahtlos in unseren benutzerdefinierten PKCS11-Wrapper und zahlreiche Signaturtools von Drittanbietern wie Signtool, Jarsigner, JSign und viele weitere integrieren.

• Clientseitiges Hashing und sichere Zeitstempelung

  Die Plattform nutzt clientseitiges Hashing, d. h. der Code-Hash wird mithilfe eines speziell entwickelten Key Storage Providers (KSP) auf Ihrem Rechner generiert, der nahtlos mit Microsofts Cryptography Next Generation (CNG)-Framework zusammenarbeitet. Zusammen mit sicheren Zeitstempeln gewährleistet sie die Integrität und Langlebigkeit digitaler Signaturen, auch nach Ablauf des Zertifikats.

• Umfassende Prüfprotokolle

  Die Plattform bietet Echtzeit-Einblick in alle Code-Signierung Aktivitäten im Bereich Sicherheit und Compliance, einschließlich der Führung detaillierter Ereignisprotokolle und Prüfprotokolle zur Nachverfolgung der Schlüsselnutzung, Untersuchung von Vorfällen und Erfüllung von Compliance-Anforderungen. Es bietet außerdem eine Plugin-Integration mit vielen SIEM-Tools wie Grafana, Loki und Splunk über OpenTelemetry.

• Flexible Bereitstellungsmodelle

  Organisationen können eine vollständig verwaltete, Cloud-basierte Lösung mit integrierter HSM-Sicherheit nutzen, die alle Funktionen über API-Zugriff bietet, oder CodeSign Secure lokal mit physischen Servern einsetzen und dabei private Schlüssel sicher in Cloud-HSMs, lokalen HSMs oder beidem verwalten, um maximale Flexibilität zu gewährleisten.

• Unterstützung für Post-Quanten-Kryptographie (PQC)

  CodeSign Secure unterstützt Post-Quanten-Kryptographie Signieren, ML-DSA (Multivariate Lattice Digital Signature Algorithm) und LMS (Leighton-Micali Signatures), zwei vom NIST anerkannte, quantenresistente Signaturverfahren, direkt auf dem HSM selbst. Durch die Auslagerung dieses Prozesses auf ein PQC-fähiges HSM werden die benötigten massiven kryptografischen Schlüssel niemals dem System zugänglich gemacht und bleiben physisch in einer gehärteten Umgebung geschützt.

  Für Organisationen, die einen schrittweisen Übergang benötigen, unterstützt CodeSign Secure auch Dual-Signatur-Verfahren, beispielsweise die Verwendung einer klassischen RSA- oder ECDSA-Signatur in Kombination mit einer ML-DSA- oder LMS-Signatur für unterschiedliche Signaturanforderungen. Die Dual-Signatur-Einrichtung ermöglicht es, verschiedene Software je nach Bedarf sowohl mit klassischen als auch mit quantenfähigen Verifizierungssystemen zu signieren und unterstützt den Übergang nach der Quantenumstellung.

Ob Sie ein wachsendes Unternehmen, ein Großkonzern oder in stark regulierten Branchen wie der Automobilindustrie, dem Gesundheitswesen oder der Finanztechnologie tätig sind – CodeSign Secure wurde speziell für Ihre Bedürfnisse entwickelt. Wenn Sie Dutzende von Signaturidentitäten in verteilten Teams verwalten, hochperformante CI/CD-Pipelines betreiben oder strengen Compliance-Vorgaben unterliegen, ist CodeSign Secure genau auf Ihre Herausforderungen zugeschnitten. 

Fazit 

Codesignierung mag auf den ersten Blick wie eine rein technische Angelegenheit erscheinen, etwas, das man einmal konfiguriert und dann vergisst. Doch wie die Bedrohungsdaten für 2025 und 2026 schmerzlich verdeutlichen, ist sie eine der wichtigsten Sicherheitsmaßnahmen überhaupt. Angriffe auf die Software-Lieferkette Bis 2025 haben sich die Kosten mehr als verdoppelt. Angreifer warten nicht mehr vor der Haustür; sie sind in den Paketen eingebettet, die Ihre Entwickler täglich herunterladen, in den CI/CD-Prozessen, die Ihre Pipelines automatisch ausführen, und in den Build-Artefakten, denen Ihre Teams blind vertrauen. Cybersecurity Ventures prognostiziert, dass die weltweiten jährlichen Kosten dieser Angriffe bis 2031 138 Milliarden US-Dollar erreichen werden. Die Frage ist, ob Ihre Codesignatur-Sicherheit diesen Anforderungen gewachsen ist. 

Ob Sie Ihre erste PKI aufbauen, Codesignierung in eine komplexe Multi-Cloud-CI/CD-Umgebung integrieren oder die Einhaltung von Frameworks wie SLSA oder NIST anstreben – Encryption Consulting unterstützt Sie in den Bereichen Beratung, Migration und Integration. Die Software-Lieferkette ist nur so stark wie ihr schwächstes Glied. Sorgen Sie dafür, dass die Codesignierung nicht zu Ihrem schwächsten Glied gehört.