Global State of DevSecOps 2024 : DevSecOps: KI verschärft Sicherheitsprobleme
Der 2024 Global State of DevSecOps Bericht belegt, dass KI-gestützte Entwicklung die Dynamik zwischen Sicherheit und Entwicklung massiv verändert hat. Mit bis zu 20 Tools kämpfen Unternehmen gegen wachsende Komplexität und riskante Lücken in ihren Sicherheitsmaßnahmen.
Jedes Jahr bringt uns neue Errungenschaften in den Bereichen Softwareentwicklung und Anwendungssicherheit. Innovationen, die branchenübergreifend wirken und ortsunabhängig sind. Viele dieser Neuerungen werden freudig begrüßt, andere werden lieber unter Verschluss gehalten. Wer mit Anwendungssicherheit und DevSecOps betraut ist, macht diese Entscheidung oft davon abhängig, wie gut sich neue Technologien und Prozesse in bestehende Arbeitsabläufe einfügen. Der „2024 Global State of DevSecOps„-Bericht von Black Duck untersucht die Sichtweisen von Securityteams, Entwicklern, DevOps-Fachleuten und Führungskräften in den Bereichen DevSecOps-Effizienz, Qualität von Sicherheitstests und KI-gestützte Entwicklung. Die Konsolidierung von AppSec-Tools schreitet demnach zwar voran, dennoch verwenden stolze 48 % der in diesem Jahr befragten Unternehmen weiterhin zwischen elf und zwanzig verschiedene Tools für ihre Sicherheitstests.
Die Tatsache, dass fast die Hälfte der Unternehmen bis zu 20 verschiedene Sicherheitstools einsetzt, kann als Zeichen dafür gewertet werden, dass Sicherheit ernst genommen wird. Die Zahl weist aber auch auf ein mögliches Problem hin. Alle Bemühungen um ein „Mehr“ an Sicherheit führen schnell auch zu einem „Mehr“ an Schwierigkeiten, die unterschiedlichen Tools adäquat zu verwalten. Dies betrifft zum einen die schiere Anzahl, zum anderen mögliche Inkonsistenzen zwischen den jeweiligen Ergebnissen. Dies macht Tests ineffizient und erschwert die Problembehebung – oder macht sie gänzlich unmöglich. Duplikate und False Positives erhöhen das typische „Rauschen“ und bremsen die Teams aus.
Herausforderungen durch uneinheitliche Sicherheitsstrategien
Der DevSecOps-Bericht bestätigt das uneinheitliche Bild. Beim Hinzufügen einer Anwendung in die Testwarteschlange wird Automatisierung immer beliebter: 38 % der Befragten geben an, dass alle Projekte automatisch abgearbeitet werden. Demgegenüber steht allerdings ein alarmierend hoher Anteil von Unternehmen (29 %), die einräumen, sämtliche Projekte manuell hinzuzufügen. 29 % mag noch nach einer verhältnismäßig niedrigen Zahl klingen. Aber das manuelle Abarbeiten macht den gesamten Prozess anfällig für Verzögerungen. Nicht selten verzichten Unternehmen sogar gänzlich auf kritische Tests. Das führt dazu, dass Schwachstellen in die Produktionsumgebung gelangen oder beim Kunden landen. Man stelle sich automatisierte Entwicklungspipelines vor, die Software mit neuen Funktionen und Codeänderungen mehrmals pro Tag erstellen. Wenn man diese Geschwindigkeit mit dem eines manuellen Test-Procederes vergleicht, wird schnell deutlich, dass Transparenz in Echtzeit so kaum aufrechtzuerhalten ist. Das führt fast zwangsläufig zu verzögerten Produkt-Releases oder schlimmer noch zu hochproblematischen Security-Problemen oder technischen Schulden. Zudem wird sich die Entwicklungsgeschwindigkeit durch den Einsatz von KI-Tools weiter erhöhen.
In zurückliegenden Jahren hätte sich diese Tatsache lediglich auf die Effizienz der Arbeitsabläufe bei der Umstellung auf DevSecOps ausgewirkt. Im Jahr 2024 haben jedoch durch künstliche Intelligenz (KI) generierter Code und KI-gestützte Entwicklung die Kluft zwischen Sicherheits- und Entwicklungsteams vergrößert. Jetzt fließen die Softwareentwicklungspipelines schneller als die Testpipelines der Sicherheitsabteilung. Über 90 % der Befragten nutzen bereits KI-Tools in irgendeiner Form für die Softwareentwicklung. Aber auch KI-Tools generieren unsicheren Code oder verweisen auf anfällige Bibliotheken von Drittanbietern. Dadurch vergrößert sich die Angriffsfläche. Eine Tatsache, die nicht unmittelbar zu erkennen ist, weil Entwickler keinen Einblick in die Struktur und das Grundprinzip des von der KI-generierten Codes haben.
Eine optimistische Interpretation der Studienergebnisse wäre, dass 43 % der Befragten nur bestimmten Entwicklern oder Teams gestatten, KI-Tools zum Schreiben von Code zu verwenden. Das mag auf eine methodische und schrittweise Einführung verweisen, bei der AppSec-Teams ihre Sicherheitsschleusen entsprechend präparieren. Die diesjährigen Daten deuten allerdings eher auf eine Haltung hin, die mit „Besser um Vergebung bitten als um Erlaubnis betteln“ recht gut beschrieben ist: 21 % der Befragten bestätigen nämlich, dass Entwickler KI-Tools trotz eines betrieblichen Embargos verwenden.
Betrachtet man KI-gestützte Entwicklung unter dem Sicherheitsaspekt, bestätigen 85 % der Befragten, dass sie „einige Maßnahmen“ ergriffen haben, um den Herausforderungen zu begegnen, die mit KI-generiertem Code verbunden sind. Obwohl dies ermutigend ist, war dennoch weniger als ein Viertel (24 %) der Befragten „sehr zuversichtlich“, was bestehende Richtlinien und Verfahren zum Testen von KI-Code angeht. Ferner zeigen sich 20 % der Unternehmen nur „wenig“ und 6 % „überhaupt nicht zuversichtlich“, angemessen darauf vorbereitet zu sein, KI-generierten Code sicher zu verwalten.
Die besorgniserregendste Erkenntnis stammt von denjenigen, die allen Entwicklern die Verwendung von KI-Tools erlauben, aber gleichzeitig nur „geringes“ (18 %) oder „gar kein Vertrauen „(4 %) in ihre Fähigkeit haben, KI-generierten Code sicher zu verwalten. Diese Gruppe macht insgesamt 6 % aller Befragten aus und räumt offenbar der Entwicklungsgeschwindigkeit Vorrang gegenüber der Anwendungssicherheit ein. Einen detaillierten Vergleich der Daten zu „Erlaubnis/Nutzung von KI-gestützten Entwicklungstools“ versus „Vertrauen in die eigenen Sicherheitsmaßnahmen“ liefert der vollständige Report.
Wenn Unternehmen ihre DevSecOps-Programme mit Blick auf die KI-gestützte Entwicklung gestalten, sollte man sowohl auf die Testabdeckung als auch auf die Umsetzbarkeit der Ergebnisse achten. Schließlich bedeuten enge Entwicklungszeitpläne und häufigere Code-Pushs, dass man identifizierte Probleme schneller beheben muss, ohne dass die Effizienz leidet.
Welche Risiken birgt KI-generierter Code für Unternehmen?
Eine schnellere Entwicklung ist nicht gleichbedeutend mit einer sicheren Entwicklung. Beide gehen Hand in Hand. Wenn die Masse des entwickelten Codes größer ist als die Fähigkeit, ihn angemessen zu testen, steigt das Risiko. Das ist nicht nur eine Frage von anfälligem Code. Es ist nicht zuletzt eine Frage der für die Softwareentwicklung geltenden Vorschriften für eine Sicherheitsüberprüfung. Etliche Vorgaben ergeben sich aus Standards, wie beispielsweise dem Cyber Resilience Act (CRA) in der EU. Zudem sind Unternehmen sich oft nicht bewusst, dass KI in Bezug auf die Verwendung des Codes von Dritten deren Lizenzen betrifft und entsprechende Lizenzverpflichtungen mit sich bringt. KI kann Sicherheitsrisiken in den Code einbringen, indem sie entweder anfälligen Code schreibt oder auf Bibliotheken von Drittanbietern verweist, die ihrerseits anfällig sind. Dieser vorgeschlagene Code oder die Bibliotheken Dritter sind außerdem an Lizenzverpflichtungen gekoppelt. Sie zu missachten, kann ein Unternehmen in der Folge sogar eigenes geistiges Eigentum kosten.
Die diesjährigen Befragungen haben noch einen weiteren kritischen Befund zutage gefördert. So hat sich herausgestellt, dass die häufig verwendete Metrik, um die Effizienz der Tests zu ermitteln, möglicherweise nur oberflächlich ist und durch einen verringerten Testaufwand künstlich gestärkt wird. 5 % der Befragten geben an, nur bis zu 20 % ihrer Projekte und Repositories in die Testwarteschlange aufzunehmen. Ebenso nehmen 65 % der Befragten bis zu 60 % dieser Artefakte in ihre Testwarteschlange auf. Lediglich 9 % der Befragten erreichen nach eigenen Angaben eine Abdeckung von bis zu 100 %.
Automatisierung als Schlüssel zur Sicherheitsoptimierung
KI wird die Entwicklung zwangsläufig weiter beschleunigen. AppSec-Teams haben also ausreichend Raum für Verbesserungen. Etwa indem sie den Fokus auf die Automatisierung von Testaktivitäten legen – und das für jede Pipeline, jedes Repository und jedes Projekt.
Trotz der wachsenden Tendenz, bei Sicherheitstests eine geringere Abdeckung in Kauf zu nehmen, bewerten immerhin 20 % der Befragten die Testergebnisse als leicht verständlich und umsetzbar. Diese Unternehmen sollten dann auch in der Lage sein, KI-generierten Code mit der Geschwindigkeit abzusichern, die der Entwicklung entspricht. Tatsächlich sagen sogar 72 % der Befragten, dass es zumindest „einigermaßen einfach“ sei, die Testergebnisse zu verstehen und darauf zu reagieren.
Maßnahmen, so simpel sie auch sein mögen, können nur wirken, wenn sie auf den richtigen Daten beruhen. Das berüchtigte „Datenrauschen“ produziert fast naturgemäß unrichtige Informationen, Duplikate und Konflikte zwischen bis zu Tausenden von Sicherheitsrisiken, die AppSec-Tests anzeigen.
Gegenwärtig stufen 78 % der Befragten mehr als 20 % der Ergebnisse als Rauschen ein. Dieses Rauschen vermindert die Effizienz, erschwert die Triage und behindert Maßnahmen zur Abhilfe. Die Pessimisten unter den Befragten (3 %) behaupten sogar, dass bis zu 100 % der Ergebnisse Rauschen sind. Immerhin 75 % der Befragten stufen bis zu 60 % der Testergebnisse als Rauschen ein. Diese Unternehmen würden also von einer besseren Korrelation der Ergebnisse, granularen AppSec-Richtlinien und einer automatisierten Problemverifizierung profitieren.
Effizienz, Geschwindigkeit und die Gefahr von Sicherheitslücken
Alles in allem zeigt der Global State of DevSecOps Report 2024 von Black Duck, dass die meisten Unternehmen den Grundstein für DevSecOps gelegt haben. Jetzt sind Initiativen gefragt, um die Abdeckung auszuweiten und das Ablenkungsrisiko für alle Beteiligten zu verringern. KI-generierter Code überschwemmt bereits die Pipelines. Automatisierung und geschlossene Feedbackschleifen zwischen Sicherheits- und Entwicklungsteams sind daher der Schlüssel, um schnell und sicher qualitativ hochwertige Software zu produzieren – und mit der Geschwindigkeit der KI Schritt zu halten.
Boris Cipot ist Senior Sales Engineer bei Black Duck.