Wie Code Signing im Softwareentwicklungszyklus hilft

Die Codesignierung im Softwareentwicklungszyklus bezeichnet die Praxis, Code, Builds und Releases in jeder Phase der Pipeline – nicht erst vor der endgültigen Verteilung – digital mit einer kryptografischen Signatur zu signieren. Dadurch wird sichergestellt, dass ein Build zwischen Commit und Deployment nicht manipuliert wurde, und die Sicherheitslücke geschlossen, die Angriffe wie SolarWinds und 3CX ausgenutzt haben.

Mit dem Wachstum digitaler Technologien entwickeln sich auch Cyberbedrohungen rasant weiter. Daher sind die Sicherheit und Integrität von Software unerlässlich. Die Codesignierung spielt eine zentrale Rolle, um die Authentizität von Software zu gewährleisten, Manipulationen zu verhindern und Vertrauen zwischen Entwicklern und Endnutzern aufzubauen. Für Unternehmen reicht die reine Signierung des Codes jedoch nicht aus. Sie müssen bewährte Verfahren anwenden, um Risiken zu minimieren und eine sichere Software-Lieferkette zu gewährleisten.

Bevor wir uns mit den Best Practices befassen, wollen wir zunächst verstehen, was Codesignierung ist, welche Rolle sie in DevOps- und CI/CD-Pipelines spielt und wie sie dazu beiträgt, Cyberangriffe in der realen Welt zu verhindern.

https://www.youtube.com/embed/3bKeAOmvRo0?si=lg61-YiChqlgRKB7

Was ist Code Signing und wie funktioniert es?

Die Codesignierung ist ein Sicherheitsmechanismus, der die Authentizität und Integrität von Softwarecode, Skripten oder ausführbaren Dateien überprüft. Dabei wird Software digital signiert, um zu bestätigen, dass sie aus einer vertrauenswürdigen Quelle stammt und seit der Signierung nicht verändert oder manipuliert wurde.

Der Prozess beginnt mit dem Hashing, bei dem die Software in eine eindeutige Zeichenkette fester Länge (z. B. SHA-256 ) umgewandelt wird. Dieser Hash wird anschließend mit dem privaten Schlüssel des Entwicklers (sicher gespeichert, oft in einem Hardware-Sicherheitsmodul , HSM) verschlüsselt, um eine digitale Signatur zu erstellen. Diese wird zusammen mit Metadaten wie Zeitstempel und Zertifikatsdetails (öffentlicher Schlüssel) in die Software eingebettet.

Wenn ein Benutzer die Software herunterlädt, entschlüsselt sein System die Signatur mit dem öffentlichen Schlüssel des Entwicklers (aus dem beigefügten Zertifikat) und vergleicht sie mit einem neu berechneten Hash der heruntergeladenen Datei. Stimmen sie überein, wird die Datei als unverändert verifiziert.

Warum ist Code Signing bei der Softwareentwicklung wichtig?

Wie bereits erwähnt, spielt die Codesignierung eine wichtige Rolle bei der Sicherstellung der Softwareauthentizität und der Verhinderung von Manipulationen. Wir werden im Detail untersuchen, warum die Codesignierung für die Softwareentwicklung so entscheidend ist.

Gewährleistet die Softwareintegrität

Die Codesignierung garantiert, dass die Software seit der Signierung durch den Entwickler nicht verändert wurde. Beim Signieren des Codes wird ein kryptografischer Hashwert generiert und mit dem privaten Schlüssel des Entwicklers verschlüsselt. Verändert sich auch nur ein einziges Byte in der Datei (beispielsweise durch Malware-Einschleusung oder Beschädigung), schlägt die Hashwertprüfung fehl und warnt die Benutzer vor einer möglichen Kompromittierung der Software. Dies verhindert, dass Angreifer veränderte Versionen legitimer Software verbreiten und schützt somit sowohl Entwickler als auch Endbenutzer.

Überprüft Authentizität und Vertrauenswürdigkeit

