Sicherung der Software-Lieferkette: Schutz des digitalen Ökosystems

In der heutigen, sich rasant entwickelnden digitalen Welt, in der jeder Geschäftsbetrieb von einem reibungslosen Ablauf mit Softwarelösungen abhängt, ist die Gefahr von Angriffen auf die Software-Lieferkette allgegenwärtig. Jüngste Ereignisse wie der berüchtigte SolarWinds- Datendiebstahl unterstreichen die Dringlichkeit, diese heimtückischen Bedrohungen zu verstehen und sich dagegen zu verteidigen. Dieser umfassende Blogbeitrag beleuchtet die Komplexität dieser Angriffe, analysiert ihre Feinheiten und präsentiert eine fundierte Strategie zur Stärkung der Abwehr.

Die Sicherung der Software-Lieferkette lässt sich kurz wie folgt zusammenfassen: Keine einzelne Kontrollmaßnahme deckt die gesamte Angriffsfläche vom Build-Prozess bis zur Veröffentlichung ab. Die Signierung beweist Herkunft und Integrität eines Artefakts ab dem Zeitpunkt der Signierung; Malware-Scans überprüfen den Codeinhalt zu einem bestimmten Zeitpunkt; die SLSA-Build-Provenienz verifiziert, dass der Build-Prozess selbst nicht manipuliert wurde; SBOMs dokumentieren den tatsächlichen Inhalt des Artefakts. Jede dieser Maßnahmen schließt eine bestimmte Sicherheitslücke, und das Auslassen einer einzelnen Maßnahme lässt diese Lücke bestehen.

Wichtige Erkenntnisse

• Codesignierung und Malware-Scanning lösen unterschiedliche Probleme: Scanning prüft Inhalte vor der Signierung, während Signierung vor nachträglichen Änderungen schützt. Keines der beiden Verfahren ersetzt das andere.
• Diese Seite bildet die gesamte Angriffsfläche vom Build-Prozess bis zur Veröffentlichung ab und zeigt, wo die einzelnen Kontrollmaßnahmen Anwendung finden. Detaillierte Informationen zu den unten aufgeführten einzelnen Angriffen finden Sie unter [Link einfügen]. Die häufigsten Angriffe auf Software-Lieferketten und Aktueller Stand der Angriffe auf die Software-Lieferkette.

Angriffsfläche bis zur Veröffentlichung und Anwendungsbereiche der Kontrollmaßnahmen

Praktikum	Risiko	Kontrolle
Quellcode / Abhängigkeiten	Schädlicher oder anfälliger Drittanbietercode wurde vor dem Build eingeschleust	Abhängigkeitsanalyse, SBOM-Generierung
Umgebung erstellen	Build-Server kompromittiert, Schadcode vor der Signierung eingeschleust (SolarWinds-Muster)	Build-Isolation, Hash-Validierung (z. B. Build-Verifizierer), SLSA-Bauherkunft
Unterzeichnung	Zertifikatsdiebstahl, unzureichende Schlüsselverwaltung	HSM-gestützte Schlüsselspeicherung, rollenbasierte Genehmigung von Signaturen
Vertrieb	Manipulation während der Übertragung oder durch einen kompromittierten Aktualisierungsmechanismus	Signaturprüfung bei Installation/Aktualisierung, Zeitstempelung
Nach der Veröffentlichung	Kompromittierung nach der Verteilung entdeckt	Widerruf, Neuunterzeichnung, SBOM-gesteuerte Folgenabschätzung

Das Orchester der Software-Lieferketten: Die Komplexität verstehen

Stellen Sie sich eine Software-Lieferkette wie eine Symphonie aus miteinander verbundenen Komponenten vor – von Codezeilen über Drittanbieterbibliotheken und Entwicklungswerkzeuge bis hin zu Bereitstellungsmechanismen und Überwachungssystemen nach dem Launch. So wie ein einzelner schiefer Ton eine Melodie stören kann, kann ein kompromittiertes Glied in dieser Kette Schockwellen durch das gesamte System senden, den Betrieb unterbrechen und die Sicherheit gefährden.

Die Versuchung für Cyberkriminelle: Warum Angriffe auf Software-Lieferketten sinnvoll sind

