Sicherung der Software-Lieferkette mit CodeSign Secure 

Einführung

Wenn Sie an Softwaresicherheit denken, denken Sie wahrscheinlich zuerst an Firewalls, Virenschutz oder das Patchen von Fehlern. Doch die größten Risiken gehen heutzutage nicht immer vom Code aus, den Sie schreiben. Sie entstehen durch den Code, den Sie verwenden, die Tools, denen Sie vertrauen, und die Systeme, die Ihre Anwendungen erstellen und bereitstellen. 

Das Software-Lieferkette verbindet alles: Ihren Quellcode, Open-Source-Bibliotheken, CI/CD-Pipelines, Build-Server, Cloud-Infrastruktur und sogar die von Ihren Automatisierungstools verwendeten Identitäten. Und wenn nur eine dieser Verbindungen manipuliert wird, können Angreifer eindringen und das gesamte Produkt kompromittieren, ohne jemals Ihre eigentliche Codebasis zu berühren. 

Wir haben dies bei Angriffen wie diesen beobachtet: SolarWinds und Codecov. Ein einziges kompromittiertes Update oder ein durchgesickertes Geheimnis öffnete die Tür für massive Schäden in Tausenden von Organisationen. Dabei handelt es sich nicht nur um technische Probleme; es sind Sicherheitsmängel, die Unternehmen Vertrauen, Geld und Zeit kosten können. 

Da sich Software schnell weiterentwickelt und stark auf Komponenten von Drittanbietern angewiesen ist, ist der Schutz der Lieferkette eine Grundvoraussetzung. Es geht nicht darum, zusätzliche Schritte hinzuzufügen. Es geht darum, sicherzustellen, dass die gelieferte Software genau das ist, was sie soll – und nicht mehr. 

In diesem Artikel erläutern wir, wie es zu Bedrohungen in der Lieferkette kommt, wo die Schwachstellen liegen und was Sie tun können, um den gesamten Prozess vom Schreiben des Codes bis zum Versand zu sichern. 

Was genau ist die Software-Lieferkette? 

Stellen Sie sich die Software-Lieferkette wie die Zubereitung einer Mahlzeit vor. Nicht alles auf Ihrem Teller wurde selbst zubereitet. Das Gemüse haben Sie vielleicht selbst geschnitten, aber die Soße kam aus dem Glas, die Gewürze waren vorverpackt und jemand anderes kümmerte sich um die Lieferung. Bei Software funktioniert es genauso. 

Wenn ein Entwickler eine Anwendung erstellt, ist es nicht nur sein eigener Code, der im Endprodukt landet. Es gibt Open-Source-Bibliotheken, Tools von Drittanbietern, APIs, Build-Systeme, Container-Images, Bereitstellungsplattformen und Skripte – im Grunde eine ganze Reihe beweglicher Teile, die alle zusammenkommen, damit die Software funktioniert. 

Diese Teile werden oft automatisch von verschiedenen Orten abgerufen und durch CI/CD-Pipelines zusammengefügt. Es gibt auch Input von Personalentwicklern, DevOps Ingenieure, Sicherheitsteams und Maschinen wie automatisierte Bots oder Servicekonten, die die Dinge hinter den Kulissen vorantreiben. 

All dies – der Code, die Tools, die Infrastruktur, die Mitarbeiter und die Automatisierung – ist Ihre Software-Lieferkette. 

Und genau wie bei der Lebensmittelsicherheit kann eine verunreinigte oder falsch gehandhabte Zutat das gesamte Gericht ruinieren. Deshalb ist es so wichtig zu verstehen, was in Ihrer Software steckt und wie sie erstellt und ausgeliefert wird. 

Wie es tatsächlich zu Angriffen auf die Software-Lieferkette kommt

Angriffe auf die Software-Lieferkette sind keine ferne Bedrohung wie in einem Film – sie sind überraschend real und, ehrlich gesagt, nicht allzu kompliziert. Angreifer dringen nicht immer durch Ihre Firewalls ein. Stattdessen schleichen sie sich unbemerkt über die Tools, Bibliotheken oder Systeme ein, denen Ihr Team bereits vertraut. 

So läuft es normalerweise ab: 

• Zielen Sie auf die Abhängigkeiten ab: Die meisten modernen Apps basieren auf Open-Source-Paketen. Angreifer schleusen Schadcode in diese Pakete ein, indem sie entweder veraltete Pakete übernehmen oder schädliche Updates bereitstellen, die nützlich erscheinen. Wenn Sie dieses Paket in Ihren Build integrieren, ist der Angriff sofort mit von der Partie. 