Ohne Codesignatur haben Nutzer keine zuverlässige Möglichkeit zu überprüfen, ob Software von einem legitimen Herausgeber stammt. Codesignaturzertifikate, die von vertrauenswürdigen Zertifizierungsstellen (CAs) ausgestellt werden , verknüpfen die Software mit einer verifizierten Organisation oder einem Entwickler. Bei der Installation signierter Software zeigt das Betriebssystem den Namen des Herausgebers an (z. B. „Microsoft Corporation“ statt „Unbekannter Herausgeber“), was das Vertrauen stärkt und Sicherheitswarnungen reduziert. Dies ist besonders wichtig für Unternehmenssoftware, Treiber und Finanzanwendungen, bei denen die Quellcodeverifizierung von entscheidender Bedeutung ist.

Diese von vertrauenswürdigen Zertifizierungsstellen ausgestellten Zertifikate gibt es in verschiedenen Ausführungen, je nach dem Grad der Validierung und des gebotenen Vertrauens:

Art des Zertifikats	Verifizierungsstufe	Vertrauenssignal	Am besten geeignet für
Individuell validiert (IV)	Überprüft die Identität des einzelnen Entwicklers anhand offizieller Dokumente.	Grundlegendes Vertrauen; kann auf einigen Systemen weiterhin Warnungen auslösen	Persönliche oder kleinskalige Projekte
Organisation validiert (OV)	Überprüft die Geschäftsberechtigung einer rechtmäßig registrierten Organisation.	Mittleres Vertrauen; zeigt den Firmennamen in der Signatur an	Interne und öffentliche Software eines eingetragenen Unternehmens
Extended Validation (EV)	Gründliche Geschäfts- und Identitätsprüfung	Höchstes Vertrauen; unterdrückt Sicherheitswarnungen sofort	Öffentliche, unternehmensinterne und sicherheitsrelevante Software

Verhindert Malware und Angriffe auf die Lieferkette

Cyberkriminelle verbreiten Schadsoftware häufig, indem sie sich als legitime Software ausgeben oder bösartigen Code in Updates einschleusen. Codesignierung mindert dieses Risiko, indem sie sicherstellt, dass nur ordnungsgemäß signierter und verifizierter Code ausgeführt wird. Versucht ein Angreifer, eine signierte ausführbare Datei zu verändern, wird die digitale Signatur ungültig, und das System blockiert den Vorgang. Dies ist besonders wichtig für die Sicherheit von Lieferketten, wo Angreifer Softwareanbieter kompromittieren, um mit Trojanern infizierte Updates zu verbreiten, wie beispielsweise beim SolarWinds-Angriff. Codesignierung dient als Schutzmechanismus gegen solche Bedrohungen.

Ermöglicht sichere Software-Updates

Software-Updates sind ein häufiges Einfallstor für Hacker, die unsignierte Updates nutzen, um Schadsoftware zu verbreiten. Die Codesignierung stellt sicher, dass nur der ursprüngliche Herausgeber Updates bereitstellen kann. Wenn eine Anwendung nach Updates sucht, überprüft sie die digitale Signatur vor der Installation. Dies hilft, Man-in-the-Middle-Angriffe (MITM) und unautorisierte Änderungen zu verhindern.

Warum beweisen die jüngsten Cyberangriffe, dass sichere Code-Signierung unerlässlich ist?

Zahlreiche aufsehenerregende Cyberangriffe zeigen, wie Angreifer Schwachstellen in Software-Lieferketten ausnutzen, wodurch die Codesignierung noch wichtiger wird. ReversingLabs verzeichnete zwischen 2020 und 2023 einen Anstieg von über 1,300 % bei Bedrohungen, die über Open-Source-Paketquellen verbreitet werden – und dieser Trend hält an: Laut einem Bericht von Sonatype vom 28. Januar 2026 identifizierte das Unternehmen allein im Jahr 2025 über 454,600 neue schädliche Open-Source-Pakete, ein Anstieg von 75 % gegenüber dem Vorjahr . Gleichzeitig verdoppelte sich die Beteiligung von Drittanbietern an Datenschutzverletzungen innerhalb eines Jahres von 15 % auf 30 % , wie aus dem Verizon-Bericht „Data Breach Investigations Report 2025“ hervorgeht.

