7 überraschende Hindernisse auf dem Weg zur DevSecOps-Reife

Im Rahmen der kürzlich erfolgten Entwicklung und Einführung des DevSecOps Maturity Framework hat Snyk umfassende Branchenforschung zum aktuellen Stand der Developer Security in softwareorientierten Unternehmen durchgeführt. Mehr als 300 Organisationen stellten Daten bereit, damit wir nachvollziehen können, wie sie ihre eigene Reife in den Bereichen DevOps, Anwendungssicherheit, Schwachstellenmanagement, Priorisierung, Akzeptanz durch Entwickler und Programm-Governance einschätzen.

Insgesamt zeigen unsere Ergebnisse, dass die meisten Unternehmen den Wert ausgereifter DevSecOps-Praktiken verstehen und aktiv daran arbeiten, eine moderne Sicherheitskultur und ein AppSec-Programm aufzubauen, die auf kontinuierliche Verbesserung ausgerichtet sind. Doch nicht alle gehen dabei gleich vor. Tatsächlich haben wir im übergeordneten Bestreben nach mehr Reife erhebliche Unterschiede darin festgestellt, wie Organisationen zentrale Aspekte ihrer Sicherheitspraktiken beschreiben. Das deutet auf beträchtliche Lücken hin, die auf dem Weg zum gemeinsamen Ziel der DevSecOps-Reife noch bestehen. Sehen wir uns einige dieser Ergebnisse an, die mögliche Verbesserungsbereiche aufzeigen.

Risikoreduzierung und Security Fatigue gehören zu den KPIs, die Sicherheitsteams am seltensten messen. Gleichzeitig zählen sie zu den fünf wichtigsten Indikatoren, die Teams messen möchten.

Von allen Sicherheitskennzahlen, die die von uns untersuchten Teams erfassen, werden „Risikoreduzierung durch Maßnahmen von Entwicklern“ und „Reduzierung der Security Fatigue (Zeitaufwand für manuelle Triage, fehlerhafte Builds und Nacharbeiten an der Sicherheit)“ am seltensten gemessen. Als wir dieselben Befragten fragten, über welche Kennzahlen sie gerne berichten würden, wenn alle relevanten Daten verfügbar wären, standen diese beiden KPIs jedoch ganz oben auf der Liste. 

Offensichtlich besteht weiterhin eine erhebliche Diskrepanz zwischen den Daten, die Sicherheitstools problemlos liefern können – etwa der Anzahl gefundener und behobener Schwachstellen, CVSS-Werten und der Zeit bis zur Behebung – und den Fragen, die Sicherheitsexperten stellen möchten, zum Beispiel: „Wie stark wird das Risiko durch eine bestimmte Maßnahme reduziert?“ Diese Fragen entscheiden über die Wirksamkeit und den ROI ihres Programms. Das unterstreicht, wie wichtig es ist, Schwachstellendaten aus mehreren Quellen zusammenzuführen und miteinander zu verknüpfen. So lassen sich Silos aufbrechen und Risiken ganzheitlich bewerten – auf Grundlage eines umfassenden Verständnisses von Anwendung, Geschäft und Schwachstellenkontext. Application Security Posture Management (ASPM)-Tools wie Snyk AppRisk können dabei als interne Drehscheibe und zentrale Quelle verlässlicher, risikobasierter Sicherheitserkenntnisse dienen. 

Von allen in die Studie einbezogenen Personengruppen zeigten Softwareentwickler am stärksten Interesse daran, Security Fatigue – auch als Toil bezeichnet – zu messen. Diese weit gefasste Kategorie soll die Kosten des Shift-left-Ansatzes beziffern, und zwar in Form verlorener Entwicklerproduktivität, die für Sicherheitsaufgaben aufgewendet werden muss, die sich nicht einfach automatisieren lassen. Da die meisten Tools zum Scannen von Schwachstellen für Sicherheitsteams konzipiert sind, übersehen sie häufig die Auswirkungen auf Entwickler. Dadurch lässt sich kaum nachvollziehen, wie viel Ineffizienz in den Erkennungs- und Behebungsprozessen des SDLC steckt. Diese fehlende Möglichkeit, den Aufwand für Sicherheitsaufgaben zu messen, trägt zum hohen Maß an Spannungen zwischen Entwicklungs- und Sicherheitsteams bei – selbst in Organisationen, die bereits eine hohe DevSecOps-Reife erreicht haben.

