Snyks State of Open Source Security 2023: Supply-Chain-Sicherheit, KI und mehr

KI, False Positives und die langsame Einführung von Sicherheitstools geben weiterhin Anlass zur Sorge. Schnellere Behebungen und Fortschritte bei der Supply-Chain-Sicherheit sind jedoch ermutigende Zeichen.

Der Vorfall mit Log4Shell im Jahr 2021 rückte die Sicherheit von Open-Source-Software – und insbesondere die Supply-Chain-Sicherheit – ins Rampenlicht. In den 18 Monaten nach dem Vorfall wurde der Sicherheit von Open-Source-Software mehr Aufmerksamkeit gewidmet als jemals zuvor. Organisationen wie OpenSSF und AlphaOmega sowie große Technologieunternehmen investieren beträchtliche Ressourcen in Tools und Weiterbildung. Doch verbessert sich die Sicherheit von Open-Source-Software tatsächlich? Und wo reichen die bisherigen Bemühungen noch nicht aus? 

Snyk wollte diese Frage in unserem neuesten Bericht beantworten: dem State of Open Source Security 2023. Dafür haben wir Hunderte Fachleute aus dem technischen Bereich befragt und anonymisierte Daten aus der tatsächlichen Nutzung unserer Produkt-Suite ausgewertet. Der Bericht beleuchtet den aktuellen Stand und die Zukunft der Supply-Chain-Sicherheit und zeigt Unternehmen angesichts des Wachstums der Software-Supply-Chain-Branche mögliche Wege auf. Hier sind einige unserer wichtigsten Erkenntnisse.

Die Supply-Chain-Sicherheit hält mit der Entwicklung nicht Schritt

Viele Unternehmen stehen vor einer Lücke zwischen Innovationen in der Supply Chain und deren Absicherung. Die meisten Unternehmen nutzen zwar fortschrittliche Supply-Chain-Technologien, doch unsere Umfrage ergab, dass die meisten Befragten diese Prozesse nicht durch Maßnahmen wie kontinuierliche Audits, die Überwachung indirekter Abhängigkeiten oder die frühzeitige Prüfung der Sicherheitsbewertungen von Open-Source-Paketen absichern. Besonders bemerkenswert: 40 % der Befragten setzen noch immer keine grundlegenden Sicherheitstechnologien wie Software Composition Analysis (SCA) und Static Application Security Testing (SAST) ein. 

Da Entwicklungs-Tools für Open Source weiter an Bedeutung gewinnen und die Aufmerksamkeit böswilliger Akteure auf sich ziehen, müssen Unternehmen den Einsatz von Ansätzen zur Supply-Chain-Sicherheit in Betracht ziehen.

Automatisierung und KI schaffen neue Chancen und Herausforderungen

Der Aufstieg von Automatisierung und KI wirkt sich eindeutig auf die Anwendungsentwicklung aus. Bei der Nutzung dieser Technologien für mehr Sicherheit sind große Fortschritte zu beobachten. Doch stärken oder schwächen diese neuen Technologien die Sicherheitslage? 

Unser Bericht zeigt, dass es gegenüber diesen neuen Technologien noch Vorbehalte gibt und die Meinungen dazu auseinandergehen, ob KI-Tools die Code-Sicherheit verbessern. Auch die Wirksamkeit der Sicherheitsautomatisierung wird unterschiedlich bewertet: 61 % der Befragten gaben an, dass die Automatisierung die Zahl der False Positives erhöht hat. 

Trotz dieser unterschiedlichen Einschätzungen setzen die meisten Unternehmen bei Entwicklung und Sicherheit weiterhin verstärkt auf diese neuen Technologien. Erst die Zeit wird zeigen, wie sich KI und Automatisierung auf die Sicherheit ihrer Software-Supply-Chain auswirken.

Die Supply-Chain-Sicherheit ist noch nicht nach links verschoben

Ein zentraler Grundsatz der Supply-Chain-Sicherheit ist es, Entwicklerinnen und Entwicklern zu ermöglichen, Schwachstellen früher im Software Development Lifecycle (SDLC) zu erkennen. Dazu brauchen sie die Tools und Schulungen, um sicherer zu programmieren und häufiger Scans durchzuführen. Diese Maßnahmen verbessern Tempo und Effizienz im SDLC, da weniger Builds bei Tests vor der Bereitstellung blockiert und zur Fehlerbehebung an die Entwicklungsteams zurückgeleitet werden. 

Unsere Umfrage ergab, dass auch die Verschiebung nach links noch nicht abgeschlossen ist. Nur 40 % der Befragten gaben an, dass ihr Unternehmen Sicherheitstools in die IDEs der Entwicklerinnen und Entwickler integriert. Ein noch kleinerer Anteil nutzt sie lokal über die Befehlszeile. Build-Tools und Code-Repositories sind mit jeweils rund 65 % die häufigsten Einsatzorte für Sicherheitstools. Das zeigt, dass Teams Tools für die Supply-Chain-Sicherheit noch immer eher spät im Entwicklungsprozess einsetzen – im Rahmen von Build- oder Code-Check-in-Prozessen statt kontinuierlich zur Absicherung des Codes. 