Angriffe auf Software -Lieferketten üben aufgrund ihres Potenzials, mit minimalem Aufwand maximalen Schaden anzurichten, eine starke Anziehungskraft auf Cyberkriminelle aus. Ein Lieferkettenangriff, auch Wertschöpfungsketten- oder Drittanbieterangriff genannt, liegt vor, wenn jemand über einen externen Partner oder Anbieter mit Zugriff auf Ihre Systeme und Daten in Ihr System eindringt. Durch das Eindringen in einen einzigen Knotenpunkt der Lieferkette können Angreifer unbemerkt Schadcode einschleusen oder legitime Komponenten manipulieren und sich so Zugang zu einem weitverzweigten Netzwerk von Systemen verschaffen. Dieser Dominoeffekt verstärkt ihre Reichweite und ihr Schadenspotenzial.

Beispiel aus der Praxis

• SolarWinds (2020)

  Im Dezember 2020 ereignete sich einer der bedeutendsten und weitreichendsten Angriffe auf die Lieferkette der jüngeren Geschichte: Das Netzwerkmanagement-Softwareunternehmen SolarWinds wurde Opfer eines ausgeklügelten Cyberangriffs. Die Angreifer drangen in die Systeme von SolarWinds ein und schleusten Schadcode in die Orion-Software-Updates des Unternehmens ein. Infolgedessen luden rund 18,000 Kunden und Organisationen, darunter mehrere Regierungsbehörden und Privatunternehmen, unwissentlich die manipulierten Updates herunter. Dieser Angriff verdeutlichte die dringende Notwendigkeit sicherer Software-Updates innerhalb der Lieferkette. Er zeigte, wie weitreichende Folgen ein einziges kompromittiertes Update haben kann, und unterstrich die Bedeutung robuster Sicherheitsmaßnahmen und Wachsamkeit in der Software-Lieferkette.

• Equifax (2017)

  Im Jahr 2017 kam es bei Equifax, einem großen Kreditauskunftsunternehmen, zu einem kolossalen Datenleck, von dem sage und schreibe 147 Millionen Kunden betroffen waren. Der Vorfall wurde auf eine Sicherheitslücke in der Website-Software von Equifax zurückgeführt. Die Ursache war, dass ein wichtiger Sicherheitspatch für eine bekannte Schwachstelle nicht installiert wurde. Dieser Vorfall verdeutlicht die Bedeutung eines ordnungsgemäßen Patch-Managements als essenzieller Aspekt der Software-Lieferkette. Werden bekannte Sicherheitsprobleme nicht behoben, kann ein Unternehmen anfällig für böswillige Angreifer werden, die Schwachstellen in der Lieferkette ausnutzen.

• CCleaner (2017)

  Im Jahr 2017 wurde CCleaner, ein weit verbreitetes Systemoptimierungstool, kompromittiert. Angreifer drangen in die Lieferkette von CCleaner ein und schleusten Schadcode in die Anwendung ein. Dieser Vorfall verdeutlichte die dringende Notwendigkeit sicherer Codesignatur und gründlicher Verifizierungsprozesse innerhalb der Lieferkette. Er erinnert uns eindringlich daran, dass selbst vertrauenswürdige Software kompromittiert werden kann und unterstreicht die Bedeutung umfassender Sicherheitsmaßnahmen während des gesamten Entwicklungs- und Vertriebsprozesses.

• Apple XCodeGhost (2015)

  Im Jahr 2015 nahmen Hacker chinesische iOS-Entwickler ins Visier, indem sie das Entwicklungstool XCode manipulierten, mit dem iOS-Anwendungen erstellt werden. Den Angreifern gelang es, Schadcode in das Tool einzufügen, der unwissentlich in mehrere iOS-Apps im App Store integriert wurde. Dieser Vorfall unterstreicht die Bedeutung sicherer Entwicklungstools und die Notwendigkeit, Drittanbieterkomponenten, die in die Software-Lieferkette integriert werden, rigoros zu prüfen. Er ist ein warnendes Beispiel dafür, wie gefährlich es ist, sich auf ungeprüfte Tools und Komponenten zu verlassen.

• NotPetya (2017)

  Der NotPetya-Malware-Angriff 2017 war ein Supply-Chain-Angriff von erschütterndem Ausmaß. Er zielte zunächst auf die ukrainische Regierung und Infrastruktur, breitete sich aber schnell auf andere Länder aus. Angriffsvektor war eine kompromittierte Supply-Chain des Softwareunternehmens MeDoc, das die Malware über ein Update seines weit verbreiteten Steuerbuchhaltungsprogramms verbreitete. Dieser Angriff zeigte, wie ein scheinbar routinemäßiges Software-Update zu einem Vektor für weitreichendes Cyber-Chaos werden kann, und unterstreicht die Notwendigkeit robuster Sicherheitsmaßnahmen entlang der gesamten Lieferkette.

