Illustration Absmeier Genki Bing

DevSecOps ist eine derjenigen Abkürzungen, die man in der hektischen Welt der Softwareentwicklung durchaus unterschiedlich interpretieren kann. So kann man beispielsweise eine Definition wählen, nach der man das Thema Sicherheit als willkommene Ergänzung der Bereiche Entwicklung (Dev) und Betrieb (Ops) betrachtet. Oder Sicherheit gilt eher als der unerwünschte Eindringling, der die nahtlose Produktivität von Entwicklung und Betrieb behindert. Es wird Sie vermutlich kaum überraschen, dass letztere Sicht auf die Dinge, die noch immer vorherrschende ist.

Tatsächlich ist es, annähernd 50 Jahre nachdem der Begriff geprägt wurde, immer noch herausfordernd, Sicherheit in Entwicklung und Betrieb einzubinden. Aber es gibt Fortschritte. Das bestätigt der »Global State of DevSecOps 2023« Report, eine aktuelle Umfrage des Synopsys Cybersecurity Research Center (CyRC) und des internationalen Marktforschungsunternehmens Censuswide unter über 1.000 IT-Fachleuten. DevSecOps gilt heute als geschäftskritische Praxis und als wichtiges Anliegen innerhalb des Risikomanagements. Die Notwendigkeit, Sec mit DevOps zu verbinden, liegt an sich auf der Hand. Mit der wachsenden Menge an Software steigt zwangsläufig die Anzahl der Schwachstellen, so dass einige Experten schon von einem »Vulkan an Schwachstellen« sprechen. Selbst das ist wohl noch untertrieben. Denn es entstehen ständig neue Schwachstellen.

Zudem räumen über 80 % der Befragten ein, dass das Beheben einer kritischen Sicherheitslücke innerhalb ihrer Software den Zeitplan für die DevOps-Bereitstellung beeinträchtigt hat. Und dieses Problem besteht weltweit: Die Umfrageteilnehmer, Fachleute in verschiedenen Funktionen der Bereiche Technologie, Cybersicherheit und Anwendungs-/Softwareentwicklung, kommen aus den USA, Großbritannien, Frankreich, Finnland, Deutschland, China, Singapur und Japan.

Dennoch hält das Ringen um DevSecOps weiter an. Auch das ist, angesichts der inhärent widersprüchlichen Prioritäten keine Überraschung. Das Ziel eines Sicherheitsteams ist klar: Softwarecode so sicher und widerstandsfähig wie möglich zu machen, bevor er der unberechenbaren und gefährlichen digitalen Welt ausgesetzt wird. Entwickler hingegen sind einem immensen Druck ausgesetzt, immer schneller zu produzieren. Das Mantra lautete deshalb seit Jahren: »Wir hätten gerne Sicherheit für unsere Wertströme – solange sie uns nicht ausbremst.« Oder, vielleicht noch direkter: »Wenn ihr schon hier seid, dann kommt uns wenigstens nicht in die Quere.«

Trotzdem. In einer Welt, in der mittlerweile praktisch alles softwaregesteuert abläuft, muss Sicherheit einen mindestens ebenso hohen Stellenwert haben wie Geschwindigkeit. Werden Softwareprodukte ohne die nötigen strengen Sicherheitsvorkehrungen bereitgestellt, führt dies unweigerlich zu risikobehafteter Software. Dabei sind Softwarerisiken immer beides: unternehmerische wie persönliche Risiken. Schlagzeilen über Cyberkriminelle, die Softwareschwachstellen für alle möglichen Zwecke ausnutzen, sind an der Tagesordnung. Das reicht vom Identitätsdiebstahl über das Abräumen von Bankkonten bis hin zur Störung kritischer Infrastrukturen und vielem mehr.

Sicherheitsmaßnahmen sind aber heutzutage mit derselben Geschwindigkeit umsetzbar wie Entwicklungsschritte. Es gibt also keinen triftigen Grund, nicht sofort zu handeln. Vor diesem Hintergrund ist es ermutigend, dass DevSecOps für die meisten Unternehmen, die mit Softwareentwicklung zu tun haben, mittlerweile eines ihrer wesentlichen Ziele ist.