Die genaue Messung der Sicherheitslage anhand des Risikos ist das DevSecOps-Ziel Nr. 1 für Sicherheits- und Engineering-Teams.

In der Anwendungssicherheit hält sich hartnäckig der Mythos, Entwickler würden sich nicht für Software-Risiken interessieren. Die Realität zeigt sich erneut daran, dass das wichtigste DevSecOps-Ziel der Entwickler darin bestand, die risikobasierte Sicherheitslage genau zu verstehen – genau wie bei ihren Kollegen in AppSec (Platform-Engineering-Gruppen nannten es als ihr zweitwichtigstes Ziel). Anders gesagt: Entwickler möchten ihren Beitrag zur Risikoreduzierung für die Organisation leisten, sind aber der Meinung, dass ihnen die nötigen Daten für bessere Priorisierungsentscheidungen fehlen.

Diese Diskrepanz wurzelt in der Komplexität der Berechnung von Anwendungsrisiken. Dafür ist zusätzlicher Kontext nötig – etwa zu Geschäftsauswirkungen, Erreichbarkeit, Reifegrad von Exploits und vorhandenen kompensierenden Kontrollen – und nicht bloß eine einfache Zählung von Problemen und deren Schweregrad. Moderne Software ist sehr komplex, und die Budgets für die Behebung sind stets begrenzt. Deshalb muss die Behebungszeit nicht einfach nach den Schwachstellen mit dem höchsten Schweregrad verteilt werden. Diese sind möglicherweise gar nicht ausnutzbar; und selbst wenn doch, kann ein erfolgreicher Exploit erhebliche geschäftliche Auswirkungen haben – oder auch nicht. Stattdessen ist ein maßgeschneidertes, risikobasiertes Bewertungssystem erforderlich, das verschiedene Kontextquellen aus dem gesamten SDLC berücksichtigt.

Wenn sich keine Einigkeit über ein risikobasiertes Priorisierungsschema erzielen lässt, führt dies häufig zu Spannungen zwischen Engineering- und Sicherheitsteams und kann DevSecOps-Initiativen aufgrund des anhaltenden Vertrauensmangels zum Scheitern bringen. Entwickler haben oft das Gefühl, ihre Zeit für die Behebung der „falschen“, also tatsächlich weniger riskanten Probleme einsetzen zu müssen. Sicherheitsexperten befürchten häufig, dass zu viele echte Risiken in Produktionsumgebungen gelangen, weil es keinen gemeinsamen, vertrauenswürdigen Mechanismus zur Risikobewertung gibt, der in die Arbeitsabläufe beider Gruppen eingebunden ist. Es ist daher nicht verwunderlich, dass eine genaue Risikomessung für beide Seiten oberste Priorität hat. Die meisten Sicherheitstools entwickeln sich jedoch erst weiter, um diesen Bedarf zu decken.

Nur 50 % der Organisationen geben an, in Just-in-Time-Sicherheitsschulungen für Entwickler und Security-Champions-Programme in Entwicklungsteams zu investieren.

Sicherheitsschulungen sind ein entscheidender Bestandteil ausgereifter DevSecOps-Praktiken – insbesondere für Softwareentwickler. Damit sie wirksam sind, müssen sie relevant, praxisnah und fortlaufend sein und sich nahtlos in die Prozesse und Arbeitsweisen der Teams einfügen. Die meisten herkömmlichen Sicherheitsschulungen erfüllen diese Anforderungen jedoch nicht. So entsteht immer wieder eine Lücke im Verständnis der Entwickler für Risiken der Anwendungssicherheit und die zugehörigen Praktiken für sicheres Programmieren.