• Gefährdung der Build-Pipeline: Anstatt Ihre App direkt zu hacken, zielen Angreifer auf die Systeme ab, die sie erstellen oder bereitstellen, wie z. B. Ihre CI / CD-PipelineEin durchgesickertes Token, ein falsch konfiguriertes Skript oder sogar ein anfälliges Plug-In können ihnen Zugriff verschaffen, um Code kurz vor der Veröffentlichung einzuschleusen. 

• Geheimnisse stehlen oder preisgeben: APIs, Datenbanken und Cloud-Plattformen verwenden alle Token und Anmeldeinformationen. Wenn diese Geheimnisse im Quellcode oder in Protokollen landen (was häufiger vorkommt, als Sie denken), können Angreifer sie abgreifen und sich Zugriff verschaffen, ohne Alarm auszulösen. 

• Fälschen Sie die Quelle oder den Autor: In manchen Fällen geben sich Angreifer als vertrauenswürdige Mitwirkende aus und übermitteln scheinbar harmlosen Code. Wird dieser Code freigegeben, wird er Teil Ihres Produkts. Keine Alarme. Keine Warnsignale. Nur eine unauffällige Hintertür, die nur darauf wartet, genutzt zu werden. 

• Eine Abhängigkeit auf Registrierungsebene kapern: Wenn ein Angreifer ein Paketregistrierungskonto (npm, PyPI usw.) übernimmt, kann er gefälschte Versionen weit verbreiteter Tools verbreiten. Tausende von Apps könnten unwissentlich infizierte Versionen herunterladen und verwenden. 

Kurz gesagt: Es geht nicht immer darum, Dinge kaputt zu machen; es geht darum, sich anzupassen, seriös auszusehen und den Rest den Systemen zu überlassen. Und wenn der Schadcode erst einmal drin ist, kann er monatelang unentdeckt bleiben. 

SolarWinds, Codecov und mehr: Lehren aus schwerwiegenden Sicherheitsverletzungen 

Manchmal braucht es einen größeren Vorfall, um die Dinge durcheinander zu bringen, und in der Welt der Software-Lieferkettensicherheit haben einige Angriffe genau das bewirkt. 

SolarWinds 

Ende 2020 schleusten Angreifer Schadcode in ein legitimes Software-Update für die Orion-Plattform von SolarWinds ein. Dieses Update wurde an Tausende von Kunden, darunter namhafte Regierungsbehörden und Unternehmen, ausgeliefert. Was war daran so beunruhigend? Die Angreifer hackten nicht jedes Zielsystem, sondern verschafften sich Zugang über die Software, der die Nutzer bereits vertrauten. 

Lektion: Nur weil der Code von einem vertrauenswürdigen Anbieter stammt, heißt das nicht, dass er sauber ist. Wenn Ihr Build-Prozess nicht durchgängig gesperrt ist, stehen Ihnen alle Türen offen. 

Codecov 

Im Jahr 2021 erhielten Angreifer Zugriff auf das Bash Uploader-Skript von Codecov, indem sie deren Docker-Bild. Dieses Tool wurde von Tausenden von Entwicklern in CI-Pipelines verwendet. Die bösartige Version sendete unbemerkt Umgebungsvariablen, einschließlich Geheimnisse, an einen Remote-Server. 

Lektion: Selbst kleine Änderungen an einem Tool in Ihrer CI/CD-Pipeline können sensible Informationen an Angreifer weitergeben. Alles, was Anmeldeinformationen oder Builds betrifft, verdient besondere Aufmerksamkeit. 

Weitere erwähnenswerte Beispiele 

• Ereignis-Stream (npm): Ein Angreifer verschaffte sich Zugang, indem er seine Hilfe bei der Wartung eines verlassenen Softwarepakets anbot und anschließend Schadsoftware hinzufügte, die auf Krypto-Wallets abzielte. 

• UAParser.js (npm): Eine beliebte JavaScript-Bibliothek wurde entführt, um Schadsoftware auf den Systemen zu verbreiten, auf denen sie installiert war. 

Lektion: Wenn ein Paket öffentlich, unbeaufsichtigt oder weit verbreitet ist, stellt es ein verlockendes Ziel dar. Angreifer lieben es, wenn Sie Paketen vertrauen, ohne den Inhalt zu prüfen. 

Vom Quellcode bis zur Bereitstellung: Wo die Schwachstellen liegen 

Softwareentwicklung ist wie ein Staffellauf: Ihr Code durchläuft zahlreiche Kontrollpunkte, bevor er in die Produktion gelangt. Das Problem? Bei jeder dieser Übergaben kann etwas schiefgehen, wenn Sie nicht genau aufpassen. 

