SOFTWARE SUPPLY CHAIN MANAGEMENT TEIL 3

Eine Industrie im Wandel

Vor fast zwanzig Jahren sagte der Sicherheitstechnologe Bruce Schneier: „Es gibt keine echten Konsequenzen für schlechte Sicherheit oder Software. Bis vor kurzem haben wir diesen Satz ergänzt mit „… und es hat sich kaum etwas geändert“. Aber das stimmt nicht mehr – die Software-Industrie ist nun gezwungen, sich zu ändern.

Die meisten Unternehmen werden immer noch von einem Motiv angetrieben: dem Wunsch, schneller Innovationen zu entwickeln und Marktanteile zu gewinnen als die Konkurrenz. Unternehmen erkennen zunehmend, dass "innovativ sein" auch Qualität, Sicherheit und Wartungsfreundlichkeit bedeutet.

Darüber hinaus verändern die zunehmende staatliche Regulierung, die sich ändernden Industriestandards und die wachsende Bedeutung der Open-Source-Lizenzierung den Blick auf die Software-Entwicklung. In diesem Abschnitt gehen wir auf einige externe Faktoren ein, die das Software Supply Chain Management beeinflussen.

Gegenspieler der Supply Chain

Vor fast 9 Jahren wurde die Welt Zeuge der ersten bekannten Apache-Struts-Schwachstelle. In diesem Fall hat Apache die Sicherheitslücke verantwortungsbewusst und öffentlich bekanntgegeben und gleichzeitig eine neue Version zur Behebung des Problems angeboten. Obwohl Apache sein Bestes tat, um die Öffentlichkeit zu warnen und Angriffe zu verhindern, hörten viele Unternehmen entweder nicht zu oder handelten nicht rechtzeitig. Das führte in der Praxis zu zahlreichen Angriffen. Einfach ausgedrückt: Hacker profitieren in hohem Maße davon, wenn Unternehmen das Steuer aus der Hand geben und nicht rechtzeitig auf die öffentlich gewordenen Sicherheitslücken reagieren.

Seitdem gab es noch viele weitere Vorfälle: Shellshock, Heartbleed, die Commons Collection und zuletzt der Log4j-Exploit und Spring4Shell. All das geschah nach dem gleichen Muster: Nach der Veröffentlichung wurden die Schwachstellen flächendeckend ausgenutzt.

In Wirklichkeit sind solche Schwachstellen jedoch keine Seltenheit – ganze 29 % der gängigen Open-Source-Komponenten haben eine bekannte Schwachstelle.

Teil3-1bQuelle: „2021 State of the Software Supply Chain“ von Sonatype

Bösartige Angriffe auf Software Supply Chains

Heutzutage schaffen bösartige Akteure jedoch eigene Angriffsmöglichkeiten. 

Mit diesen neuen Angriffen auf unsere Software Supply Chains, bei denen Anmeldeinformationen für Open-Source-Projekte kompromittiert und bösartiger Code absichtlich in Open-Source-Bibliotheken eingeschleust wird, können Hacker sozusagen „den Brunnen vergiften“. Der anfällige Code wird dann wiederholt von Millionen von Software-Entwicklern heruntergeladen, die ihre Anwendungen unwissentlich kompromittieren. Das spielt den bösartigen Akteuren direkt in die Karten.

Solche Angriffe auf die Software Supply Chain nehmen in alarmierendem Maße zu: 2021 stieg die Zahl der Cyberangriffe auf Open-Source-Anbieter um ganze *650 %*. Bei Sonatype haben wir proaktiv mehr als 63.000 Versuche zur Veränderung von Komponenten ermittelt.

Gruppe 2811Quelle: „2021 State of the Software Supply Chain“ von Sonatype

Angriffe in diesem Bereich sind in dreierlei Hinsicht einzigartig:

  • 1. Sie bemühen sich häufig darum, legitim zu erscheinen, da sie unter dem Radar fliegen und Teil der Software Supply Chain werden möchten.
  • 2. Wenige sind reine Service-Angriffe, etwa DDOS-Angriffe (Distributed Denial of Service).
  • 3. Sie zielen selten auf eine bestimmte Gruppe oder Person ab. Komponenten sind für die breite Nutzung und einfache Verbreitung ausgelegt.

Vorgelagerte (upstream) Software-Ziele , die sich auf nachgelagerte (downstream) Opfer auswirken

Herkömmliche Angriffe auf Software konzentrierten sich entweder auf die Benutzer oder ihr Ziel. Oft täuschen bösartige Akteure Personen, damit sie Malware öffnen oder ihre Zugangsdaten teilen. Außerdem werden häufig öffentlich bekannte Software-Schwachstellen ausgenutzt, um ungepatchte Server anzugreifen. Diese gelten in der Software Supply Chain als „downstream“, da sie nicht mit dem Entwicklungsprozess verbunden sind.

In letzter Zeit haben sich jedoch Angriffe wie der raffinierte SolarWinds-Angriff 2019 darauf konzentriert, die „upstream“ Software-Entwicklung anzugreifen. Hierbei beteiligen sich die Angreifer an gemeinschaftlichen Open-Source-Projekten, um den Quellcode mit Malware zu verunreinigen. Dieser Code wird dann als Komponente unserer alltäglichen Software verbreitet.

Teil3-weiterführende-Lektüre

 

