Globaler DevSecOps-Statusbericht 2023

skizziert.

Über Synopsys' 2023DevSecOpsBericht über die Erhebung der aktuellen Situation

Synopsys Anfang 2023NetzwerksicherheitResearch Centre (CyRC) hat in Zusammenarbeit mit Censuswide, einem internationalen Marktforschungsunternehmen, eine Umfrage unter 1.000 IT-Fachleuten durchgeführt, die für Sicherheit zuständig sind. Zu den Befragten gehörten Entwickler, AppSec-Fachleute, DevOps-Ingenieure, CISOs und IT-Mitarbeiter,Netzwerksicherheitund Anwendungen/Software
Experten in verschiedenen Funktionen im Bereich der Entwicklung, mit Gesprächspartnern aus den USA, dem Vereinigten Königreich, Frankreich, Finnland, Deutschland, China, Singapur und Japan.
Alle Befragten waren zur Teilnahme an der Umfrage berechtigt, unabhängig von ihrer Branche oder Unternehmensgröße. Eine der Herausforderungen bei der Entwicklung dieser Umfrage war, dass der Begriff "DevSecOps" mehrere Disziplinen umfasst, von denen viele ihre eigenen, einzigartigen Rollen haben. Die Umfrage sollte Personen mit unterschiedlichem beruflichem Hintergrund erreichen, darunter sowohl Entwickler, die "direkt" Code schreiben, als auch CISOs, die sich mit Software-Sicherheit beschäftigen.

Über DevOps und DevSecOps

Beschleunigte Entwicklung, kontinuierliche Bereitstellung, Pipeline-Ausfallsicherheit, Skalierbarkeit und End-to-End-Transparenz sind die Schlüsselprinzipien für die Umsetzung von DevOps. Die Erfüllung dieser Kriterien erfordert eine konzertierte Aktion von Entwicklung, Sicherheit und Betrieb.

DevSecOps ist eine Erweiterung der DevOps-Methodik, die darauf abzielt, eine Sicherheitskultur in mehreren Teams zu etablieren und die Sicherheit frühzeitig und konsequent in der DevOps-Umgebung zu berücksichtigen, indem Sicherheitspraktiken in die Softwareentwicklung integriert werden.
Lebenszyklus (SDLC) und CI-Pipelines zielt DevSecOps darauf ab, Sicherheit von einer eigenständigen Phase zu einem Teil des Entwicklungslebenszyklus zu machen.

DevSecOps hat in Unternehmen, die an der Softwareentwicklung beteiligt sind, an Popularität gewonnen, und die SANS State of DevSecOps Survey 2023 zeigt, dass DevSecOps zu einer wichtigen Geschäftspraxis und einem Ansatz für das Risikomanagement geworden ist. In der Vergangenheit gab es jedoch häufig Meinungsverschiedenheiten zwischen Sicherheits- und Entwicklungsteams, wenn es darum ging, Sicherheit in ihre Prozesse zu integrieren.

Die Praxis würde die traditionelleAnwendungssicherheitTesting (AST) Tools in den Software Development Lifecycle (SDLC) zu integrieren. Entwickler beschweren sich oft darüber, dass AST-Tools zu komplex, schwer zu erlernen, wenig leistungsfähig sind und viel "Rauschen" erzeugen, das "Reibung" erzeugt ⸺, also Dinge, die Entwickler daran hindern, während des Softwareentwicklungsprozesses einfach und schnell Code zu erstellen. Sie verhindern, dass Entwickler während des Softwareentwicklungsprozesses einfach und schnell Code erstellen können. Die Mehrheit der Befragten äußerte allgemeine Unzufriedenheit mit den von ihnen verwendeten AST-Tools.

Vorteile der Automatisierung

Das Kernprinzip von DevOps besteht darin, manuelle Prozesse in jeder Phase des SDLC zu automatisieren. Automatisierung ist eine wesentliche Voraussetzung für jedes Unternehmen, um die Entwicklung und Bereitstellung von Code durch kontinuierliche Integration oder kontinuierliche Bereitstellung zu beschleunigen.
Erfolgreiches DevSecOps erfordert das Zusammenspiel von Integration und Automatisierung sowie die Einhaltung von Standards und Richtlinien. Dies gibt dem Sicherheitsteam die Gewissheit, dass die Sicherheitsinteressen gewahrt werden, während das DevOps-Team auf dem Laufenden bleibt und darauf vertrauen kann, dass es nicht zu Unterbrechungen der Pipeline kommt. Im Gegensatz zu manuellen Tests können automatisierte Sicherheitstests schnell und konsistent durchgeführt werden, so dass Entwickler Probleme bereits in einem frühen Stadium des Entwicklungsprozesses erkennen können, ohne dass dies Auswirkungen auf die Liefertermine oder die Produktivität hat.

• Konsistenz
  Automatisierte Tests gewährleisten, dass die Sicherheitsprüfungen bei jedem Build und jeder Bereitstellung einheitlich durchgeführt werden. Manuelles Testen kann zu inkonsistenten Testprozessen und -abdeckungen führen.
• Skalierbarkeit
  Mit zunehmender Komplexität der Software wird das manuelle Testen unpraktisch. Automatisierte Tests sind leicht skalierbar und ermöglichen eine große Anzahl von Tests für verschiedene Komponenten.
• Kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD)
  Automatisierte Tests sind in CI/CD-Pipelines, in denen schnelle und häufige Codeänderungen stattfinden, von entscheidender Bedeutung. Automatisierte Tests können Änderungen schnell validieren und verhindern, dass fehlerhafter Code in die Produktionsumgebung gelangt.
• ständige Verbesserung
  Automatisierte Tests liefern Daten und Erkenntnisse, die Entwicklungs- und Sicherheitsteams dabei helfen können, ihre Sicherheitspraktiken im Laufe der Zeit zu verbessern, indem sie ihnen ermöglichen, systematisch Schwachstellenmuster zu analysieren und zu beheben.
• Rekord (im Sport usw.)
  Automatisierte Tests können den gesamten Testprozess dokumentieren und erleichtern so die Nachverfolgung und Prüfung von Sicherheitsmaßnahmen und Compliance-Anforderungen.
• Verringerung der menschlichen Fehler
  Manuelle Tests sind anfällig für Fehler aufgrund von Ermüdung oder Nachlässigkeit. Automatisierte Tests folgen vordefinierten Skripten und können das Risiko menschlicher Fehler verringern.
• Zeit- und Kosteneinsparungen
  Das Erkennen und Beheben von Sicherheitsproblemen in einem späten Stadium des Entwicklungsprozesses oder während der Produktion ist zeitaufwändig und teuer. Automatisierte Tests minimieren diese Kosten.