Hier ist eine Aufschlüsselung, wo Dinge oft durch die Maschen schlüpfen: 

• Quellcode-Repos: Es beginnt mit dem Code. Aber wer hat Zugriff? Sind die Zweige geschützt? Wenn jemand eine Änderung ohne Überprüfung direkt in den Hauptcode eingibt oder, schlimmer noch, mit einem gestohlenen Token Zugriff erhält, gibt es Probleme, bevor der Build überhaupt beginnt. 

• Abhängigkeiten: Ihr Projekt basiert wahrscheinlich auf Hunderten externer Pakete. Einige sind möglicherweise veraltet, andere werden nicht mehr gewartet und manche enthalten möglicherweise sogar versteckte Malware. Es ist einfach, eine Abhängigkeit hinzuzufügen. Schwieriger ist es jedoch, den Überblick über die einzelnen Pakete zu behalten. 

• CI/CD-Pipelines: Diese automatisieren Ihre Builds, Tests und Bereitstellungen, was großartig ist. Sie verarbeiten aber auch Geheimnisse, führen Skripte aus und kommunizieren mit Produktionssystemen. Wird ein Job in der Pipeline kompromittiert, könnten Angreifer unbemerkt Code einschleusen oder vertrauliche Daten preisgeben. 

• Artefakte erstellen: Sobald Ihre App erstellt ist, wird der Ausgabe Ihres Container-Images, Ihrer Binärdatei oder Ihres Pakets in der Regel ohne Zweifel vertraut. Wenn dieses Artefakt jedoch nicht signiert oder verifiziert ist, lässt sich nicht feststellen, ob es echt oder manipuliert ist. 

• Bereitstellungssysteme: Kubernetes-, Terraform- und GitOps-Tools helfen alle dabei, Software schnell auszuliefern. Aber sie können auch eine Hintertür sein, wenn sie falsch konfiguriert sind. Ein einziger exponierter API oder ein missbrauchtes Servicekonto kann direkt zur Produktion führen. 

Jeder Schritt scheint für sich genommen einfach, doch zusammen bilden sie eine lange, zusammenhängende Kette. Und wie jede Kette ist sie nur so stark wie ihr schwächstes Glied. Deshalb muss Sicherheit Teil jedes einzelnen Schrittes sein und darf nicht erst am Ende angehängt werden. 

Warum CI/CD-Pipelines zu einem beliebten Angriffsziel geworden sind 

CI/CD-Pipelines sind das Herzstück moderner Softwarebereitstellung. Sie erstellen Ihren Code, führen Ihre Tests aus, signieren Ihre Artefakte und übertragen alles automatisch in die Produktion. Das ist viel Leistung an einem Ort. Und wissen Sie was? Angreifer haben es definitiv bemerkt. 

• Hoher Zugang, geringe Sichtbarkeit: CI/CD-Tools haben oft mehr Zugriff als die meisten Entwickler. Sie können Code extrahieren, Geheimnisse nutzen und ihn in der Produktion einsetzen – alles ohne menschliches Zutun. Das macht sie zu einer wahren Goldgrube für Angreifer. Und da das meiste davon im Hintergrund geschieht, können böswillige Änderungen eine Zeit lang unentdeckt bleiben. 

• Offenkundig aufbewahrte Geheimnisse: CI/CD-Umgebungen benötigen in der Regel Anmeldeinformationen für Dinge wie Cloud-Zugriff, Signaturschlüssel und APIs. Wenn diese Geheimnisse jedoch im Klartext gespeichert, falsch konfiguriert oder mit zu vielen Berechtigungen versehen sind, sind sie für Angreifer, die Zugriff auf die Pipeline erhalten, ein leichtes Ziel. 

• Viele Tools, viele Lücken: Die Pipeline besteht nicht nur aus einem Tool, sondern aus einer Mischung von Git-Plattformen, Runnern, Plugins, Paketmanagern, Cloud-Diensten und vielem mehr. Ist ein Teil dieser Kette unsicher oder ungepatcht, öffnet das Tür und Tor. Angreifer müssen nicht alles zerstören. Ein einziges Teil reicht aus. 

• Automatisierung ausnutzen: Sobald Angreifer in die Pipeline eingedrungen sind, können sie den Schaden automatisieren. Sie können Malware in einen Build einschleusen, Umgebungsvariablen ändern oder Geheimnisse an einen externen Server senden – und das alles, ohne ständigen Zugriff zu benötigen. Die Pipeline erledigt die Arbeit für sie. 

Warum Sie sich kümmern sollten 

