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.
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.
Quelle: „2021 State of the Software Supply Chain“ von SonatypeHeutzutage 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.
Quelle: „2021 State of the Software Supply Chain“ von SonatypeAngriffe in diesem Bereich sind in dreierlei Hinsicht einzigartig:
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.
Einige Beispiele für häufige bösartige Angriffe auf die Software Supply Chain:
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.
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:
Ü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.
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.
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.
Möchten Sie sich selbst von Nexus-Produkten überzeugen?