• Verbesserung der Erfahrung für Entwickler
  Automatisierte Sicherheitstests für Anwendungen ermöglichen es Entwicklern, einen proaktiven, ganzheitlichen Ansatz bei der Behandlung von Sicherheitsproblemen zu verfolgen, der dazu beiträgt, Sicherheitswissen und -fähigkeiten zu erlernen und zu verbessern, wodurch die Erfahrung der Entwickler verbessert und letztlich die Softwaresicherheit und -effizienz im gesamten Entwicklungsprozess erhöht wird.

Der wachsende Einsatz von ASOC/ASPM in DevSecOps

In diesem Bericht werden Unternehmen in verschiedenen Stadien der DevSecOps-Reife untersucht, einschließlich ihrer Merkmale und der Sicherheitstools/-praktiken, die sie eingeführt haben. Auf der Grundlage der Ergebnisse geben wir ihnen Empfehlungen, wie sie ihre Software-Sicherheitsreife weiter verbessern können.
Interessanterweise zeigen die Umfrageergebnisse, dass der Einsatz von Application Security Orchestration and Correlation (ASOC) - inzwischen allgemein als Application Security Situation Management (ASPM) bezeichnet - immer häufiger vorkommt. Laut Gartner sollte ASPM eine Priorität für jedes Unternehmen sein, das mehrere Entwicklungs- und Sicherheitstools einsetzt.

Von der Entwicklung bis zur Bereitstellung ermöglichen ASPM-Lösungen die kontinuierliche Verwaltung eines breiten Spektrums von Anwendungsrisiken, einschließlich der Erkennung, Korrelation und Priorisierung von Sicherheitsproblemen.
ASPM fungiert auch als Verwaltungs- und Orchestrierungsschicht für Sicherheitstools, um die Kontrolle und Durchsetzung von Sicherheitsrichtlinien zu unterstützen. ASPM verfügt über eine konsolidierte Ansicht der Anwendungssicherheitsergebnisse und bietet somit einen vollständigen Überblick über den Sicherheits- und Risikostatus der gesamten Anwendung oder des Systems.
In Anbetracht der Tatsache, dass die meisten dieser 1.000 Befragten im Allgemeinen mit den von ihnen verwendeten AST-Tools unzufrieden waren - sie beklagten sich darüber, dass sie nicht in der Lage waren, Fehlerbehebungen auf der Grundlage der Geschäftsanforderungen zu priorisieren (35%) oder Daten zusammenzuführen/zu korrelieren, um Probleme zu lösen (29%) - ist es sinnvoll, dass ASOC/ Es macht Sinn, dass die Nutzung von ASPM einen schnellen Wachstumstrend aufweist.

Die wichtigsten Ergebnisse der Synopsys-Umfrage zum Stand von DevSecOps 2023

Die Mehrheit der DevOps-Teams hat DevSecOps bis zu einem gewissen Grad übernommen, wobei insgesamt 911 TP3T der Befragten angaben, dass sie bestimmte Sicherheitsmaßnahmen für die Durchführung von DevSecOps-Aktivitäten in ihre Softwareentwicklungspipeline integriert haben. Man kann mit Sicherheit sagen, dass die Übernahme von DevSecOps-Methoden jetzt Teil der Softwareentwicklung ist.
Organisationen mit ausgereifteren Sicherheitsprogrammen haben Mitarbeiter, die sich der Sicherheit widmen.291 TP3T-Befragte gaben an, dass sie über funktionsübergreifende DevSecOps-Teams verfügen - kollaborative Teams, die sich aus Mitgliedern von Entwicklung, Sicherheit und Betrieb zusammensetzen -, die ein wichtiger Faktor für den Erfolg ihrer Sicherheitsprogramme sind. Mitarbeiter, die sich auf Sicherheit konzentrieren und mit Entwicklern/Softwareingenieuren und/oder QS und Tests zusammenarbeiten, stehen in Unternehmen mit ausgereiften Sicherheitsprogrammen wahrscheinlich an vorderster Front bei Sicherheitstests.

Es gibt viele Hindernisse für eine effektive DevSecOps-Implementierung

Mehr als 331 TP3T der Befragten nannten einen Mangel an Sicherheitsschulungen als Haupthindernis. Dicht gefolgt von einem Mangel an Sicherheitspersonal (311 TP3T), mangelnder Transparenz bei Entwicklung/Betrieb (311 TP3T) und veränderten Prioritäten (301 TP3T).

Mehr als ein Drittel der Befragten gab an, dass die Integration automatischer Sicherheitstests in die Build-/Deployment-Workflows für den Erfolg eines Sicherheitsprogramms entscheidend ist. Weitere wichtige Erfolgsfaktoren sind die Durchsetzung von Sicherheits-/Compliance-Richtlinien durch Infrastructure-as-Code, die Förderung von Sicherheitsbeauftragten in den Entwicklungs- und Betriebsteams sowie die Verbesserung der Kommunikation zwischen Entwicklungs-, Betriebs- und Sicherheitsteams. Kommunikation zwischen den Teams für Entwicklung, Betrieb und Sicherheit.

Der späte Umgang mit größeren Schwachstellen im SDLC kann die Gewinne erheblich schmälern.

Mehr als 80% der Befragten gaben an, dass größere Schwachstellen/Sicherheitsprobleme in der eingesetzten Software ihren Arbeitsfortschritt im Zeitraum 2022-2023 in irgendeiner Form beeinträchtigen.
28% der Befragten gaben an, dass es bis zu drei Wochen dauert, bis ihr Unternehmen größere Sicherheitsrisiken/Schwachstellen in installierten Anwendungen behebt; weitere 20% der Befragten gaben an, dass es bis zu einem Monat dauern kann
Diese Zahlen sind besonders beunruhigend, wenn man bedenkt, dass Sicherheitslücken schneller als je zuvor ausgenutzt werden. Jüngste Studien zeigen, dass mehr als die Hälfte aller Schwachstellen innerhalb einer Woche nach ihrer Offenlegung ausgenutzt werden.

Mehr als 70% der Befragten waren Tabelle 1 zeigt die Arten von automatisierten Scanning-Maßnahmen, die üblicherweise zum Scannen von Code auf Sicherheitslücken und andere Defekte verwendet werden. Sie rangieren in der Kategorie "Nützlichkeit von Tools/Prozessen" an erster Stelle, gefolgt von "Spezifizierung von Sicherheitsanforderungen während der Anforderungsermittlungsphase des SDLC" und "formale Bewertung des Software-Sicherheitsplans durch Modelle wie BSIMM und SAMM". Dicht darauf folgten "Klärung der Sicherheitsanforderungen während der Anforderungsermittlungsphase des SDLC" und "Formale Bewertung von Software-Sicherheitsplänen durch Modelle wie BSIMM und SAMM".