• TSMC, taiwanesischer Chiphersteller (2018)

  Im Jahr 2018 wurde der taiwanesische Chiphersteller TSMC Opfer eines Angriffs auf seine Lieferkette mit erheblichen Folgen. Die Schadsoftware gelangte über den Software-Update-Mechanismus in die Systeme von TSMC, nachdem ein Lieferant infizierte Software auf einigen seiner Maschinen installiert hatte, ohne zuvor Virenscans durchzuführen. Dieser Angriff betraf über 10,000 Geräte in einigen der modernsten Anlagen von TSMC und verdeutlichte die Schwachstellen, die durch laxe Sicherheitspraktiken der Lieferanten in der Lieferkette entstehen können. Dies ist eine deutliche Mahnung für die Notwendigkeit strenger Überprüfungen und Sicherheitsmaßnahmen innerhalb eines Unternehmens und seiner Lieferkettenpartner.

Schwachstellen und Angriffsvektoren

• Komponenten von Drittanbietern

  Unternehmen nutzen häufig Bibliotheken und Tools von Drittanbietern, um die Entwicklung zu optimieren. Diese Abhängigkeit erzeugt jedoch einen Dominoeffekt: Eine Schwachstelle in einer Komponente kann sich zu weitreichenden Schwachstellen in verschiedenen Softwareanwendungen ausweiten.

• Insider-Bedrohungen

  Personen innerhalb einer Organisation mit böswilligen Absichten können ihren privilegierten Zugriff auf wichtige Systeme ausnutzen, was zu potenziell verheerenden Sicherheitsverletzungen führen kann.

• Fehler im Entwicklungsprozess

  Lücken in Entwicklungs- und Aktualisierungsprozessen, wie etwa unzureichende Tests oder ungesicherte Aktualisierungsmechanismen, bieten Angreifern, die nach Schwachstellen suchen, Einfallstore für deren Ausnutzung.

Die duale Natur von Open Source ausbalancieren: Innovation und Risiko

Der Aufstieg von Open-Source-Software hat die Entwicklungsarbeit massiv beschleunigt, Innovationen gefördert und Projekte vorangetrieben. Dieses kollaborative Ökosystem birgt jedoch auch Herausforderungen und erfordert ständige Wachsamkeit, um die Sicherheit angesichts der rasanten Entwicklung der Softwarelandschaft zu gewährleisten. Wie es so schön heißt: „Open-Source-Software spielt eine zentrale Rolle in der modernen Entwicklung, aber ihre kollaborative Natur kann Sicherheitslücken verursachen. Organisationen müssen diese Projekte aktiv überwachen und Schwachstellen beheben, um eine sichere Lieferkette sicherzustellen.“

Verbesserung der Sicherheit mit Best Practices und Strategien

• Gründliche Prüfung von Komponenten von Drittanbietern

  Organisationen müssen regelmäßige und sorgfältige Prüfungen von Tools, Bibliotheken und Softwarekomponenten von Drittanbietern durchführen, um Schwachstellen zu identifizieren und sich gegen potenzielle Sicherheitsverletzungen zu schützen.

• Nutzen Sie DevSecOps

  Die Integration von Sicherheitspraktiken von Beginn der Softwareentwicklung an gewährleistet einen robusten Schutzmechanismus gegen neu auftretende Bedrohungen.

• Kontinuierliche Überwachung und Anomalieerkennung

  Durch den Einsatz fortschrittlicher KI-gesteuerter Tools zur kontinuierlichen Überwachung können Unternehmen Anomalien, die auf potenzielle Verstöße hinweisen könnten, schnell erkennen.

• Ganzheitliche Anwenderschulung

  Durch die Aufklärung aller Beteiligten über die sich entwickelnde Bedrohungslandschaft und die Weitergabe bewährter Sicherheitspraktiken kann die Organisation zu einer sicheren Software-Lieferkette beitragen.

• Rotes Team-Testen

  Durch den Einsatz ethischer Hacker zur Simulation von Angriffen und Aufdeckung versteckter Schwachstellen können Unternehmen ihre Abwehrmaßnahmen proaktiv stärken.

Kennzahlen und Daten: Die Schwere von Supply-Chain-Angriffen verstehen

• Zunahme bösartiger Open-Source-Pakete

  Der Sonatype-Bericht „State of the Software Supply Chain 2026“ identifizierte mehr als 454,600 neue bösartige Open-Source-Pakete im Jahr 2025, ein Anstieg von 75 % gegenüber dem Vorjahr (Pressemitteilung veröffentlicht am 28. Januar 2026).