Wenn ein Angreifer Ihre CI/CD-Pipeline kompromittiert, kann er schädliche Updates direkt an Ihre Benutzer senden. Keine Warnungen. Keine Alarme. Nur eine sauber aussehende Bereitstellung mit etwas Bösartigem darin. 

CI/CD sorgt für eine schnelle und reibungslose Code-Auslieferung, ohne geeignete Kontrollen sind Angriffe jedoch auch schnell und leise. Die Sicherung der Pipeline ist nicht nur eine DevOps Job mehr; es hat für die Sicherheit Priorität. 

Code Signing richtig gemacht 

Codesignatur ist wie ein Wachssiegel auf Ihrem Softwarepaket. Es beweist, dass der Code wirklich von Ihnen stammt und nicht manipuliert wurde. Ohne ordnungsgemäße Code-Signierung könnte jeder schädlichen Code in Ihre App oder Ihr Update einschleusen. Das bedeutet, dass Benutzer möglicherweise unwissentlich etwas Gefährliches installieren. 

Das Signieren Ihres Codes schafft zusätzliches Vertrauen. Es signalisiert Benutzern und Systemen: „Das ist echt und kann sicher ausgeführt werden.“ Es trägt auch zur Einhaltung von Vorschriften bei. Viele Vorschriften verlangen den Nachweis, dass Software während der Bereitstellung nicht manipuliert wurde. Es geht aber nicht nur darum, eine Signatur anzubringen. Es geht darum, es richtig zu machen, sichere Schlüssel zu verwenden, diese Schlüssel zu schützen und die Signierung in Ihre Build- und Release-Pipeline zu integrieren. Wenn die Code-Signierung umständlich oder manuell erfolgt, wird sie oft übersprungen oder vermasselt. Das birgt Risiken. 

Um es richtig zu machen, sind Automatisierung, starke Kryptografie und klare Richtlinien erforderlich. 

In der heutigen Softwarewelt, in der Angriffe aus Ihrer Lieferkette kommen können, ist eine starke Code-Signierung ein Muss und kein nettes Extra. 

SBOMs, Bescheinigungen und Transparenz in der gesamten Kette 

In Software-Lieferketten gilt: Was man nicht sieht, kann man nicht schützen. Hier kommen Dinge wie SBOMs und Attestierungen ins Spiel. Sie geben Ihnen ein klares Bild davon, was in Ihrer Software steckt und wie es dorthin gelangt ist. 

Was ist überhaupt eine SBOM? 

SBOM steht für Software Bill of Materials. Stellen Sie sich das als eine Zutatenliste Ihrer Software vor, die alle Komponenten, Bibliotheken und Abhängigkeiten auflistet, die zusammen gebündelt sind. Es hilft Teams, Schwachstellen schnell zu erkennen und erleichtert die Einhaltung von Vorschriften erheblich. 

Warum sind Bescheinigungen wichtig? 

Attestierungen sind wie digitale Quittungen, die bestimmte Schritte während Ihres Build- oder Release-Prozesses bestätigen. Eine Attestierung kann beispielsweise belegen, dass Ihr Code auf Schwachstellen geprüft oder mit einem vertrauenswürdigen Schlüssel signiert wurde. 

Die gesamte Kette im Blick 

Zusammen bieten SBOMs und Attestierungen einen besseren Einblick in den Inhalt und die Entwicklung Ihrer Apps. Diese Transparenz hilft, Probleme frühzeitig zu erkennen, Risiken zu vermeiden und schneller zu reagieren, wenn etwas schiefgeht. 

Mehr Transparenz, mehr Sicherheit 

Wenn Sie genau wissen, was in der Produktion läuft, und Sie den Nachweis haben, dass Ihr Code die richtigen Prüfungen durchlaufen hat, können Sie Ihrer Software leichter vertrauen und dies auch gegenüber Kunden und Prüfern leichter nachweisen. 

Wie CodeSign Secure von EC Ihnen hilft, Ihre Software von der Erstellung bis zur Auslieferung zu sichern 

Unser CodeSign Secure ist wie der Bodyguard Ihrer Software und stellt sicher, dass vom Zeitpunkt der Erstellung Ihres Codes bis zum Erreichen der Benutzer alles legal bleibt. 

Ihre Container-Images und andere Artefakte werden automatisch signiert, sodass Sie immer sicher sein können, dass sie nicht manipuliert wurden. Sie müssen sich nicht mehr fragen, ob das, was in der Produktion ist, mit dem übereinstimmt, was Sie getestet haben. 