Fast alle Befragten stimmten zu, dass das AST-Tool nicht mit ihren geschäftlichen Anforderungen kompatibel war.

Die meisten der 1.000 Befragten nannten eine ganze Reihe von Problemen mit AST-Tools als ihre größte Herausforderung, darunter die Unfähigkeit dieser Tools, bei der Problembehebung auf der Grundlage der Geschäftsanforderungen Prioritäten zu setzen (35%) und die Unfähigkeit, Daten zusammenzuführen/zu korrelieren, um Probleme zu lösen (29%).
52% Sicherheitsexperten haben begonnen, auf DevSecOps-Veranstaltungen aktiv mit KI zusammenzuarbeiten, aber mehr als drei Viertel sind besorgt über den Einsatz von KI, die
Die Ergebnisse deuten darauf hin, dass Sicherheitsteams aktiv KI, maschinelles Lernen, natürliche Sprachverarbeitung und neuronale Netze nutzen. Der zunehmende Einsatz generativer KI-Tools, wie z. B. KI-gestützter Codierungsempfehlungen, hat jedoch zu einer Reihe von Fragen des geistigen Eigentums, des Urheberrechts und der Lizenzierung von KI-generiertem Code und in einigen Fällen sogar zu Rechtsstreitigkeiten geführt.

Umfrage zum Stand von DevSecOps 2023

DevSecOps-Bereitstellung

Mehr als ein Drittel der 1.000 Befragten war der Ansicht, dass ihr Sicherheitsprogramm die Reifegradstufe 3 erreicht hatte, bei der die Sicherheitsprozesse dokumentiert, wiederholbar und unternehmensweit standardisiert sind. Weitere 251 TP3T der Befragten waren der Ansicht, dass ihr Sicherheitsprogramm den Reifegrad 4 erreicht hat, bei dem die Sicherheitsprozesse auch dokumentiert, überwacht und bewertet werden.
Insgesamt 911 TP3T-Befragte gaben an, dass sie irgendeine Art von DevSecOps-Aktivität in ihrer Softwareentwicklungspipeline angewandt haben, und die Einführung von DevSecOps scheint ein fester Bestandteil von DevOps zu sein.

Welchen Reifegrad hat Ihrer Meinung nach das aktuelle Software-Sicherheitsprojekt/-programm Ihrer Organisation?

Die Umsetzung von Sicherheitspraktiken stellt einen höheren Reifegrad dar

Ein weiteres Maß für die DevSecOps-Reife, das in der Abbildung dargestellt ist, zeigt, dass die Befragten eine breite Palette von Sicherheitspraktiken eingeführt haben, von kontinuierlicher Überwachung und Bewertung (30%) bis zu automatisierten Tests (28%).
Das Sicherheitsrisikomanagement, das von 358 Befragten (35,1%) als Best Practice genannt wurde, umfasst die Integration von Sicherheitsüberlegungen in jeder Phase des Entwicklungsprozesses, um potenzielle Sicherheitsrisiken im Zusammenhang mit Softwareanwendungen zu erkennen, zu bewerten und zu mindern. Im Rahmen des SDLC umfasst das allgemeine Sicherheitsrisikomanagement die folgenden Aktivitäten.

• Anforderungsanalyse. Identifizierung von Sicherheitsanforderungen und -einschränkungen in einem frühen Stadium des SDLC und Definition von Sicherheitszielen.
• Entwurf. Einbeziehung von Sicherheitsgrundsätzen in die Systemarchitektur und den Systementwurf, um sicherzustellen, dass die Anwendungen mit angemessenen Schutzvorkehrungen gegen allgemeine Schwachstellen entwickelt werden.
• Entwicklung. Implementierung sicherer Kodierungspraktiken und Einhaltung von Kodierungsstandards, die Sicherheitsfragen behandeln. Verwendung integrierter Sicherheitstests wie Static Application Security Testing (SAST) und Software Composition Analysis (SCA), um Schwachstellen beim Schreiben von Code und bei der Einführung von Open-Source- oder Drittanbieter-Code zu erkennen.
• Testen. Durchführung verschiedener Arten von Sicherheitstests zur Ermittlung von Schwachstellen in Anwendungen, z. B. SAST, Dynamic Application Security Testing (DAST), SCA und Penetrationstests.
• Bereitstellung. Sichere Konfiguration der Umgebung, in der die Anwendung ausgeführt werden soll. Implementierung von Zugriffskontrolle, Netzwerksicherheit und geeigneten Authentifizierungs- und Autorisierungsmechanismen.
• Überwachung und Bewertung. Kontinuierliche Überwachung von Anwendungen in der Produktionsumgebung auf Sicherheitsereignisse und Anomalien. Implementierung von Protokollierungs- und Überwachungslösungen zur Erkennung
• Erkennen von und Reagieren auf potenzielle Verstöße.301 TP3T-Befragte gaben an, dass dies die wichtigste Sicherheitspraktik in ihrem Unternehmen ist.
• Reaktion und Behebung. Entwickeln Sie einen Plan für die Reaktion auf Zwischenfälle, um Sicherheitsvorfälle schnell und effizient zu behandeln. Behebung von Problemen, die während der Testphase entdeckt wurden.
• Transparenz und Sicherheit. Festlegung klarer Normen, Standards und Strategien sowie Berichterstattung über Sicherheitsrisiken und Risikotoleranz.
• Schulung. Schulungen für Entwicklungsteams zu sicheren Codierungspraktiken, häufigen Schwachstellen und bewährten Sicherheitspraktiken, damit die Entwickler Sicherheitsprobleme proaktiv angehen können. Leider nannten 34%-Befragte "unzureichende/unwirksame Sicherheitsschulungen für Entwickler/Ingenieure" als eines der Haupthindernisse für eine effektive DevSecOps-Implementierung in ihrem Unternehmen.
• Kontinuierliche Verbesserung. Regelmäßige Überprüfung und Verbesserung der Sicherheitsprozesse und -praktiken im SDLC.

Welche Sicherheitsmaßnahmen wendet Ihre Organisation an? (alle zutreffenden Punkte ankreuzen)

Bewertung des Sicherheitsplans