Nachfolgend finden Sie einige reale Cyberangriffe und die Lehren, die wir in den letzten Jahren daraus gezogen haben.

3CX-Lieferkettenangriff (März 2023)

Der Lieferkettenangriff auf 3CX im Jahr 2023 markierte eine deutliche Eskalation von Sicherheitslücken in Software-Lieferketten. Angreifer drangen in das Build-System des Unternehmens ein, um schädliche Updates zu installieren, die mit den gültigen Zertifikaten von 3CX digital signiert waren. Dieser ausgeklügelte Angriff wurde nordkoreanischen staatlich geförderten Akteuren zugeschrieben und betraf weltweit über 600,000 Organisationen durch manipulierte Versionen der 3CX-Desktop-Anwendung.

Der Vorfall legte gravierende Sicherheitslücken in Build-Systemen offen und zeigte, dass selbst ordnungsgemäß signierte Software-Updates nicht blind vertraut werden können. Er verdeutlicht die Notwendigkeit einer mehrstufigen Überprüfung der Softwareintegrität, die präzise Prüfungen der Build-Umgebungen und die kontinuierliche Überwachung signierter Anwendungen auf ungewöhnliches Verhalten umfasst.

Neben Prüfungen und Überwachung benötigen Organisationen über die Codesignierung hinaus mehrere Schutzebenen. Dazu gehören unter anderem:

Scannen nach Software-Sicherheitslücken

Software-Schwachstellenscanner sind Tools, die Anwendungen, Code und Softwareumgebungen automatisch auf bekannte Sicherheitslücken überprüfen. Diese Scanner identifizieren Probleme wie veraltete Bibliotheken, Fehlkonfigurationen, unsichere Codemuster und öffentlich bekannte Schwachstellen (CVEs). Durch das Scannen von Software vor der Veröffentlichung und während regelmäßiger Updates können Entwickler Sicherheitsprobleme frühzeitig erkennen und beheben und so das Risiko verringern, dass Angreifer sie später ausnutzen. Schwachstellenscans sind ein wichtiger Bestandteil moderner DevSecOps-Praktiken und gewährleisten kontinuierliche Sicherheit während des gesamten Software-Lebenszyklus.

Software-Stückliste (SBOM)

Eine Software-Builder-Map (SBOM) ist eine detaillierte Liste aller Komponenten, Bibliotheken und Abhängigkeiten einer Softwareanwendung. Sie funktioniert wie eine Zutatenliste und ermöglicht es, den Inhalt eines Programms leicht nachzuverfolgen. Durch die Pflege einer SBOM können Unternehmen schnell erkennen, ob Komponenten von Drittanbietern oder Open-Source-Software bekannte Sicherheitslücken, veraltete Bibliotheken oder Lizenzrisiken aufweisen. Sie spielt eine entscheidende Rolle bei der Verbesserung der Softwaresicherheit, insbesondere bei der Verwaltung und Reduzierung von Risiken entlang der Software-Lieferkette.

MOVEit Transfer-Ausnutzung (Juni 2023)

Der MOVEit-Angriff der Ransomware-Gruppe Cl0p zeigte, wie Schwachstellen in der Lieferkette den Code-Signing-Schutz umgehen können. Zwar handelte es sich nicht um einen direkten Code-Signing-Verstoß, doch die massenhafte Ausnutzung dieser weit verbreiteten Dateiübertragungslösung ermöglichte es Angreifern, Software-Updates und Patches während der Übertragung abzufangen.

Dadurch entstand ein Szenario, in dem ordnungsgemäß signierte Software während der Auslieferung gegen manipulierte Versionen ausgetauscht werden konnte. Der Vorfall verdeutlichte, dass die alleinige Codesignierung nicht ausreicht; Unternehmen müssen zusätzlich die Integrität ihrer Vertriebskanäle überprüfen und eine Prüfsummenvalidierung implementieren, um sicherzustellen, dass signierte Pakete nach der Signierung unverändert bleiben.