Einige Beispiele für häufige bösartige Angriffe auf die Software Supply Chain:

  • Typosquatting – Einer der ältesten Angriffe und immer noch weit verbreitet. Die Bezeichnung „Typosquat“ bezieht sich auf bösartige Komponenten, die ähnliche Software unter einem ähnlichen Namen anbieten („Typo“ bedeutet übersetzt „Tippfehler“, während „squat“ für „besetzen“ steht). Die Schadsoftware zielt also auf Entwickler ab, die einen falschen Namen eingeben oder eine andere Schreibweise verwenden, z. B. „collor“ statt „color“.
  • Brandjacking – Ähnlich wie Typosquatting, aber sehr überzeugend benannt nach Technologiemarken, Websites und Projekten.
  • Dependency Confusion – Clever getarnte Malware kann Entwicklungstools manchmal so dazu verleiten, gleichnamige Komponenten aus dem öffentlichen Repository anstelle von intern erstellten Paketen herunterzuladen. Mehrere große Unternehmen wurden Anfang 2021 von solchen Angriffen überrascht.
  • Project Hijacks – Wenn die oben genannten Taktiken nicht funktionieren, werden gerne beliebte Projekteigentümer ins Visier genommen.

Solche Angriffe können zu Datenverlusten, zur Installation von Kryptominern oder Schlimmerem führen. Und je früher in der Software Supply Chain ein Paket kompromittiert wird, desto mehr Ziele können betroffen sein.

Schnelle Angriffe mithilfe öffentlich gewordener Schwachstellen

Da die Software-Entwicklung allgemein sehr viel schneller geworden ist, können nun auch bösartige Akteure Exploits deutlich rascher vorbereiten. Hatten Unternehmen vor zehn Jahren im Durchschnitt fast einen Monat Zeit, um auf wichtige Meldungen über Schwachstellen in der Supply Chain zu reagieren, schließt sich dieses Zeitfenster mittlerweile. Die Struts-Sicherheitslücke im Jahr 2017 (die vor allem zu einem öffentlichkeitswirksamen Vorfall bei Equifax führte) hatte ein Zeitfenster von 5 Tagen. 

Ende 2021 war das Zeitfenster für die Log4j-Schwachstelle gerade einmal zwei Tage lang:
Gruppe 2820Übernommen von IBM X-Force / Analyse von Gartner Research (September 2016)


Schnelle interne Entwicklungsprozesse sind daher nicht mehr nur ein Wettbewerbsvorteil, sondern auch eine notwendige Sicherheitsmaßnahme. Und der Trend ist eindeutig: Unternehmen müssen ständig optimieren, um effektiv auf Schwachstellen reagieren zu können.

Mehr als nur Rufschädigung: Vorfälle ziehen Klagen nach sich

Es gibt zwar eine lange Liste von Möglichkeiten, wie Unternehmen die Schäden aus einem Sicherheitsvorfall minimieren können, aber eine mangelhafte Behebung kann nun auch zu rechtlichen Konsequenzen führen. Im Zuge der Log4j-Sicherheitslücke wurde US-Unternehmen mitgeteilt, dass sie möglicherweise von der Federal Trade Commission verklagt werden, weil sie keine Maßnahmen zur Absicherung ihrer eigenen Systeme getroffen haben. 

Dies zeigt, dass nicht nur die Entwickler ein gutes Verständnis der Software Supply Chain haben müssen – es liegt ebenso im wirtschaftlichen und nationalen Interesse.

Anforderungen für die Einhaltung von Normen

Obwohl in immer mehr Branchen Software eingesetzt wird, gibt es leider keinen einheitlichen Standard für die Software-Compliance, der die Integrität der Software Supply Chain gewährleistet. Die meisten Standards und Compliance-Anforderungen sind immer noch branchenspezifisch.

Beispielsweise betrifft der PCI-DSS-Standard Unternehmen, die mit Kreditkartenzahlungen arbeiten. Die Gesundheitsbranche unterliegt hingegen dem HIPAA (Health Insurance Portability and Accountability Act). Unternehmen, die von Europa aus tätig sind, müssen sich mit der DSGVO auseinandersetzen, während staatliche US-Datenquellen dem FISMA-Gesetz unterliegen.


Mit Bidens Cybersecurity Executive Order trat in diesem Jahr das erste föderale Mandat für die Sicherheit kritischer Software-Komponenten in Kraft. Diese neuen Anforderungen, die wir auch in der Einleitung erörtert haben, betreffen direkt die Software Supply Chain sowie die Software-Transparenz.  Da die US-Bundesregierung einer der Hauptabnehmer von Software ist, könnte der Erlass weitreichende Konsequenzen haben. Sein Geltungsbereich ist aktuell auf diejenigen Unternehmen beschränkt, die Software für den Staat entwickeln oder an ihn verkaufen.

Nicht nur die Entwickler müssen ein gutes Verständnis der Software Supply Chain haben – es liegt ebenso im wirtschaftlichen und nationalen Interesse.

Was die Einhaltung von Standards anbelangt, so ist Software möglicherweise ein Opfer ihres eigenen Erfolgs: Die vielen Auswirkungen, die Software auf unser Leben hat, wird durch Gesetze auf Landes-, Regions-, Bundes- und internationaler Ebene noch verstärkt. Gleichzeitig entwickelt sich die Software-Entwicklung selbst weiter. Daher können wir nur empfehlen, Ihre eigene Branche nach fortlaufenden Schulungen, Best Practices, effektiven Richtlinien und Prozessüberwachung zu durchforsten.

Sonatype Envelope

Möchten Sie sich selbst von Nexus-Produkten überzeugen?