Zu den wichtigsten Ergebnissen der Umfrage zählt, dass die große Mehrheit der Befragten (91 %) DevSecOps in irgendeiner Form bereits integriert hat. Aber all das gilt unter Vorbehalt. Denn für einen nicht unbeträchtlichen Prozentsatz der Firmen ist es nach wie vor schwierig, einen Reifegrad zu erreichen, bei dem Sicherheitsprozesse und -standards in den gesamten Lebenszyklus der Softwareentwicklung (SDLC) eingebettet sind: Fast ein Drittel der Befragten stuft den Reifegrad ihres DevSecOps-Programms auf einer 5er-Skala auf der Stufe 1 oder 2 ein.

Ein Grund mag sein, dass viele Anwender mit den Tools für Softwaresicherheit (Application Security Testing, AST) unzufrieden sind. Aber genau diese Tools fungieren als Kernelement bei der Integration von Sicherheit in eine Software.

Eine große Mehrheit der Befragten schätzt AST-Tools zwar als durchaus hilfreich ein. Es gibt aber auch eine Reihe von Gründen zur Frustration. Da werden hohe Kosten im Vergleich zum ROI ins Feld geführt, es fehlen Prioritäten was Abhilfemaßnahmen in Bezug auf die geschäftlichen Anforderungen anbelangt, die Tools seien wahlweise zu langsam, um sie in schnelle Release-Zyklen/kontinuierliche Bereitstellung einzubinden oder zu ungenau bzw. unzuverlässig. Zudem sei es oftmals nicht möglich, die Ergebnisse mit der Lösung von Problemen in Zusammenhang bringen.

Viele Tools können demnach die Vorgabe, die Entwicklung »nicht auszubremsen«, kaum erfüllen. Glücklicherweise ist das für die meisten Unternehmen kein Grund, sich von DevSecOps zu verabschieden. Vielmehr suchen sie nach Möglichkeiten, die Stolpersteine aus dem Weg zu räumen.

Das belegen auch weitere Umfrageergebnisse:

• Für ausgereifte Sicherheit braucht es Menschen. 29 % der Befragten geben an, dass die Zusammenarbeit von Entwicklung, Sicherheit und Betrieb ein gewichtiger Faktor für den Erfolg eines Sicherheitsprogramms ist.
• Automatisierung hilft. Mehr als 70 % bewerten das automatische Scannen von Code auf Schwachstellen oder Defekte als hilfreiche Sicherheitsmaßnahme, wobei 34 % das automatische AST sogar als »sehr hilfreich« einschätzen. Über ein Drittel sagt, dass die Integration von automatisierten Sicherheitstests in die Build/Deploy-Workflows für den Erfolg eines Sicherheitsprogramms »sehr wichtig« ist.
• Weitere wichtige Einflussfaktoren. Weitere wichtige Erfolgsfaktoren sind die Durchsetzung von Sicherheits- und Compliance-Richtlinien als Infrastructure-as-Code, das Einbeziehen von Sicherheitsbeauftragten in die Entwicklungs- und Betriebsteams sowie eine grundsätzlich bessere Kommunikation zwischen den Entwicklungs-, Betriebs- und Sicherheitsteams.
• Barrieren. Fast ein Drittel der Befragten gab an, dass der Erfolg von DevSecOps vor allem durch unzureichende Sicherheitsschulungen, einen Mangel an geeignetem Sicherheitspersonal, fehlende Transparenz bei der Entwicklung und hinsichtlich betrieblicher Tätigkeitsbereiche sowie durch sich ständig ändernde Prioritäten behindert wird.
• Mangelnde Sicherheit kann sich negativ auf den Gewinn auswirken. Wie bereits erwähnt, räumen mehr als 80 % der Befragten ein, dass sich Sicherheitsmängel in der eingesetzten Software in irgendeiner Form auf ihre Lieferpläne für 2022-23 ausgewirkt haben. Fast die Hälfte der Befragten gibt zusätzlich an, dass ihr Unternehmen drei Wochen oder länger braucht, um kritische Sicherheitsrisiken/Schwachstellen in den installierten Anwendungen zu beheben. Das ist besonders beunruhigend, weil Schwachstellen inzwischen schneller als je zuvor ausgenutzt werden. Neueste Studien zeigen, dass weit über die Hälfte der gemeldeten Schwachstellen innerhalb einer Woche nach ihrer Veröffentlichung ausgenutzt werden.
• KI ja, aber mit Bedacht. Laut der Umfrage nutzen 52 % der Sicherheitsexperten für ihre DevSecOps-Verfahren bereits KI, maschinelles Lernen, natürliche Sprachverarbeitung und neuronale Netzwerke. Aber mehr als 75 % sind wegen der eventuellen Risiken besorgt. Der zunehmende Einsatz generativer KI-Tools, z. B. KI-gestützte Codierungsvorschläge, wirft Fragen auf – und führte in einigen Fällen sogar zu Rechtsstreitigkeiten – was geistiges Eigentum, Urheberrechte und die Lizenzierung von KI-generiertem Code anbelangt.