Vorfall bei Applied Materials (Februar 2023)

Bei dem Datenleck des Halbleiterriesen wurden gestohlene Zugangsdaten verwendet, um auf sensible Systeme zuzugreifen, möglicherweise auch auf die Infrastruktur zur Code-Signatur. Obwohl die genauen Details noch nicht bekannt gegeben wurden, zeigte der Angriff, wie Social Engineering und der Diebstahl von Zugangsdaten selbst starke Schutzmechanismen zur Code-Signatur umgehen können.

Dieser Fall unterstreicht auch die Risiken der Integration von Code Signing in automatisierte CI/CD-Pipelines ohne angemessene Sicherheitskontrollen. Automatisierung steigert zwar die Entwicklungsgeschwindigkeit und -effizienz, kann aber auch die Gefährdung erhöhen, wenn sie nicht sicher verwaltet wird. Wenn Signaturprozesse in Pipelines integriert sind, können Angreifer, die Build-Server oder CI/CD-Umgebungen kompromittieren, potenziell schädlichen Code einschleusen und ihn automatisch signieren lassen, ohne dass Warnmeldungen ausgelöst werden.

Um dies zu verhindern, müssen Unternehmen Code-Signatur-Vorgänge als äußerst vertrauenswürdige Vorgänge behandeln. Das bedeutet, dass sie eine Multi-Faktor-Authentifizierung implementieren, den Zugriff auf Signatur-Anmeldeinformationen beschränken, Hardware-Sicherheitsmodule (HSMs) oder Cloud-basierte Schlüsselverwaltungslösungen verwenden und vor jeder Signierung manuelle Genehmigungsschritte oder Richtlinienprüfungen durchführen. Die Automatisierung sollte durch strenge Zugriffskontrollen und Überwachung ergänzt werden, um sicherzustellen, dass die Sicherheit nicht der Geschwindigkeit geopfert wird.

SolarWinds-Angriff (Dezember 2020)

Der SolarWinds-Angriff war ein ausgeklügelter Angriff auf die Lieferkette, bei dem russische, staatlich geförderte Hacker in die Softwareentwicklungssysteme des Unternehmens eindrangen und heimlich Schadcode in legitime Updates für SolarWinds' IT-Überwachungsplattform Orion einfügten. Diese manipulierten Updates wurden digital mit gültigen SolarWinds-Zertifikaten signiert und anschließend an rund 18,000 Kunden, darunter Regierungsbehörden und Großkonzerne, verteilt. Dadurch konnten die Angreifer ihre Opfer über einen sehr langen Zeitraum ausspionieren.

Durch die Ausnutzung vertrauenswürdiger Update-Mechanismen und den Missbrauch von Codesignaturen legte der Sicherheitsvorfall gravierende Schwachstellen in der Software-Lieferkette offen und bewies, dass selbst ordnungsgemäß signierte Software missbraucht werden kann, wenn die Build-Umgebungen kompromittiert sind. Codesignatur allein reicht nicht aus; ist die Build-Umgebung kompromittiert, kann selbst signierte Software schädlich sein. Um solchen Risiken zu begegnen, setzt die Branche zunehmend auf reproduzierbare Builds als wirksame Verteidigung.

Ein reproduzierbarer Build stellt sicher, dass bei jeder Kompilierung des Quellcodes dieselbe Binärdatei erzeugt wird. Dadurch lässt sich überprüfen, ob das Ergebnis exakt dem Sollzustand entspricht. Dieser Prozess wird häufig mit einer Hash-Validierung vor und nach dem Build kombiniert. Dabei wird vor dem Build ein Hash des Quellcodes erstellt und nach dem Build der Hash der resultierenden Binärdatei überprüft. Jede Abweichung zwischen erwarteter und tatsächlicher Ausgabe kann auf Manipulationen oder unautorisierte Änderungen hinweisen. Reproduzierbare Builds und Hash-Validierung tragen gemeinsam dazu bei, Kompromittierungen während des Build-Prozesses zu erkennen und die Vertrauenswürdigkeit und Transparenz der Software-Lieferkette zu erhöhen. Dies ist auch die Grundlage für Frameworks wie SLSA Level 3.