Diese Lücke hängt mit der bevorzugten Lernweise von Engineering-Fachkräften zusammen, die auf der Lösung realer Probleme beruht. Die große Komplexität moderner Softwareentwicklung macht es schwierig, alles, was ein Engineer wissen muss, mit herkömmlichen, von oben nach unten vermittelten Methoden zu lehren. Stattdessen lernen Entwickler durch praktische Erfahrung: Sie stoßen auf ein Problem und müssen eine Lösung finden, bevor sie weitermachen können. Diese Art des Just-in-Time-Lernens bleibt nachweislich besser im Gedächtnis. Die meisten Sicherheitsschulungsprogramme verfolgen jedoch den gegenteiligen, weniger wirksamen Ansatz. Investitionen in Just-in-Time-Sicherheitsschulungen, bei denen Entwickler eine kurze Lerneinheit absolvieren können, um die Risiken einer bestimmten Schwachstelle zu verstehen und zu lernen, wie sie sich beheben lässt – etwa ein Problem im eigenen Code –, verbessern nachweislich die Sicherheitsergebnisse. Snyk Learn ist ein Beispiel dafür. Dennoch nutzen nur etwa die Hälfte der von uns untersuchten Organisationen diesen Ansatz.

Auch die Wirksamkeit von Security-Champions-Programmen ist in Studien immer wieder belegt worden. Sie bringen Sicherheitswissen direkt in Software-Engineering-Teams ein, indem ein Entwickler pro Team mit gezielten, vertieften Schulungen und Ressourcen ausgestattet wird und als Verbindungsperson zwischen den Entwicklerkollegen und der AppSec-Organisation fungiert. Da Engineers am liebsten von anderen Engineers lernen und Kollegen Sicherheitsanforderungen besser in die Arbeitsweisen ihres Teams übertragen können, tragen Security Champions nachweislich dazu bei, Spannungen mit AppSec abzubauen und bessere Ergebnisse zu erzielen. Die Hälfte der Organisationen, die noch kein Champions-Programm eingeführt hat, könnte bei ihren Initiativen zur Entwicklersicherheit weiterhin auf Hindernisse stoßen, wenn dieser entscheidende Baustein der Unternehmenskultur fehlt.

Weniger als die Hälfte (46 %) der Organisationen gibt an, ihre geschäftskritischen Anwendungen genau identifizieren zu können.

Das Risiko wird häufig grob als Wahrscheinlichkeit multipliziert mit den Auswirkungen berechnet. Tools zum Scannen von Schwachstellen können die Wahrscheinlichkeit eines Exploits mehr oder weniger genau ermitteln – insbesondere, wenn sie zusätzlichen Kontext wie Erreichbarkeit und Reifegrad des Exploits einbeziehen. Die Auswirkungen hingegen lassen sich per Definition nur vom Unternehmen bewerten. Ein Sicherheitsscanner kann nicht zwischen einem Problem mit hohem Schweregrad in einer geschäftskritischen Anwendung und derselben Schwachstelle in einem ungenutzten Dienst unterscheiden, der eine veraltete Werbewebsite unterstützt. Die mit diesen beiden Problemen verbundenen Risiken könnten jedoch kaum unterschiedlicher sein.

Für ausgereifte DevSecOps-Praktiken müssen Organisationen die geschäftlichen Auswirkungen ihrer Software-Assets verstehen und diese Bewertungen in die Risikobewertung zur Priorisierung von Problemen einbeziehen. Configuration-Management-Datenbanken (CMDBs) dienen häufig dazu, ein aktuelles Inventar von Code-Repositories, Container-Images, Deployments und anderen Artefakten zu verwalten. Sie können auch als verlässliche Quelle für die Bewertung der Geschäftskritikalität dienen. Diese Daten lassen sich anschließend von Sicherheitsorchestrierungsplattformen, insbesondere ASPM-Lösungen wie Snyk AppRisk, für die Integration in risikobasierte Priorisierungsalgorithmen nutzen.