Wie lautet also die übergeordnete Botschaft? DevSecOps kann erfolgreich sein – mit den richtigen Mitarbeitern und den passenden, korrekt konfigurierten Tools.

Auch wenn DevSecOps nicht manuell umsetzbar ist, so braucht es dennoch auch weiterhin menschliche Unterstützung. In dem Bericht heißt es: »So wichtig wie automatisierte Tests für die Konsistenz, die Skalierbarkeit und die Zeit- und Kostenersparnis sind, so wichtig ist der menschliche Faktor. Denn er bietet zusätzlichen Einblick und eine Form der Anpassungsfähigkeit, die für die Identifizierung komplexer und subtiler Sicherheitsprobleme unerlässlich sind.«

Was die Tools betrifft, so umfasst das Standard-Toolkit für das Testen während des SDLC statische, dynamische und interaktive AST-Tools, sowie die Software Composition Analysis. Sie alle helfen Entwicklern, bekannte Schwachstellen und mögliche Lizenzkonflikte in Open-Source-Softwarekomponenten zu finden und zu beheben.

Diese Tools müssen jedoch stets so konfiguriert werden, dass sie die geschäftlichen Prioritäten eines Unternehmens berücksichtigen.

Einer der ermutigenden Befunde der Umfrage: Unternehmen setzen immer häufiger Application Security Orchestration and Correlation (ASOC) ein, heute meistens als Application Security Posture Management (ASPM) bezeichnet. ASPM erlaubt unter anderem die »Orchestrierung« von Tests, damit der richtige Test zur richtigen Zeit während des SDLC zum Einsatz kommt. Zudem gestattet ASPM es, nachzuvollziehen, ob Schwachstellen tatsächlich gemäß der Prioritäten des betreffenden Unternehmens behoben wurden. Das verhindert unter anderem, dass Entwickler nicht mit Erkenntnissen überschüttet werden. Ein »Rauschen«, das dann gerne ausgeblendet wird.

Und es trägt dazu bei, Schwachstellen in bereitgestellten Anwendungen schneller als bislang zu beheben. Laut der Analysten von Gartner sollte jedes Unternehmen, das verschiedene Entwicklungs- und Sicherheitstools einsetzt, ASPM nutzen, um die richtigen Prioritäten setzen zu können.

Fazit

Eine effektive Umsetzung von DevSecOps ist möglich. Wie in vielen anderen Szenarien auch, ist Sicherheit aber eine Reise und kein einmaliges Ereignis. Aber es lohnt sich, sich auf den Weg zu machen, denn selbst auf Stufe 1 sind sie deutlich besser abgesichert als auf Stufe 0.

Gunnar Braun, Technical Account Manager for Application Security Solutions bei Synopsys