• Finanzielle Auswirkungen von Verstößen

  Laut dem IBM-Bericht „Cost of a Data Breach Report 2025“ kostet ein Datenleck in der Lieferkette durchschnittlich 4.91 Millionen US-Dollar – der längste im Rahmen der Studie erfasste Angriffsvektor.

• Tage zum Identifizieren und Lindern

  Laut demselben IBM-Bericht dauert es im Durchschnitt 267 Tage, bis Lieferkettenverletzungen erkannt und eingedämmt werden können – länger als bei allen anderen von IBM erfassten Angriffsvektoren.

• Beteiligung Dritter an Datenschutzverletzungen

  Die Beteiligung Dritter an Datenschutzverletzungen hat sich innerhalb eines Jahres von 15 % auf 30 % verdoppelt – die größte jemals im Verizon 2025 Data Breach Investigations Report verzeichnete Veränderung innerhalb eines Jahres.

Förderung der kollektiven Verteidigung: Gemeinsam gegen Bedrohungen

Neben individuellen Anstrengungen kann eine branchenweite Zusammenarbeit ein wirksames Mittel zur Abwehr von Bedrohungen darstellen. Der Austausch von Bedrohungsinformationen, Schwachstellen und Abwehrstrategien zwischen Unternehmen stärkt das Ökosystem gegen potenzielle Angriffe.

Wie kann Encryption Consulting Supply-Chain-Angriffe verhindern?

Der Build Verifier von EC spielt eine entscheidende Rolle bei der Abwehr potenzieller Supply-Chain-Angriffe, indem er die Integrität und Authentizität von Softwarekomponenten innerhalb der Lieferkette sicherstellt. Durch die sorgfältige Überprüfung des Quellcodes und der Binärdateien der Software vor der Integration in die Entwicklungspipeline erkennt der Build Verifier jegliche nicht autorisierten oder böswilligen Änderungen. Er nutzt fortschrittliche kryptografische Techniken wie digitale Signaturen und Hash-Funktionen, um Vertrauen aufzubauen und die Herkunft von Softwarekomponenten zu überprüfen. Darüber hinaus überwacht er den Build- und Bereitstellungsprozess auf unerwartete Änderungen und warnt Entwickler in Echtzeit vor potenziellen Bedrohungen. Dieser proaktive Ansatz schützt nicht nur vor Manipulationen kritischer Softwarekomponenten, sondern bietet auch ein höheres Maß an Sicherheit entlang der gesamten Software-Lieferkette und macht sie deutlich widerstandsfähiger gegen böswillige Akteure, die die Integrität von Software- und Hardwaresystemen gefährden wollen.

Fazit

Zum Abschluss dieser Diskussion ist es wichtig, sich vor Augen zu führen, dass die Symphonie der Sicherheit auf proaktiven Maßnahmen und ständiger Wachsamkeit beruht. Um Angriffe auf die Lieferkette zu verhindern, müssen Unternehmen Transparenz und Vertrauen priorisieren. Regelmäßige Audits, kontinuierliche Überwachung durch fortschrittliche Technologien und die frühzeitige Integration von Sicherheit sind grundlegende Bestandteile einer robusten Verteidigungsstrategie. Red-Team-Tests liefern wertvolle Erkenntnisse und ermöglichen es Unternehmen, Schwachstellen zu identifizieren, bevor böswillige Akteure dies tun.

Häufig gestellte Fragen

Ist eine Codesignierung noch notwendig, wenn der Code vor der Veröffentlichung auf Malware gescannt wird?

Ja. Das Scannen prüft den Codeinhalt zu einem bestimmten Zeitpunkt; die Signierung schützt vor späteren Änderungen, sei es durch Manipulation während der Übertragung, einen kompromittierten Vertriebskanal oder eine spätere unautorisierte Änderung. Sie adressieren unterschiedliche, sich nicht überschneidende Risiken im Entwicklungsprozess.

Ersetzt ein SBOM die Notwendigkeit der Codesignierung?

Nein. Ein SBOM dokumentiert die Komponenten eines Artefakts und ist nützlich für die Bewertung der Auswirkungen von Sicherheitslücken, falls sich eine Komponente später als kompromittiert erweist. Es überprüft jedoch nicht, ob das Artefakt selbst nach der Erstellung manipuliert wurde; dies ist die Aufgabe der Signierung.