Fast 701 TP3T-Befragte gaben an, dass es nützlich wäre, ihr Sicherheitsprogramm mit einem Bewertungsinstrument wie dem Software Security Architecture Maturity Model (BSIMM) zu bewerten, wobei mehr als ein Drittel eine solche Bewertung als sehr nützlich" einstufte.
Eine externe Bewertung Ihrer Sicherheitslage kann Ihnen dabei helfen, Ihr Softwaresicherheitsprogramm zu analysieren und es mit anderen Organisationen und Ihren Mitbewerbern zu vergleichen. Tools wie BSIMM können datengestützte, objektive Analysen liefern, auf deren Grundlage Sie Entscheidungen über Ressourcen, Zeit, Budget und Prioritäten treffen können. Unabhängig davon, ob Sie gerade erst mit einem Sicherheitsprogramm beginnen oder Ihr bestehendes Programm an die sich ändernden Geschäfts- und Sicherheitsanforderungen anpassen wollen, kann der Vergleich Ihres Software-Sicherheitsprogramms mit anderen Ihre Strategie bestimmen.
Wenn Sie für ein Softwaresicherheitsprogramm verantwortlich sind oder gerade mit der Entwicklung eines solchen Programms beginnen, kann Ihnen das Verständnis der AppSec-Trends unter Ihren Kollegen dabei helfen, Ihre Sicherheitsbemühungen strategisch zu verbessern. Wenn Sie ein Sicherheitsprogramm aus technischer Sicht leiten, können Sie die Informationen aus einer BSIMM- oder Software Assurance Maturity Model (SAMM)-Bewertung nutzen, um taktische Verbesserungen für Mitarbeiter und Prozesse zu entwickeln, z. B. ein Security Champions-Programm.

Dem BSIMM-Bericht zufolge besteht eine der ersten Maßnahmen, die viele Software-Sicherheitsteams ergreifen, darin, Personen zu identifizieren, die die Software-Sicherheit vorantreiben, aber nicht direkt mit dem Software-Sicherheitsteam verbunden sind. Diese Personen, die unter der Bezeichnung "Software-Sicherheitsbeauftragte" bekannt sind, können die Bemühungen um die Software-Sicherheit unterstützen und vorantreiben. Sicherheitsbeauftragte im Entwicklungsteam können beispielsweise Ingenieure dazu ermutigen, die Verantwortung für die Sicherheit ihrer eigenen Softwareprodukte zu übernehmen.331 Die TP3T-Befragten nannten die Entwicklung eines Programms für Sicherheitsbeauftragte als einen der Schlüsselfaktoren für den Erfolg eines Software-Sicherheitsprogramms.

Effektivität der formalen Bewertung der Softwaresicherheit durch Modelle wie BSIMM und SAMM.

Die Bedeutung von funktionsübergreifenden Teams für den DevSecOps-Erfolg

29%-Befragte wiesen darauf hin, dass ein funktionsübergreifendes DevSecOps-Team - ein Team, das sich aus Entwicklungs-, Sicherheits- und Betriebspersonal zusammensetzt - der Schlüssel zum Erfolg eines Sicherheitsprogramms ist (siehe Anhang Q16). Sicherheitsexperten können in Zusammenarbeit mit Entwicklern/Softwareingenieuren und/oder QS- und Testteams (unabhängig davon, ob sie formell Teil des DevSecOps-Teams sind oder nicht) die erste Verteidigungslinie für Sicherheitstests sein und Unternehmen dabei helfen, ausgereiftere Sicherheitsprogramme aufzubauen.
Eine einzige Pipeline von Tests vor und nach der Bereitstellung durch das Sicherheitsteam gehört der Vergangenheit an. In der heutigen Softwareentwicklungsumgebung liegt die Verantwortung für Sicherheitstests beim gesamten Entwicklungsteam, einschließlich der Qualitätssicherungs-, Entwicklungs- und Betriebsteams, und die meisten Teams integrieren die Sicherheit in ihre Software in verschiedenen Phasen des Softwareentwicklungszyklus.
331 TP3T-Befragte gaben an, dass ihre Organisationen auch externe Berater mit der Durchführung von Sicherheitstests beauftragen. Die beste Praxis ist hier die Durchführung regelmäßiger Sicherheitsprüfungen. Die Beauftragung eines externen Prüfers oder Penetrationstesters mit der Durchführung solcher Tests ist von unschätzbarem Wert, da sie einen objektiven Überblick über die Sicherheitslage der gesamten Organisation bietet.

Wer ist in Ihrer Organisation für Sicherheitstests zuständig? (alle zutreffenden Angaben ankreuzen)

Kombination von manuellen und automatisierten Tests für optimale Ergebnisse

Die Umfrageergebnisse zeigen, dass die Mehrheit der Befragten der Meinung ist, dass eine Kombination aus manuellen und automatisierten Sicherheitstests einen umfassenderen Ansatz für die Bewertung der Sicherheit geschäftskritischer Anwendungen bietet. Während automatisierte Tests aus Gründen der Konsistenz, der Skalierbarkeit sowie der Zeit- und Kostenersparnis wichtig sind, kann die menschliche Beteiligung eine zusätzliche Ebene der Einsicht und Anpassungsfähigkeit schaffen, die für die Identifizierung komplexer und subtiler Sicherheitsprobleme unerlässlich ist. Als "Black-Box"-Test (d. h. Testen ohne Kenntnis der internen Abläufe einer Anwendung) erfordert DAST beispielsweise, dass sowohl die Entwickler als auch die Entwickler in den Testprozess einbezogen werden.SicherheitsexperteValidierung und Klassifizierung der Testergebnisse.
Auch die Tatsache, dass externe Penetrationstests von 44%-Befragten als eine Schlüsselkomponente ihrer Sicherheitstests angesehen werden, beweist, dass Penetrationstests eine wichtige Ergänzung zu internen Tests sind. Externe Penetrationstests werden häufig durchgeführt, um Industrienormen und -standards zu erfüllen, und können zusätzliche Vorteile bringen, wie z. B. eine objektive Bewertung der Sicherheitslage Ihres Unternehmens und eine genaue Simulation potenzieller Bedrohungen und Schwachstellen, die von externen Angreifern ausgenutzt werden könnten.

Wie beurteilen oder testen Sie die Sicherheit von geschäftskritischen Anwendungen? (Wählen Sie alle zutreffenden Punkte aus)

Wichtige Leistungsindikatoren

In der Umfrage wurden die Befragten gebeten, die drei wichtigsten Leistungsindikatoren (KPIs) für die Bewertung des Erfolgs ihres DevSecOps-Programms zu nennen. An der Spitze der Liste stand die "Gesamtreduzierung offener Schwachstellen", die von 295 Befragten (29%) genannt wurde, dicht gefolgt von der "Reduzierung sicherheitsrelevanter Probleme, die spät im SDLC entdeckt werden", die von 288 Befragten (28%) genannt wurde, und an dritter Stelle die "Reduzierung sicherheitsrelevanter Probleme, die spät im SDLC entdeckt werden", die von 288 Befragten (28%) genannt wurde. Dicht gefolgt von der "Verringerung der sicherheitsrelevanten Probleme, die in den späten Phasen des SDLC entdeckt werden", die von 288 Befragten (281 TP3T) genannt wurde, und an dritter Stelle die "Zeit zur Lösung von Problemen", die von 281 Befragten (281 TP3T) genannt wurde.