Auf unserer Plattform können Sie außerdem sogenannte Attestierungen anhängen. Diese belegen, dass Ihr Build bestimmte Sicherheitsprüfungen oder Compliance-Schritte bestanden hat. So erhalten Sie vollständige Transparenz über den Werdegang Ihrer Software. 

Darüber hinaus funktioniert es reibungslos mit gängigen CI/CD-Tools, sodass sich das Signieren und Verifizieren nahtlos in Ihre vorhandenen Arbeitsabläufe einfügt, ohne diese zu verlangsamen. 

Und da unser CodeSign Secure moderne Standards unterstützt, funktioniert es gut mit Tools in der gesamten Lieferkette, sodass die Vertrauenswürdigkeit Ihrer Software bei jedem Schritt leichter gewahrt bleibt. 

Mit unserer Plattform unterzeichnen Sie nicht nur Code, sondern bauen auch Vertrauen in das auf, was Sie liefern. 

Compliance-fähige Sicherheit: Erfüllung der Anforderungen von SLSA, NIST, SSDF und CRA 

Die Sicherheit Ihrer Software-Lieferkette ist nicht nur eine gute Praxis, sondern oft auch unerlässlich, um Branchenstandards und -vorschriften einzuhalten. Hier kommen Frameworks wie SLSA, NIST SSDF und CRA ins Spiel. 

Was sind diese Frameworks? 

• SLSA (Supply-chain Levels for Software Artifacts) ist eine Checkliste, um sicherzustellen, dass Ihre Build-Prozesse vertrauenswürdig und vor Manipulationen geschützt sind. 

• NIST SSDF (Secure Software Development Framework) bietet Richtlinien zum Integrieren von Sicherheit in Ihren Entwicklungslebenszyklus und konzentriert sich dabei auf die Reduzierung von Risiken bei der Softwarebereitstellung. 

• CRA (Cybersecurity Risk Assessment) hilft Unternehmen, Risiken in ihrer gesamten Software-Lieferkette zu identifizieren und zu verwalten. 

Warum sind sie wichtig? 

Wenn Sie diese Frameworks befolgen, ergreifen Sie konkrete Maßnahmen, um Ihre Pipeline abzusichern und Ihre Software zu schützen. Sie bieten klare, umsetzbare Anleitungen, sodass Sie nicht nur raten müssen, was Sie sichern müssen. 

Wie CodeSign Secure hilft 

Plattformen wie unser CodeSign Secure erleichtern das Abhaken dieser Kästchen. Durch die Automatisierung Codesignatur und Artefaktbescheinigung unterstützt unsere Plattform Ihre Compliance-Bemühungen ohne zusätzlichen manuellen Arbeitsaufwand. 

Letztendlich hilft Ihnen die Einhaltung dieser Standards dabei, das Vertrauen Ihrer Kunden, Partner und Prüfer aufzubauen und gleichzeitig die Bösewichte fernzuhalten. 

Fazit 

In der Software-Lieferkette geht es nicht mehr nur darum, sauberen Code zu schreiben. Es geht darum zu wissen, was in Ihre Builds einfließt, wie Ihre Software zusammengestellt wird und in der Lage zu sein, nachzuweisen, dass dabei nichts Undurchsichtiges passiert ist. 

Angreifer werden immer raffinierter und zielen auf die Tools und Automatisierungen ab, auf die Sie sich täglich verlassen. Ob es sich um eine kompromittierte Abhängigkeit, einen fehlerhaften CI-Job oder ein heimtückisches, unsigniertes Artefakt handelt – kleine Sicherheitslücken können zu großen Problemen führen. 

Aus diesem Grund sind Sichtbarkeit, Signierung und Rückverfolgbarkeit keine optionalen Dinge mehr. Sie bilden die Grundlage. 

Unsere CodeSign Secure hilft Ihnen, diese Basislinie zu verbessern, indem Ihre Artefakte vom Build bis zur Produktion gesichert werden. Mit integrierter Unterstützung für automatisches Signieren, detaillierte Bescheinigungen und SBOM-Integration erleichtert unsere Plattform den Aufbau von Vertrauen in jeden Teil Ihrer Pipeline. 

Und wenn Sie hohe Standards wie SLSA Level 3 oder höher anstreben, unterstützt Sie unsere Plattform mit reproduzierbarer Build-Unterstützung, sodass Sie Byte für Byte überprüfen können, ob das, was Sie lokal erstellen, genau dem entspricht, was in der Produktion landet. 

In einer Welt, in der das Vertrauen in Software ständig auf die Probe gestellt wird, bietet Ihnen unsere Plattform die Tools, um Ihre Arbeit zu zeigen und dafür einzustehen.