Vergleich aktueller Vorfälle im Zusammenhang mit Codesignaturen

Die folgende Tabelle fasst die vier oben genannten Vorfälle nebeneinander zusammen, da jeder einzelne einen anderen Punkt in der Lieferkette ausnutzte.

Vorfall	Datum	Ursache	Wichtigste Lektion
SolarWinds	Dezember 2020	Kompromittierte Entwicklungsumgebung; Schadcode mit gültigen Zertifikaten signiert	Eine Signatur kann kein Vertrauen beweisen, wenn die Build-Umgebung selbst kompromittiert ist; daher sind reproduzierbare Builds und Hash-Validierung notwendig.
Applied Materials	Februar 2023	Gestohlene Zugangsdaten, möglicherweise einschließlich des Zugangs zur Signaturinfrastruktur	Automatisierung ohne MFA und manuelle Genehmigung ermöglicht es gestohlenen Anmeldeinformationen, unbemerkt Schadcode zu signieren
3CX	März 2023	Angreifer drangen in das Build-System ein und signierten bösartige Updates mit legitimen Zertifikaten.	Korrekt signierte Software ist nicht blindlings vertrauenswürdig; Entwicklungsumgebungen erfordern eine kontinuierliche Überwachung.
MOVEit-Übertragung	Juni 2023	Eine Sicherheitslücke in einer Dateitransfersoftware wurde ausgenutzt, um signierte Pakete während der Übertragung abzufangen.	Die alleinige Codesignierung sichert den Vertriebskanal nicht; die Prüfsummenvalidierung nach der Signierung ist ebenfalls wichtig.

Einige Best Practices bei der Code-Signierung zur Sicherung der Software-Lieferkette

Wie bereits erwähnt, können unsachgemäße Verfahren zur Codesignierung Sicherheitslücken verursachen, die Anwendungen anfällig für Lieferkettenangriffe, Malware-Einschleusungen und unautorisierte Änderungen machen. Die Implementierung bewährter Verfahren zur Codesignierung hilft Unternehmen, Vertrauen zu wahren, Manipulationen zu verhindern und Endnutzer vor Bedrohungen zu schützen. Im Folgenden werden einige dieser bewährten Verfahren zur Codesignierung erläutert, die für eine sichere Softwareentwicklung unerlässlich sind.

Sichere Speicherung privater Schlüssel im HSM

Die Grundlage für sichere Codesignierung liegt im Schutz privater Schlüssel vor Diebstahl und Missbrauch. Hardware-Sicherheitsmodule (HSMs) bieten höchsten Schutz, indem sie Schlüssel in spezieller, manipulationssicherer Hardware speichern, die deren Extraktion selbst bei einem kompromittierten Server verhindert. Diese Geräte setzen strenge Zugriffskontrollen durch, um sicherzustellen, dass Schlüssel ausschließlich für kryptografische Operationen verwendet und niemals im Klartext offengelegt werden.

Organisationen, die sensible Software verarbeiten, sollten FIPS 140-2 Level 3-zertifizierte HSMs einsetzen, da diese nicht nur Schlüssel sichern, sondern auch alle kryptografischen Operationen intern durchführen und so die Risiken von Memory-Scraping-Angriffen eliminieren. Dieser Ansatz erscheint nach Vorfällen wie dem SolarWinds-Angriff, bei dem kompromittierte Build-Systeme durch HSM-geschützte Schlüssel hätten entschärft werden können, umso wichtiger.

Erzwingen Sie Multi-Faktor-Authentifizierung und Genehmigungs-Workflows

Während HSMs Schlüssel technisch schützen, verhindern prozedurale Kontrollen die unbefugte Nutzung. Die Implementierung einer Multi-Faktor-Authentifizierung (MFA) für den Zugriff auf Signatursysteme stellt sicher, dass gestohlene Anmeldeinformationen allein keine Signaturvorgänge auslösen können.