Wie die Umfrageergebnisse zeigen, sind Zeit, Produktivität und Kosten die drei gemeinsamen Nenner der bisherigen KPIs und die Herausforderungen, denen sich Unternehmen bei der Implementierung eines sicheren SDLC stellen müssen. Mit anderen Worten, die drei Hauptprobleme, mit denen DevSecOps-Teilnehmer konfrontiert sind, sind.

• Wie können wir die Anzahl der Schwachstellen/Probleme, die uns begegnen, verringern?
• Wie können wir Schwachstellen in einem früheren Stadium des SDLC finden?
• Wie können wir die Zeit für die Lösung von Problemen verkürzen, um Verzögerungen bei der Erstellung zu verringern und die Entwicklungseffizienz zu verbessern?

Welche sind die wichtigsten KPIs, die Sie zur Bewertung des Erfolgs von DevSecOps-Aktivitäten verwenden? (wählen Sie bis zu 3 aus)

Welche AST-Tools verwenden Sie? Sind sie nützlich?

Die Ergebnisse zeigen, dass erfolgreiche DevSecOps-Strategien ein komplettes Sicherheitstoolset verwenden, um Codequalität und Sicherheitsprobleme während des gesamten Softwareentwicklungszyklus anzugehen, einschließlich dynamischer Anwendungssicherheitstests (DAST), interaktiver Anwendungssicherheitstests (IAST), statischer Anwendungssicherheitstests (SAST) und Softwarekompositionsanalyse (SCA).
Die Ergebnisse der Umfrage zeigen, dass SAST das beliebteste AST-Instrument ist, da 72% der Befragten es für nützlich halten. Es wurde dicht gefolgt von IAST (69%), SCA (68%) und DAST (67%).
SAST und DAST verwenden unterschiedliche Testmethoden für verschiedene SDLC-Phasen, wobei SAST für die Entdeckung und Beseitigung von Schwachstellen in proprietärem Code in einer frühen Phase des SDLC (d.h. vor der Bereitstellung der Anwendung) entscheidend ist, während DAST für die Entdeckung von Problemen während des Betriebs, wie Authentifizierungs- und Netzwerkkonfigurationsfehler, nach der Bereitstellung geeignet ist. SAST ist entscheidend für die Entdeckung und Beseitigung von Schwachstellen in proprietärem Code zu einem frühen Zeitpunkt im SDLC (d.h. vor der Bereitstellung der Anwendung), während DAST für die Entdeckung von Problemen im Betrieb, wie Authentifizierungs- und Netzwerkkonfigurationsfehler, nach der Bereitstellung geeignet ist. IAST kombiniert einige der Funktionen von SAST und DAST für die Entdeckung von bedeutenden Sicherheitsfehlern, die durch andere Testarten nicht erkannt werden können.
SCA eignet sich für die Identifizierung und das Management von Open-Source-Sicherheits- und Lizenzierungsrisiken, was eine wichtige Anforderung in der modernen Softwareentwicklung ist, insbesondere wenn mehr als drei Viertel des Codes in einer bestimmten Anwendung Open-Source sein dürfte. Da viele Unternehmen Softwarepakete von unabhängigen Softwareanbietern sowie Geräte des Internets der Dinge (IoT) und eingebettete Firmware verwenden, müssen sie möglicherweise auch eine Form der SCA-Binäranalyse in ihrem AST-Toolkit durchführen.

Sind die folgenden, von Ihrer Organisation verwendeten Tools für die Anwendungssicherheit nützlich (falls vorhanden)?

Wann wird getestet? Wann werden die Patches angewendet? Wie wirkt sich dies auf unseren Arbeitsplan aus?

Die Häufigkeit der Sicherheitstests von Anwendungen hängt von einer Reihe von Faktoren ab, darunter die tägliche Geschäftskritik der Anwendung, die Branche und die Bedrohungslage. Wie unsere Umfrageergebnisse zeigen, sollten sehr kritische Anwendungen regelmäßig überprüft werden (Abbildung). Die meisten Unternehmen, die an dieser Umfrage teilgenommen haben, gaben an, dass sie durchschnittlich zwei bis drei Tage pro Woche Schwachstellen-Scans für geschäftskritische Anwendungen durchführen.
Auf den ersten Blick mag der Befund, dass Unternehmen mit 281 TP3T bis zu drei Wochen brauchen, um größere Sicherheitslücken zu schließen (Abbildung I), beunruhigend erscheinen, doch muss dies im Zusammenhang mit anderen Faktoren betrachtet werden. Es besteht der Irrglaube, dass die legendären Entwickler in der Lage sind, alle Schwachstellen zu patchen, aber niemand verlangt von den Entwicklern, dass sie sich ohne triftigen Grund mit unwichtigen Schwachstellen befassen.
Bemerkenswert ist, dass das Haupthindernis für die DevSecOps-Implementierung für 311 TP3T der Befragten "mangelnde Transparenz in Dev/Ops" und für 291 TP3T "organisatorische Silos zwischen Dev, Ops und Security" ist (Abbildung 1). und 291 TP3T der Befragten nannten "organisatorische Silos zwischen Entwicklung, Betrieb und Sicherheit" (Abbildung). Beides deutet auf Probleme bei der Risikokommunikation zwischen Sicherheits- und Entwicklungsteams sowie auf die Notwendigkeit einer schnellen Alarmierung und Automatisierung von Sicherheitsrichtlinien hin.
In jedem Fall sollte die Prioritätensetzung bei der Behebung von Schwachstellen mit der geschäftlichen Bedeutung der zu flickenden Anlage, ihrer Kritikalität und dem Risiko, dass die Anlage ausgenutzt wird, in Einklang gebracht werden, insbesondere der letzte Punkt. Untersuchungen zeigen, dass mehr als die Hälfte aller Schwachstellen innerhalb einer Woche nach ihrer Offenlegung ausgenutzt werden.

Wie oft führt Ihr Unternehmen im Durchschnitt Bewertungen oder Tests der Sicherheit von geschäftskritischen Anwendungen durch?

Wie lange braucht Ihr Unternehmen im Durchschnitt, um erhebliche Sicherheitsrisiken/Schwachstellen in installierten oder genutzten Anwendungen zu beseitigen?

