Die Bedeutung von Code Signing in der Software Lieferkette

Woher wissen Sie, dass Ihrem Code vertraut werden kann?

In einer Welt, in der Vertrauen schwer zu erlangen ist, ist es eine wichtige Frage, die wir uns stellen müssen. Woher wissen wir, dass die Anwendungen, die wir ausführen, die Container, die wir bereitstellen, oder der Code, den wir an unsere Kunden liefern, echt sind? Woher wissen wir, dass keine Manipulationen vorgenommen wurden?

Alles läuft auf eine Code-Signierung hinaus.

In diesem Blog erörtern wir die Bedeutung von Code Signing, die Herausforderungen bei der richtigen Implementierung und wie Keyfactor Code Assure es Ihnen ermöglicht, Code Signing zu zentralisieren und zu sichern, ohne die Arbeitsabläufe von Entwicklern zu unterbrechen (das vollständige Webinar zu diesem Thema finden Sie, wenn Sie unten auf "Jetzt ansehen" klicken).

Heute ist software nicht nur das Schaufenster. Es ist der operative Motor eines jeden Unternehmens. Und damit dieser Motor wie eine gut geölte Maschine läuft, müssen wir wissen, dass alles, was wir bauen und einsetzen, vertrauenswürdig ist.

Das Herzstück des Vertrauens in die Lieferkette von software ist die Codesignierung. Die Codesignierung beweist die Identität des Herstellers des Quellcodes und bestätigt, dass der Code seit seiner Veröffentlichung nicht verändert wurde.

Wir bewegen uns schnell auf eine Realität zu, in der alles signiert werden muss. Nicht nur die software , die wir von Drittanbietern kaufen, sondern auch die software , die wir in unseren eigenen Unternehmen erstellen und bereitstellen. Das bedeutet, dass alles von PowerShell-Skripten, Bash-Skripten, Containern, Bibliotheken, Dateien und ausführbaren Dateien (was auch immer) signiert werden muss.

Aber Code Signing gibt es schon seit Jahren. Was hat sich also geändert?

Anwendungs- und Betriebsteams arbeiten dank der Einführung von CI/CD und Tools zur Build- und Testautomatisierung schneller als je zuvor. Das bedeutet, dass es weniger Menschen gibt, die einen direkten Überblick über die Vorgänge in der Pipeline haben.

Böswillige Akteure, von APT-Gruppen (Advanced Persistent Threats) bis hin zu Hackern, die im Keller hausen, suchen nach Schwachstellen oder Sicherheitslücken in diesen schnelllebigen und komplexen Umgebungen. Um sich unauffällig zu verhalten, wird bösartiger Code oft an praktisch jedem Punkt der Lieferkette unentdeckt eingeschleust oder verändert. Entweder das oder sie kompromittieren den Code-Signierungsprozess selbst.

Ein Angreifer könnte bösartigen Code in open-source software einschleusen, in Ihr Quellcode-Repository eindringen oder die Build-Server selbst kompromittieren. Im Fall von SolarWinds haben Angreifer nur ein paar Zeilen harmlos aussehenden Code in eine einzige DLL-Datei eingeschleust, der eine weitreichende Bedrohung für die gesamte Lieferkette darstellt.

Angreifer können auch Code-Signatur-Schlüssel auf anfälligen Systemen erwerben oder stehlen, um ihre Malware-Tools zu signieren. Wir haben dies in verschiedenen Szenarien beobachtet, in denen private Codesignatur-Schlüssel von einem Build-Server oder einer Entwickler-Workstation kompromittiert oder sogar versehentlich in der Firmware oder software selbst offengelegt wurden.

Aus der Sicht der Sicherheit reicht es also nicht mehr aus, den Code einfach nur zu signieren. Jetzt ist es genauso wichtig, dass: (1) sicherzustellen, dass das, was die Entwickler entwickeln, auch signiert und an Ihre Kunden geliefert wird, und (2) dass die Infrastruktur und die privaten Schlüssel, die zum Signieren des Codes verwendet werden, streng kontrolliert werden.

Die Angreifer haben sich nach links verlagert. Anstatt Unternehmen direkt anzugreifen, suchen sie nach Schwachstellen in der software Lieferkette, wo sie Tools stehlen oder Code kompromittieren können. Die staatlich unterstützte APT 41 beherrscht diese Technik seit über einem Jahrzehnt und zielt indirekt auf eine große Bandbreite von Unternehmen ab, indem sie deren software Anbieter oder Lieferanten kompromittiert.

Das Code-Signieren ist ein natürliches Ziel für Angreifer, da es ihnen ermöglicht, sich in die Lieferkette einzuschleichen und Ziele von innen heraus anzugreifen. So kann das geschehen:

• Schlüsseldiebstahl oder -missbrauch: Angreifer stehlen Code-Signaturmaterial über ungeschützte Systeme oder falsch konfigurierte Zugriffskontrollen.
• Systemkompromittierung: Angreifer können auch zentralisierte Signier- oder Update-Server kompromittieren, um ein software -Update während des Auslieferungsprozesses zu kapern.
• Code-Kompromittierung: Bösartiger Code wird in open-source Bibliotheken oder Quellcode-Repositories eingeschleust und bleibt unentdeckt, bevor er signiert und an Endbenutzer weitergegeben wird.
• Insider-Bedrohungen: Entwickler innerhalb des Unternehmens können absichtlich bösartigen Code signieren oder sogar unbeabsichtigt Signierschlüssel in einem öffentlich zugänglichen software Update oder Repo offenlegen.

Trotz dieser bekannten Bedrohungen ist die Realität, dass die meisten Unternehmen, mit denen wir heute sprechen, nicht so viel signieren, wie sie sollten, und was noch wichtiger ist, sie haben in der Regel keinen konsistenten Code-Signierungsprozess.

In einer kürzlich durchgeführten Studie haben wir festgestellt, dass Unternehmen durchschnittlich 25 Code-Signatur-Zertifikate besitzen. Etwa 51 % der Befragten gaben an, dass sie die zugehörigen privaten Schlüssel in einem hardware Sicherheitsmodul (HSM) speichern. Auf der anderen Seite gaben viele an, dass private Schlüssel auch auf Build-Servern (33 %) und Entwickler-Workstations (19 %) zu finden sind, und fast zwei Drittel (60 %) der Unternehmen haben keine formellen Zugangskontrollen und Genehmigungsprozesse für Code-Signatur-Schlüssel.

Das Problem ist, dass die Code-Signierung oft nur lose mit der Entwicklung von software gekoppelt ist, anstatt eng integriert zu sein. Die beiden Prozesse sind nicht miteinander verbunden, was zu Reibungsverlusten und Verzögerungen bei der Bereitstellung von software führt oder, was noch schlimmer ist, die Möglichkeit eröffnet, dass böswillige Akteure dies ausnutzen. Hier sind einige häufige Hindernisse:

• Entfernte Teams: Die dezentralisierte Entwicklung ist die neue Norm, die mehrere Herausforderungen mit sich bringt. Die lokale Speicherung von Schlüsseln auf einem Rechner ist keine Option, aber die Übertragung großer Dateien an ein zentrales Signiersystem führt zu erheblichen Wartezeiten.
• Kein Prozess: Code-Signatur-Schlüssel sind in einem HSM gut geschützt, aber es muss dennoch kontrolliert werden, was signiert wird, wer signieren darf usw.
• Manueller Prozess: Richtlinien sind unerlässlich, aber Prozesse, die stark von der hardware Konfiguration und manuellen Genehmigungsprozessen abhängen, sind nicht skalierbar.
• Keine Integration: Die fehlende Unterstützung von Dateitypen oder die fehlende Integration mit bestehenden Tools (z. B. SignTool, Authenticode, jarsigner) macht es extrem schwierig, eine zentrale Kontrolle aufrechtzuerhalten und gleichzeitig Entwicklern ein transparentes Arbeiten zu ermöglichen.

Es stellt sich also die Frage, wie man es Entwicklern einfach und transparent macht, Code zu signieren und gleichzeitig die zentrale Kontrolle darüber zu behalten, was und wie sie signieren können. Diese Frage haben wir uns gestellt, aber anstatt nach der Antwort zu suchen, haben wir sie selbst entwickelt.

Mit der Umstellung auf häufigere software Updates, Remote-Entwicklungsteams und mehr Produkte ist unsere bisherige Signierlösung, die auf hochsicheren, aber stark manuellen Prozessen beruhte, nicht mehr ausreichend. An dieser Stelle kommt Keyfactor Code Assure ins Spiel.

Um das richtige Gleichgewicht zwischen unseren Anforderungen (und denen unserer Kunden) an Transparenz, Benutzerfreundlichkeit und natürlich Sicherheit zu finden, haben wir eine Lösung entwickelt, die dies ermöglicht:

• Schützen Sie private Schlüssel in einem zentral kontrollierten HSM (physisch oder in der Cloud)
• Ermöglicht Entwicklern die Verwendung nativer Tools und Signiermethoden auf ihrem lokalen Rechner, ohne dass die privaten Schlüssel jemals das zentrale HSM verlassen.
• Zugangskontrolle und Aufgabentrennung für verschiedene Teams und Rollen
• Durchsetzung von Richtlinien für die Unterzeichnung auf der Grundlage von Benutzer/Gruppe, Standort, Unterzeichnungsmethode und anderen Parametern
• Führen Sie einen Prüfpfad und einen Zeitstempel für alle Code-Signierungsaktivitäten und die Verwendung von Schlüsseln.
• Integration mit Build-Servern und CI/CD-Tools, vor allem Jenkins, zur Automatisierung der Code-Signierung

Werfen wir einen Blick darauf, wie es funktioniert. Hier ist eine kurze Vorschau auf die Lösung und wie sie sicheres Code Signing für Java und Windows ermöglicht (die vollständige Demo finden Sie hier).