Die Mehrheit der befragten Organisationen, denen die Identifizierung ihrer geschäftskritischen Software Schwierigkeiten bereitet, steht vor einem doppelten Problem: Bei diesen besonders wertvollen Anwendungen lassen sie möglicherweise zu viele Risiken in die Produktion gelangen, was im Falle eines Exploits erhebliche geschäftliche Auswirkungen hätte. Gleichzeitig leiden sie insgesamt unter ineffizienten Behebungsprozessen, da sie Korrekturen für Anwendungen mit sehr niedrigen Auswirkungswerten nicht ohne Weiteres niedriger priorisieren können. Für ausgereifte DevSecOps-Praktiken sind Tools und Prozesse erforderlich, die geschäftliche Auswirkungen bei jeder Risikoberechnung von Anfang an berücksichtigen.

Nur 31 % der Organisationen setzen Sicherheitsanforderungen vor der Produktion in mehreren Phasen des SDLC automatisch durch.

Unsere Forschung hat ergeben, dass die meisten Organisationen vollständig dokumentierte Software-Risikoprofile haben, deren Anforderungen automatisch durchgesetzt werden können. Bei der größten Gruppe (40 %) erfolgt diese Durchsetzung jedoch ausschließlich in der Produktions- bzw. Laufzeitumgebung. Deutlich weniger Organisationen ergreifen die Initiative, Richtlinien an mehreren Punkten des SDLC in Vorproduktionsumgebungen durchzusetzen. Das bedeutet vor allem, dass selbst in Organisationen mit einer ausgereiften DevSecOps-Kultur die meisten Vorteile einer schnellen und frühzeitigen Behebung von Sicherheitsproblemen ungenutzt bleiben.

Es gilt seit Langem als Grundsatz der Sicherheit, dass die Kosten für die Behebung von Problemen steigen, je weiter Software im Entwicklungsprozess voranschreitet. Werden nur einige Sicherheitsrichtlinien in der Vorproduktion umgesetzt, etwa in CI/CD-Pipelines, PR-Prüfungen oder Staging-Umgebungen, fallen für die meisten Probleme die höchstmöglichen Behebungskosten an.

Zwischen Behebungskosten und Erkennungsgenauigkeit besteht ein Zielkonflikt. Werden Probleme früher im SDLC erkannt, lassen sie sich schneller und effizienter beheben, weil die Rückkopplung in die Arbeitsabläufe der Entwickler kürzer ist. Je näher Software jedoch an die Produktion rückt – wenn sie kompiliert, paketiert und für Tests in immer produktionsähnlicheren Umgebungen bereitgestellt wird –, desto besser lässt sich das Risiko einschätzen und desto genauer werden Sicherheitsscans. Den einen „richtigen“ Zeitpunkt für Sicherheitstests in einem DevSecOps-orientierten SDLC gibt es nicht. Das beste Gleichgewicht zwischen Genauigkeit und Effizienz wird vielmehr durch mehrere schlanke Sicherheitsprüfungen erreicht, die in jeder Phase Richtlinien auf Grundlage der an der Software vorgenommenen Änderungen anwenden. Organisationen, die Sicherheitsanforderungen nur in einer einzigen Phase durchsetzen, müssen entweder bei der Genauigkeit oder bei der Effizienz der Fehlerbehebung Abstriche machen. Das bremst letztlich ihren Weg zur DevSecOps-Reife. 

Nur 25 % geben an, dass Sicherheitswarnungen ausschließlich an die relevanten Beteiligten gesendet werden und alle nötigen Informationen für konkrete Maßnahmen enthalten.

Alert-Müdigkeit ist eine der Hauptursachen für Reibungsverluste bei der Sicherheit. Zu viele Warnmeldungen oder Benachrichtigungen – insbesondere solche, die irrelevant wirken oder zusätzlichen Aufwand erfordern, um sie einzuordnen – werden leicht ignoriert. Mit der Zeit kann dadurch das Vertrauen in ein überladenes Sicherheitstool schwinden, selbst wenn spätere Warnmeldungen gezielter sind. Deshalb ist es entscheidend, Alert-Müdigkeit zu vermeiden, um DevSecOps weiterzuentwickeln.