Folglich müssen Unternehmen bei der Behebung von Schwachstellen Prioritäten setzen, und zwar auf der Grundlage von CVSS-Scores (Common Vulnerability Scoring System), CWE-Informationen (Common Weakness Enumeration) und der Ausnutzbarkeit von Schwachstellen, und zwar nicht nur am Tag Null der Offenlegung einer Schwachstelle, sondern während des gesamten Lebenszyklus einer Anwendung.
Der CVSS-Score ist ein Industriestandard für die Bewertung des Schweregrads einer Gefahr. Jede Schwachstelle in der National Vulnerability Database (NVD) hat einen Basiswert, mit dessen Hilfe der Schweregrad der Schwachstelle berechnet und die Prioritäten für die Behebung der Schwachstelle festgelegt werden können.Der CVSS-Score ist ein umfassender Basiswert, der die Ausnutzbarkeit und die Auswirkungen der Schwachstelle berücksichtigt.
Der Time Score ist eine Metrik, die Veränderungen im Laufe der Zeit aufgrund von Ereignissen außerhalb der Schwachstelle berücksichtigt. Der Grad der Behebung (gibt es ein offizielles Behebungsprogramm?) und das Vertrauen in die Berichterstattung (ist der Bericht bestätigt?). und das Vertrauen in die Meldung (ist die Meldung bestätigt?). können dazu beitragen, die CVSS-Gesamtwertung an die entsprechende Risikostufe anzupassen.
CWE-Informationen listen Software- oder Hardware-Fehler auf, die sich auf die Sicherheit auswirken, und CWE sagt Entwicklern, welche Fehler ausgenutzt werden können (falls es Schwachstellen gibt). Diese Informationen helfen den Sicherheits- und Entwicklungsteams zu verstehen, worauf die Sicherheitsschulungen für Entwickler zu konzentrieren sind, welche zusätzlichen Sicherheitskontrollen im SDLC und in der Produktion zu implementieren sind und ob Mechanismen zur Bewertung des Schweregrads von Risiken hinzugefügt werden sollen. So kann das Entwicklungsteam beispielsweise SQL-Injection, Pufferüberläufen oder Denial-of-Service-Schwachstellen unterschiedliche Prioritäten zuweisen, je nachdem, mit welchen Daten die Anwendung in Berührung kommt, wo sie eingesetzt wird und welche anderen Umgebungs- und Sicherheitsfaktoren vorliegen.

Das Vorhandensein einer Schwachstelle erhöht die Risikoeinstufung und hilft dem Arbeitsteam, bei der Behebung der risikoreichsten Schwachstellen Prioritäten zu setzen. Nach der Bewertung des Gesamtrisikos ist eine weitere wichtige Information, die Sie berücksichtigen müssen, ob Patches, Abhilfemaßnahmen oder kompensierende Kontrollen bereits verfügbar sind. Wenn Sie beispielsweise zwei Sicherheitslücken mit mittlerem Risiko haben, die nicht genutzt werden, kann die Entscheidung, welche zuerst behoben werden soll, davon abhängen, ob es bereits einen Patch oder eine Lösung gibt.
Ein größeres Sicherheits- oder Schwachstellenproblem in einer bereitgestellten Anwendung hat oft einen Kaskadeneffekt, der sich nicht nur auf die Geschäftsabläufe eines Unternehmens (oder seiner Kunden) auswirkt, sondern auch auf den SDLC als Ganzes, wie in der Abbildung dargestellt.
Probleme mögen unbedeutend sein, wenn sie in einem frühen Stadium der Entwicklung entdeckt werden, aber sie können zu großen Problemen werden, wenn sie in einer bereitgestellten Anwendung entdeckt werden. Automatisierte Sicherheitstests, die in IDEs und CI-Pipelines integriert sind, können Schwachstellen und Defekte im Code unmittelbar nach (oder sogar vor) der Übergabe identifizieren, so dass die Entwickler Probleme beheben können, bevor sie sich nach unten ausbreiten.

Wie stark hat sich im vergangenen Jahr (2022-2023) die Behebung eines größeren Sicherheits-/Schwachstellenproblems auf den Softwarebereitstellungsplan Ihres Unternehmens ausgewirkt?

Herausforderungen für wirksame DevSecOps

Der Mangel an Cybersecurity-Talenten ist eine große Herausforderung für DevSecOps, wie in Abbildung K dargestellt. Viele Unternehmen sind nicht in der Lage, qualifizierte Mitarbeiter für wichtige Cybersecurity-Rollen zu rekrutieren. Einigen Studien zufolge gibt es weltweit 3,5 Millionen offene Stellen im Bereich Cybersicherheit. Da der Markt für ausgebildete Cybersicherheitsexperten wächst, wird die Knappheit des Angebots zu höheren Löhnen für qualifizierte Fachkräfte führen, was sie für viele Regierungsbehörden und kleine und mittlere Unternehmen (KMU) unerschwinglich macht. Wie Abbildung K zeigt, bleibt jedoch die "unzureichende Sicherheitsausbildung für Entwickler/Ingenieure" die größte Herausforderung.
Eine bewährte Strategie zur Lösung dieser Probleme ist die Einrichtung eines Security-Champion-Programms. Dabei handelt es sich um eine Gruppe von Personen aus dem gesamten Unternehmen, die ein überdurchschnittliches Interesse oder überdurchschnittliche Fähigkeiten im Bereich der Sicherheit haben (und die ihr Fachwissen bereits zur Unterstützung von Entwicklungs-, Qualitätssicherungs-, Betriebs- und Wartungsteams einsetzen). Security Champions können Ideen und Feedback zu neuen Projekten liefern und Sicherheits- oder Ingenieurteams dabei helfen, Fähigkeiten im Bereich der Softwaresicherheit mit Fachkenntnissen zu kombinieren, die ihnen bei neuen oder sich schnell ändernden Technologien fehlen. Agile Coaches, Scrum Master und DevOps-Ingenieure sind allesamt hervorragende Kandidaten für Sicherheitsbeauftragte, insbesondere wenn es darum geht, Reibungsverluste im Prozess zu identifizieren und zu beseitigen.

Was sind die Herausforderungen/Hindernisse bei der Umsetzung von DevSecOps in Ihrem Unternehmen? (Wählen Sie alle zutreffenden Punkte aus)

Wie bereits in diesem Bericht erwähnt, wurden AST-Instrumente wie SAST, DAST, IAST und SCA von den Befragten in großem Umfang eingesetzt, doch ist es nach wie vor eine Herausforderung, diese Instrumente effektiv mit den geschäftlichen Anforderungen zu verknüpfen.
Viele Befragte beklagten sich darüber, dass die von ihnen verwendeten Sicherheitstests nicht in der Lage sind, Prioritäten für die Behebung von Schwachstellen auf der Grundlage von Faktoren wie Gefährdung, Ausnutzbarkeit und Schweregrad zu setzen, dass sie zu langsam sind, um schnelle Release-Zyklen/kontinuierliche Bereitstellung zu ermöglichen, und dass sie ungenau und unzuverlässig sind.
Da es keine Möglichkeit gibt, die Ergebnisse verschiedener Sicherheitstests zu konsolidieren oder zu korrelieren, verbringen Sicherheits- und DevOps-Teams zu viel Zeit damit, die Schwachstellen zu identifizieren, die zuerst behoben werden müssen - was einer der Gründe dafür sein könnte, dass fast drei Viertel der Befragten angaben, dass ihr Unternehmen zwischen zwei Wochen und einem Monat braucht, um bekannte kritische Schwachstellen zu patchen.
Werden Schwachstellen nicht schnell gepatcht, beeinträchtigt dies grundlegende Interessen. Mehr als 80% der Befragten gaben an, dass die Behebung größerer Schwachstellen oder damit zusammenhängender Sicherheitsprobleme in eingesetzter Software ihren Arbeitsplan im Zeitraum 2022-2023 beeinträchtigt.