Noch wichtiger ist, dass die Einrichtung von Genehmigungsworkflows mit mehreren Personen, bei denen für kritische Releases die Autorisierung durch mehrere vertrauenswürdige Teammitglieder erforderlich ist, Verantwortlichkeit schafft und Risiken sowohl durch Insider-Bedrohungen als auch durch die Gefährdung von Anmeldeinformationen verringert.

Diese Kontrollen sollten direkt in CI/CD-Pipelines integriert werden, mit klaren Prüfprotokollen, die zeigen, wer jedes Signierungsereignis genehmigt hat. Nach dem Angriff auf JetBrains TeamCity erkannten Unternehmen beispielsweise, dass Angreifer durch automatisiertes Signieren ohne menschliche Aufsicht Schadcode frei signieren konnten, sobald sie in Build-Systeme eingedrungen waren.

Implementieren Sie ein umfassendes Zertifikatslebenszyklusmanagement

Eine effektive Codesignierung erfordert die aktive Verwaltung von Zertifikaten, die über deren erstmalige Ausstellung hinausgeht. Organisationen sollten kurzlebige Zertifikate ausstellen, die nach Wochen statt Jahren automatisch ablaufen, Zertifikate bei jeglichen Anzeichen einer Kompromittierung durch OCSP/CRL -Prüfungen sofort widerrufen und die Schlüssel systematisch rotieren, um die Angriffsfläche zu minimieren.

Der MOVEit-Angriff hat gezeigt, wie langlebige Zertifikate bei Auftreten von Sicherheitslücken zu einem Risiko werden können. Moderne Ansätze wie Certificate Transparency Logs und automatisierte Überwachungstools helfen, verdächtige Zertifikatsnutzungsmuster zu erkennen, bevor es zu Sicherheitsvorfällen kommt. Für Unternehmen gewährleistet die Integration dieser Verfahren in die bestehende PKI-Infrastruktur eine einheitliche Richtliniendurchsetzung durch alle Entwicklungsteams.

Gewährleisten Sie sichere Signaturzugriffskontrollen und -durchsetzung

Die Implementierung von rollenbasierter Zugriffskontrolle (RBAC, Least-Privilege) für die Code-Signierung ist unerlässlich, um Risiken in der Lieferkette zu minimieren. Die Produktionssignierung sollte durch eine obligatorische Multi-Faktor-Authentifizierung auf autorisierte Release-Ingenieure beschränkt sein, während Entwickler in der Testumgebung eingeschränkte Berechtigungen erhalten.

Die automatisierte Durchsetzung von Richtlinien muss risikoreiche Aktionen wie das Massensignieren ungewöhnlicher Dateitypen blockieren, wobei alle Aktivitäten zu Prüfzwecken protokolliert werden. Moderne Lösungen integrieren diese Kontrollen direkt in CI/CD-Pipelines und kombinieren technische Beschränkungen mit Workflow-Genehmigungen. Dieser mehrstufige Ansatz, zusammen mit HSM-geschützten Schlüsseln, stellt sicher, dass gestohlene Zugangsdaten allein die Signiervorgänge nicht gefährden können, wie die Sicherheitsverbesserungen nach dem SolarWinds-Vorfall belegen. Regelmäßige Zugriffsüberprüfungen gewährleisten sowohl Sicherheit als auch operative Effizienz.

Etablierung einer kontinuierlichen Überwachung und Reaktion auf Vorfälle

Effektive Sicherheit beim Code Signing erfordert eine Echtzeitüberwachung aller Signieraktivitäten durch zentrale Protokollierung und Warnmeldungen. Sicherheitsteams sollten auf Anomalien wie Massensignieranfragen, das Signieren ungewöhnlicher Dateitypen oder Signierereignisse an unerwarteten Orten achten.

Die Integration mit SIEM-Systemen (Security Information and Event Management) ermöglicht die Korrelation mit anderen Sicherheitsereignissen und erleichtert so die Erkennung koordinierter Angriffe. Ebenso wichtig sind vorbereitete Notfallpläne, da sie die Schritte für den Schlüsselwechsel, den Zertifikatswiderruf und den Software-Rückruf im Falle von Sicherheitsverletzungen festlegen.