Drei Viertel der Unternehmen erhalten Benachrichtigungen, auf die sich keine geeigneten Maßnahmen ergreifen lassen. Oft fehlt der nötige Kontext, sie gehen nicht an die richtigen Personen oder enthalten keine klaren und verlässlichen Schritte zur Behebung des Problems. Dieses Chaos bei Warnmeldungen kann eine Folge mehrerer isolierter Sicherheitstools sein, die um die Aufmerksamkeit derselben Stakeholder konkurrieren. Dadurch bleibt weniger Kapazität für Benachrichtigungen, die tatsächlich konkrete Maßnahmen erfordern.

Response and Remediation ist eine der sechs Säulen des DevSecOps-Maturity-Frameworks von Snyk. Eine wiederholbare Reaktionsstrategie setzt jedoch zunächst einen Warnmeldungsstrom voraus, der bei den zuständigen Personen zuverlässig und schnell entschlossenes Handeln auslöst. Unternehmen, die das Problem der Alert-Müdigkeit nicht lösen, stoßen schnell an Grenzen bei der Umsetzung vertrauenswürdiger Remediation-Schleifen, die sich im Lauf der Zeit verbessern.

Nur 37 % beschreiben ihr DevSecOps-Programm als „transparent und aus Entwicklerperspektive Self-Service-fähig, sodass es einfach ist, sicher zu arbeiten und Software-Risiken zu vermeiden.“ 

Eine der größten Diskrepanzen auf dem Weg zur DevSecOps-Reife besteht darin, die Erfahrung von Entwicklerinnen und Entwicklern zu verstehen. Ursprünglich sollte DevOps (noch ohne „Sec“) den Entwickleralltag erleichtern, indem es ihnen Tools für Aufgaben an die Hand gab, bei denen sie zuvor auf zentrale IT-Teams angewiesen waren. Software paketieren, Anwendungen bereitstellen oder Infrastruktur einrichten – all das konnten Entwicklerinnen und Entwickler nun selbst erledigen, indem sie einfach Code schrieben. Dieser Wandel hin zu Self-Service durch automatisierte, wiederholbare Prozesse wurde zu einem Grundpfeiler der modernen Softwareentwicklung und verkürzte die Time-to-Market erheblich.

Im Bereich Sicherheit hat diese Entwicklung jedoch nicht ganz Schritt gehalten. Die Idee von „DevSecOps“ gibt es seit mehr als einem Jahrzehnt, doch sie stützt sich häufig auf veraltete AppSec-Tools und -Prozesse, die nicht zu den modernen Arbeitsweisen von Softwareentwicklerinnen und -entwicklern passen. Diese Diskrepanz führt zu einer wenig überzeugenden Developer Experience. Während Engineering-Teams ihre Container, automatisierten Tests und Cloud-Services problemlos selbst verwalten können, müssen sie oft warten, bis Sicherheits-Scans außerhalb des Entwicklungsprozesses ausgeführt werden. Das macht die Behebung teurer und sorgt für ständige Spannungen mit AppSec-Teams.

Diese mangelnde Transparenz und fehlenden Self-Service-Möglichkeiten erschweren es Entwicklerinnen und Entwicklern, Software-Risiken wirksam zu verwalten. Statt Probleme von vornherein zu verhindern, müssen sie oft raten, welche Option sicher ist, und Probleme später beheben – wenn die Korrektur am teuersten ist. Anders gesagt: Es ist einfach, Risiken einzuführen, und schwer, sicher zu arbeiten. Ein wirklich modernes DevSecOps muss diesen Kreislauf durchbrechen und auf „Secure by Design“-Prinzipien setzen. So entstehen vorgegebene sichere Entwicklungswege, auf denen Entwicklerinnen und Entwickler das Risikomanagement selbst übernehmen und darauf vertrauen können, dass die Standardoption zugleich die sichere Option ist.

Seit seiner Einführung hat sich DevSecOps stark weiterentwickelt. Unsere Studie zeigt, dass sich die meisten Unternehmen auf einem klaren Weg zur Reife befinden. Doch es gibt noch viel Potenzial, das Versprechen einer vertrauenswürdigen, automatisierten und entwicklerorientierten Sicherheitspraxis einzulösen.

Möchten Sie Ihr DevSecOps-Programm weiterentwickeln? Laden Sie noch heute das E-Book herunter.