ASOC (Application Security Orchestration and Correlation) und ASPM (Application Security Situation Management) sollen die Fragmentierung und langsame Behebung von AST-Tools beheben. Gartner weist darauf hin, dass ASOC/ASPM als Verwaltungsebene fungieren kann, um mehrere AST-Tools zu orchestrieren und die Korrelation und kontextbezogene Analyse von erkannten Problemen zu automatisieren, um den Behebungsprozess zu beschleunigen und zu optimieren.

ASOC/ASPM extrahiert und konsolidiert Ergebnisse aus verschiedenen Quellen, um eine einheitliche Risikoübersicht über die gesamte Anwendungsumgebung zu erstellen. Dies ermöglicht Ihnen eine datengesteuerte Priorisierung der Abhilfemaßnahmen auf der Grundlage des geschäftlichen Kontexts (z. B. Schweregrad), um eine schnellere Behebung der Schwachstellen mit dem höchsten Risiko zu ermöglichen. ASOC/ASPM kann auch Einblick in die Produktionsumgebung gewähren und so das Problem der langen Zeitspanne bis zur Behebung von Schwachstellen in bereitgestellten Anwendungen angehen und dazu beitragen, Exploits effektiv zu vermeiden, die meist innerhalb weniger Tage nach dem Bekanntwerden der Schwachstelle auftreten.

Was sind die Hauptprobleme mit den in Ihrem Unternehmen eingesetzten Tools für die Anwendungssicherheit? (wählen Sie bis zu 3 aus)

Versprechen und Fallstricke der KI

Die Umfrageergebnisse zeigen, dass der Einsatz von KI in die Software-Sicherheitsprogramme vieler Unternehmen eingedrungen ist. Mehr als 501 TP3T der Befragten gaben an, dass sie KI aktiv in ihren DevSecOps-Praktiken einsetzen.541 TP3T der Befragten suchen nach KI, um die Effizienz und Genauigkeit ihrer Sicherheitsmaßnahmen zu verbessern.481 TP3T der Befragten suchen nach KI, um die manuelle Überprüfung von Sicherheitstests zu reduzieren.542 TP3T der Befragten suchen auch nach KI, um die Effizienz ihrer Sicherheitsmaßnahmen zu verbessern.543 TP3T der Befragten suchen nach KI, um die Effizienz ihrer Sicherheitsmaßnahmen zu verbessern. Tests manuell zu überprüfen.
Dies macht Sinn, wenn man die großen Vorteile bedenkt, die KI potenziell für DevSecOps bieten kann. AppSec-Teams befinden sich oft in einem Dilemma zwischen der Notwendigkeit vollständiger und konsistenter Sicherheitstests und der Notwendigkeit, mit den Entwicklungsteams Schritt zu halten, die DevOps-Methoden und CI-Pipelines verwenden. Bei knappen Fristen ist es für Entwickler leicht, kritische Prozesse zur Bewertung von Sicherheitsrisiken auszulassen.
Die Teilnehmer an dieser Umfrage nannten die "Verbesserung der Genauigkeit und Effizienz von Sicherheitsmaßnahmen" (54%) und die "Verringerung des Bedarfs an manueller Überprüfung und Analyse von Sicherheitsdaten" (48%) als zwei ihrer Hauptziele für die Einführung von KI in den Sicherheits-SDLC. Die beiden Hauptziele der Einführung von KI in den Sicherheits-SDLC sind
Die Befragten gaben jedoch auch an, dass sie davon ausgehen, dass KI "die Komplexität und die technischen Anforderungen an die Softwaresicherheit erhöhen wird" und dass irgendwann der Zeitpunkt kommen könnte, an dem nur noch die KI selbst in der Lage ist, den von KI erzeugten Code angemessen zu prüfen.

Die Implementierung von KI in DevSecOps bringt zusätzliche Herausforderungen mit sich, z. B. die Gewährleistung der Datenqualität und die Berücksichtigung von Sicherheits- und Datenschutzbedenken. Da KI-Tools zunehmend in DevOps-Pipelines integriert werden, werden sie mit ziemlicher Sicherheit zu Hauptzielen für Sicherheitsbedrohungen. Der Umgang mit sensiblen Daten, die zum Trainieren von KI verwendet werden, wirft auch Datenschutzbedenken auf.
Der Einsatz von KI birgt eine Reihe potenzieller Risiken. So kann die KI-gestützte Codierung zu Eigentums-, Urheberrechts- und Lizenzierungsproblemen im Zusammenhang mit dem von der KI erstellten Code führen.
Ende 2022 wurde eine Sammelklage gegen GitHub, Microsoft und OpenAI eingereicht, in der behauptet wird, dass GitHub Copilot - ein cloudbasiertes KI-Tool, das Entwicklern beim Programmieren automatische, ergänzende Vorschläge macht - gegen das Urheberrecht und die Softwarelizenzbestimmungen verstößt und dass der Open-Source-Code, der zum Trainieren von Copilot verwendet wird, die Rechte der Entwickler verletzt. Der Open-Source-Code, der zum Trainieren der Copilot-Dienste verwendet wird, verletzt ebenfalls die Rechte der Entwickler. In der Klage wird auch behauptet, dass der von Copilot vorgeschlagene Code lizenziertes Material ohne Namensnennung, Urheberrechtsvermerke oder Einhaltung der Bedingungen der Originallizenz verwendet.