Der Okta-Datenleck hat gezeigt, wie eine verzögerte Reaktion auf die Gefährdung von Anmeldeinformationen den Schaden exponentiell steigern kann. Daher sind schnelle Erkennungs- und Eindämmungsfunktionen für die Signaturinfrastruktur von entscheidender Bedeutung.

Die Rolle von Encryption Consulting bei der Verbesserung der Softwaresicherheit durch Code Signing

Encryption Consulting stärkt die Softwaresicherheit mit seiner Lösung CodeSign Secure , die bewährte Verfahren für die Codesignierung durchsetzt und so nachweisbares Vertrauen in die Softwareintegrität schafft. Die Plattform automatisiert sichere Signaturprozesse mithilfe von HSM-geschützten Schlüsseln, kryptografischer Validierung und granularen Zugriffskontrollen. Die nahtlose Integration in CI/CD-Pipelines gewährleistet, dass die Sicherheit die Entwicklung nicht beeinträchtigt.

Über die reine Signatur hinaus verfolgt CodeSign Secure einen mehrschichtigen Ansatz zur Absicherung der gesamten Software-Lieferkette. Dazu gehören die Unterstützung reproduzierbarer Builds und die Hash-Validierung vor und nach dem Build-Prozess, um Manipulationen während des Build-Prozesses zu erkennen, die Generierung und Verwaltung von Software-Stücklisten (SBOMs) zur Verfolgung von Risiken auf Komponentenebene sowie die nahtlose Integration mit Schwachstellenscannern, um bekannte Bedrohungen vor der Code-Veröffentlichung zu identifizieren.

Durch die Kombination von Automatisierung auf Unternehmensebene mit umfassender Sicherheitskompetenz unterstützt Encryption Consulting Unternehmen dabei, konform zu bleiben, Angriffe auf die Lieferkette zu verhindern und Code Signing in eine strategische Verteidigungsebene zu verwandeln, die sowohl ihre Software als auch ihre Marke in der heutigen risikoreichen digitalen Umgebung schützt.

Häufig gestellte Fragen

Was ist Codesignierung und wie funktioniert sie in einem Softwareentwicklungsprozess?

Beim Codesignieren wird der Software-Hashwert berechnet, dieser Hashwert mit dem privaten Schlüssel des Entwicklers (üblicherweise in einem HSM gespeichert) verschlüsselt, um eine digitale Signatur zu erstellen, und diese wird in die Zertifikatsmetadaten eingebettet. Beim Herunterladen der Software durch einen Benutzer oder ein System wird die Signatur mit dem öffentlichen Schlüssel entschlüsselt und die Hashwerte werden verglichen, um sicherzustellen, dass sich seit der Signierung nichts geändert hat.

Worin besteht der Unterschied zwischen IV-, OV- und EV-Codesignaturzertifikaten?

Individuell validierte (IV) Zertifikate bestätigen die Identität eines einzelnen Entwicklers und eignen sich für kleine oder private Projekte. Organisationsvalidierte (OV) Zertifikate bestätigen die Identität eines registrierten Unternehmens und zeigen den Firmennamen an. Erweiterte Validierungszertifikate (EV) beinhalten die gründlichste Prüfung, unterdrücken Sicherheitswarnungen sofort und sind optimal für öffentliche, unternehmensweite oder sicherheitskritische Software.

Kann signierte Software trotzdem schädlich sein?

Ja. Wenn die Build-Umgebung, die die Software erzeugt, kompromittiert wird, kann ein Angreifer Schadcode mit einem völlig legitimen Zertifikat signieren lassen, wie es bei den Angriffen auf SolarWinds und 3CX der Fall war. Deshalb sind reproduzierbare Builds und die Hash-Validierung vor und nach dem Build neben der Signierung selbst so wichtig.

Wie stark haben Angriffe auf Software-Lieferketten in letzter Zeit zugenommen?