Damit die Vision einer proaktiven Verschiebung nach links vollständig umgesetzt werden kann, müssen Entwicklerinnen und Entwickler Zugriff auf dieselben Sicherheitstools haben wie DevOps-, Anwendungssicherheits- und andere nachgelagerte Teams. 40 % sind zwar kein schlechter Wert, dennoch sind Sicherheitstools in den wichtigsten Workflow-Tools der Entwicklung weiterhin nicht die Regel.

Zu viele False Positives durch Automatisierung

Viele Unternehmen haben automatisierte Sicherheitsmaßnahmen in ihre Code-Pipeline integriert. Das hat zu mehr False Positives bei Schwachstellenwarnungen geführt und kann die Produktivität beeinträchtigen. Laut Umfrage setzen 64 % der Unternehmen automatisierte Code-Analysen ein, 61 % automatisiertes Software-Update-Management, 59 % automatisierte Tests (Unit- und Sicherheitstests) und 58 % automatisierte sichere Programmierpraktiken (Linter, Formatierung usw.). Automatisierte Sicherheitstools erleichtern zwar das Scannen nach Schwachstellen, haben aber auch die Zahl der False Positives erhöht. 60 % der Befragten gaben an, dass die Automatisierung zu mehr False Positives geführt hat; 30 % berichteten von einem Rückgang. False Positives machten einen erheblichen Anteil aller Warnmeldungen aus: 62 % der Befragten gaben an, dass mindestens 25 % ihrer Schwachstellenwarnungen False Positives waren. 35 % berichteten, dass mindestens 50 % ihrer Warnmeldungen False Positives waren.

Dieser hohe Anteil an False Positives verursacht für Sicherheits- und Entwicklungsteams einen enormen technischen Mehraufwand und kann die Vorteile der Automatisierung zunichtemachen. Teams müssen Wege finden, False Positives zu reduzieren, um die Sicherheit der Software-Supply-Chain tatsächlich zu verbessern. 

Eine verstärkte Reaktion auf Sicherheitsbedrohungen hat Vor- und Nachteile

Mehrere aufsehenerregende Angriffe haben die Aufmerksamkeit auf die Supply-Chain-Sicherheit verstärkt. Gleichzeitig stehen Engineering- und Sicherheitsteams unter dem Druck staatlicher Stellen, etwa durch die Executive Order der Vereinigten Staaten zur Verbesserung der Cybersicherheit des Landes und den geplanten Cyber Resilience Act der EU. 

Aufgrund dieser Faktoren haben mehrere Befragte ihre Sicherheitsmaßnahmen in letzter Zeit deutlich verstärkt. Zu den Initiativen gehörten neue Tools, häufigere Code-Scans und Schulungen.

Trotz einer Vorgabe des Bundes für eine Software-Stückliste (SBOM) aus dem Jahr 2021 nutzen nur 42 % der Unternehmen eine SBOM. Und diejenigen, die eine verwenden, stehen vor einem „Turmbau zu Babel“ mit ihren SBOMs. Unser Bericht zeigt, dass Unternehmen verschiedene Tools für Softwareentwicklung, CI/CD und Supply-Chain-Sicherheit einsetzen, um SBOMs zu erstellen. Daher sind SBOMs heute uneinheitlich und möglicherweise nicht interoperabel, was eine aussagekräftige Analyse erschwert. Viele Unternehmen setzen also zwar einen Haken beim Thema SBOM, schöpfen deren Potenzial aber noch nicht aus.

Die Supply-Chain-Sicherheit verbessert sich, aber es bleibt noch viel zu tun

Der Bericht „State of Software Supply Chain Security 2023“ zeigt insgesamt: Die Sicherheit der Software-Supply-Chain verbessert sich, aber es bleibt noch viel zu tun. Ein Zeichen dafür, dass wir auf dem richtigen Weg sind: Unsere Untersuchung ergab kürzere Behebungszeiten (TTF) über alle Schweregrade hinweg und in den meisten großen Open-Source-Ökosystemen. Tatsächlich werden Schwachstellen in Open-Source-Komponenten inzwischen schneller behoben als in proprietärer Software. Mögliche Gründe für diese positive Entwicklung sind etwa der breitere Einsatz von Sicherheitstools für Open Source wie SCA, mehr Finanzmittel und Personal für die Behebung kritischer Schwachstellen in Open-Source-Software sowie ein stärkeres Sicherheitsbewusstsein in Open-Source-Projekten. 

Andererseits stellten wir fest, dass die Angriffsfläche von Open Source weiterhin sehr groß ist. Viele Unternehmen ignorieren Schwachstellen in großen Ökosystemen wie JavaScript, Java und Debian. So ist die Log4Shell-Schwachstelle auch 18 Monate nach ihrer Bekanntgabe in zahlreichen Unternehmen noch immer nicht behoben.

Unsere Ergebnisse zeigen außerdem, dass wir uns in einer Übergangsphase befinden – weg von älteren Ansätzen, hin zu neuen Methoden und Technologien. Insgesamt sind wir auf dem richtigen Weg. Wir müssen jedoch weiter vorangehen und Innovationen vorantreiben, um das Risiko durch Open-Source-Software künftig zu reduzieren.

Lesen Sie jetzt den vollständigen Bericht oder entdecken Sie die wichtigsten Erkenntnisse auf unserer interaktiven Webseite.