Generative KI-Chatbots, die auf umfangreichen Sprachmodellen basieren, wie ChatGPT und Google Bard, leiden ebenfalls unter dem Problem, dass sie zufällig "Illusionen" erzeugen, d. h. Antworten, die zwar vertrauenswürdig und sicher erscheinen, in Wirklichkeit aber falsch sind - oder, um es mit den Worten des Laien zu sagen, "Lügen". "Lügen".
KI-Halluzinationen bedrohen eindeutig die Sicherheit der Software-Lieferkette. Forscher haben festgestellt, dass ChatGPT illusorische, nicht existierende Codebasen oder Softwarepakete vorschlagen kann. Böswillige Akteure könnten Pakete mit demselben Namen erstellen, sie mit bösartigem Code füllen und sie dann an ahnungslose Entwickler verteilen, die den Ratschlägen der KI folgen. Dies könnte sich störend auf Cyberkriminelle auswirken und ihnen ermöglichen, herkömmliche und leicht zu entdeckende Techniken wie Rechtschreibfehler oder Tarnung zu umgehen. Tatsächlich haben Forscher herausgefunden, dass Malware-Pakete, die auf der Grundlage von ChatGPTs Phantom-Ratschlägen erstellt wurden, bereits in beliebten Paketmanagern wie PyPI und npm existieren.
Diese Bedrohung ist nicht theoretisch, sie ist real und findet statt. Unabhängig davon, ob ein Angriff auf die Lieferkette von einer KI-Halluzination oder einem böswilligen Akteur ausgeht, ist es entscheidend, die Quelle des Codes zu verstehen, die Identität der Entwickler und Betreuer zu überprüfen und Pakete nur von zuverlässigen Anbietern oder Quellen herunterzuladen, um sich dagegen zu schützen.

Gelernte Lektionen

Die meisten Unternehmen haben zwar einige DevSecOps-Praktiken weitgehend übernommen, stehen aber immer noch vor der Herausforderung, sie effektiv umzusetzen. Die Umfrage ergab, dass sich die Probleme auf zwei Hauptbereiche konzentrieren.
- Integration und Abstimmung der Ergebnisse mehrerer Tools für Anwendungssicherheitstests (AST) mit den geschäftlichen Prioritäten
- Verkürzung der für die Behebung kritischer Schwachstellen erforderlichen Zeit
28% der Befragten gaben an, dass ihr Unternehmen bis zu drei Wochen braucht, um größere Sicherheitsrisiken/Schwachstellen in installierten Anwendungen zu beheben. Weitere 20% der Befragten gaben an, dass die Behebung von Schwachstellen bis zu einem Monat dauern kann, wobei die meisten Schwachstellen bereits wenige Tage nach ihrer Aufdeckung ausgenutzt werden. Die Befragten gaben an, dass es ihnen am unangenehmsten ist, dass AST-Tools nicht in der Lage sind, Schwachstellen-Patches auf der Grundlage von Geschäftsanforderungen zu priorisieren.
Wie in der Einleitung zu diesem Bericht erwähnt, bestand eine der Herausforderungen bei der Entwicklung des Fragebogens darin, dass der Begriff "DevSecOps" eine Reihe verschiedener Disziplinen umfasst, von denen viele ihre eigenen einzigartigen Rollen haben. In Bezug auf "Geschäftsprioritäten" können verschiedene Rollen unterschiedliche Auffassungen von diesem Begriff haben.
Führungskräfte sind beispielsweise am meisten daran interessiert, etwas über die Effektivität der AppSec-Tools zu erfahren, und sie möchten einen umfassenden Überblick über den Prozess und die Verbesserung der Leistung ihrer Teams erhalten. Entwicklungs- und Betriebsteams möchten, dass AppSec ihnen hilft, alle Probleme zentral zu betrachten, um die wertvollsten Sicherheitsaktivitäten zu identifizieren. Sicherheitsexperten wollen das Rauschen eliminieren, damit sie Prioritäten setzen und kritische Probleme schnell angehen können.
Application Security Posture Management (ASPM) kann die notwendigen Verbesserungen für Unternehmen bereitstellen, die Schwierigkeiten haben, isolierte Sicherheitstools zusammenzuführen und gleichzeitig die geschäftlichen Anforderungen zu erfüllen. Dabei werden isolierte Tools automatisch orchestriert, kontextualisiert und priorisiert, damit sich Unternehmen auf die für das Unternehmen wichtigsten Fragen der Anwendungssicherheit konzentrieren können.
- ASPM kann in Entwicklungs- und Sicherheitstesttools sowie in Tools zur Überwachung von Betrieb und Wartung integriert werden, um eine integrierte, einheitliche Sicht auf sicherheitsrelevante Informationen im gesamten Unternehmen zu ermöglichen.
- Durch die Korrelation und Gruppierung von Daten aus verschiedenen Tools, die spezifische Anwendungen und Schwachstellen analysieren, kann ASPM einen umfassenden Überblick über die Gesamtsicherheit einer Anwendung bieten.DevSecOps-Teams können Daten generieren, die für ihre Rollen und Zuständigkeiten relevant sind, und ASPM kann diese Daten auf eine Weise präsentieren, die für Line-of-Business-Manager und andere, die eine breitere Perspektive benötigen, aussagekräftig ist. Das DevSecOps-Team kann Daten generieren, die für seine Aufgaben und Zuständigkeiten relevant sind, und ASPM kann diese Daten auf eine Weise präsentieren, die für Manager in der Geschäftsleitung und andere Personen, die eine umfassendere Perspektive benötigen, aussagekräftig ist.
- Mit ASPM können Sie Sicherheitsrichtlinien entwickeln und durchsetzen, die auf spezifische Risiken im Zusammenhang mit bestimmten Anwendungen und Schwachstellen eingehen. ASPM ermöglicht es Ihnen auch, Sicherheitsprobleme so früh wie möglich zu erkennen und zu beheben, wenn es in Ihre Entwicklungs- oder Betriebsinfrastruktur integriert wird.
Im Gartner-Bericht für 2021 heißt es. Etwa 51 TP3T der befragten Unternehmen haben ASPM oder dessen Vorgänger, das Application Security Orchestration and Correlation (ASOC) Tool, eingeführt, und Gartner erwartet, dass die Einführungsrate schnell ansteigen wird, eine Vorhersage, die durch die Ergebnisse der Umfrage 2023 bestätigt wird, bei der 281 TP3T der befragten Unternehmen bereits mit dem Einsatz von ASOC/ASPM begonnen haben. Gartner stellt außerdem fest, dass Teams mit ausgereiften DevSecOps-Programmen zu den Early Adopters gehören und mehrere Sicherheitstools verwenden - Eigenschaften, die auch die Teilnehmer unserer DevSecOps-Umfrage aufweisen.

Merkmale der Befragten

Die in diesem Bericht untersuchte Umfrage deutet stark darauf hin, dass die fragmentierten Ergebnisse von Sicherheitstools, überlastete Arbeitskräfte und das langsame Tempo der Schwachstellenbehebung grundlegende Herausforderungen sind, die den Erfolg von DevSecOps behindern. Für Unternehmen mit unterschiedlichen DevSecOps-Teams, die mehrere Tools zum Testen der Anwendungssicherheit verwenden, kann ASPM der Schlüssel zur effektiven Bewältigung dieser Herausforderungen sein.

Branchenverteilung der Befragten