Deutlich. ReversingLabs verzeichnete zwischen 2020 und 2023 einen Anstieg von mehr als 1,300 % bei Bedrohungen, die über Open-Source-Paket-Repositories kursieren, und Sonatype identifizierte allein im Jahr 2025 über 454,600 neue bösartige Open-Source-Pakete, ein Anstieg von 75 % gegenüber dem Vorjahr, wie aus dem Bericht vom 28. Januar 2026 hervorgeht.

Was ist ein reproduzierbarer Build und warum ist er für die Codesignierung wichtig?

Ein reproduzierbarer Build erzeugt bei jeder Kompilierung desselben Quellcodes exakt dieselbe Binärdatei. Dadurch lässt sich überprüfen, ob das tatsächlich erstellte Ergebnis dem Sollzustand entspricht. In Kombination mit der Hash-Validierung vor und nach dem Build erkennt er Manipulationen während des Build-Prozesses, die eine gültige Codesignatur allein nicht erkennen würde.

Warum benötigen Organisationen neben der Codesignatur auch MFA und Genehmigungsprozesse?

Gestohlene Zugangsdaten allein sollten nicht in der Lage sein, Schadcode zu signieren. Multifaktor-Authentifizierung und Genehmigungsprozesse mit mehreren Personen für Signaturvorgänge ergänzen den technischen HSM-Schutz um eine prozedurale Kontrolle, sodass ein kompromittierter Login nicht eigenständig ein Signaturereignis auslösen kann.

Worin besteht der Unterschied zwischen einem SBOM und einem Codesignaturzertifikat?

Ein Codesignaturzertifikat belegt, wer ein bestimmtes signiertes Artefakt veröffentlicht hat und dass es seit der Signierung unverändert geblieben ist. Eine Software-Stückliste (SBOM) listet alle Komponenten und Abhängigkeiten innerhalb dieses Artefakts auf und ermöglicht es Teams, zu überprüfen, ob eine dieser Komponenten bekannte Sicherheitslücken aufweist. Beide Dokumente beantworten unterschiedliche Fragen und werden üblicherweise zusammen verwendet.

Wie schützt CodeSign Secure vor Sicherheitslücken in der Build-Umgebung, wie sie beispielsweise bei SolarWinds und 3CX auftreten?

CodeSign Secure unterstützt reproduzierbare Builds und Hash-Validierung vor/nach dem Build, um Manipulationen an der Build-Umgebung direkt aufzudecken – genau die Lücke, die sowohl SolarWinds als auch 3CX ausgenutzt haben –, sowie HSM-geschützte Schlüssel und granulare Zugriffskontrollen, die die Möglichkeiten kompromittierter Anmeldeinformationen einschränken.

Wie oft sollten Codesignaturzertifikate rotiert oder gekürzt werden?

Verwenden Sie Zertifikate mit einer Gültigkeitsdauer von Wochen statt Jahren und rotieren Sie die Schlüssel nach einem festgelegten Zeitplan, anstatt einen Schlüssel über mehrere Releases hinweg wiederzuverwenden. Kürzere Gültigkeitsdauer und regelmäßige Rotation der Zertifikate begrenzen das Ausmaß der Sicherheitslücken in der Software, falls ein einzelner Schlüssel kompromittiert wird.

Fazit

Code Signing ist entscheidend für den Schutz der Software-Lieferkette vor Manipulationen, Malware und unbefugten Änderungen. Angriffe in der Praxis haben gezeigt, dass kompromittierte Signierungsprozesse zu verheerenden Sicherheitsverletzungen führen können. Dies unterstreicht die Bedeutung sicherer Code Signing für die Wahrung von Vertrauen und Compliance.

Durch die Implementierung fortschrittlicher Verfahren wie HSM-geschützter Schlüssel, granularer Zugriffskontrollen und automatisierter Richtliniendurchsetzung können Unternehmen die Softwareintegrität während des gesamten Softwareentwicklungszyklus von der Entwicklung bis zur Bereitstellung sicherstellen.