DevSecOps (2) : Aspekte und Hinweise zur Umsetzung

Der zweite Teil dieses Beitrags widmet sich Aspekten und Hinweisen zur Umsetzung von DevSecOps, also der Ausweitung von DevOps-Praktiken auf den Bereich des Sicherheitsmanagements.

Risikomanagement

Damit Softwareentwickler bereits bei der Programmierung an die Sicherheit denken (Security by Design), muss die Zusammenarbeit mit dem Securityteam transparent gestaltet sein; das schließt den schnellen Informationsaustausch von Bedrohungen und Sicherheitslücken ein. Die frühe Umsetzung von leichtgewichtigen Risikobewertungen – wie beispielsweise das Rapid-Risk-Assessment von Mozilla (siehe https://infosec.mozilla.org/guidelines/risk/rapid_risk_assessment.html) – bereits in der Entwurfs- oder Konzeptphase ist eine zusätzliche wichtige Maßnahme, um sensible Daten und Dienste zu identifizieren, Bedrohungsszenarien abzuleiten und damit Compliance-, Sicherheits- oder Betriebsrisiken zu reduzieren.

Automatisierung

Security-Teams, die einen DevSecOps-Ansatz verfolgen, sollten im Sinne einer frühen Integration der Informationssicherheit zeitig einen entsprechenden Automatisierungsplan einrichten. Während früher Sicherheitstests kurz vor dem Release durchgeführt wurden, müssen sie heute parallel zur permanenten Entwicklung laufen. Laut dem US-amerikanischen National Institute of Standards and Technology (NIST) ist die Behebung von Sicherheitslücken in den Produktions- und Testphasen um ein Vielfaches teurer als in früheren Entwicklungsstadien.

Sicherheits-Tools

Eine nahtlose Integration von Applikationssicherheit erfordert den richtigen Einsatz von Sicherheits-Tools – das darf jedoch nicht zur Verlängerung der Entwicklungszeiten führen. In diesem Kontext ist moderne Sicherheitstechnologie – beispielsweise Runtime-Application-Self-Protection (RASP) oder Software-Composition-Analysis (SCA) – ein probates Mittel zur DevSecOps-Umstrukturierung, ohne dass dafür unbedingt eigens geschulte Sicherheits-Fachkräfte erforderlich sind.

Als Teil eines umfangreichen Application-Security-Tests erkennt und verwaltet SCA den Einsatz von Open-Source-Komponenten [2], die heute schätzungsweise bereits Teil von 60–80 % aller Applikationen sind – Code wird schließlich heutzutage in der Regel nicht mehr neu generiert, sondern setzt vielmehr auf Software-Bibliotheken auf. Das aktuell verbreitetste Java-Framework Spring Boot (https://spring.io/projects/spring-boot) bindet bereits für ein einfaches Demoprojekt, das auf der offiziellen Website generiert werden kann, knapp 50 Bibliotheken aus dem Internet ein. Eine entsprechende Überwachung und Verwaltung im Sinne der Funktionalität und Sicherheit sowie die Einhaltung von Lizenzbestimmungen bedingt daher zunehmend automatisierte Methoden.

SCA-Tools protokollieren, verfolgen und integrieren Open-Source-Komponenten in den Code einer Applikation, identifizieren Lizenzierungsprobleme und bekannte Schwachstellen in Code-Abhängigkeiten (Bibliotheken und Frameworks). Tools wie beispielsweise Renovate Bot (https://github.com/renovatebot/renovate) prüfen vorhandene Abhängigkeiten auf mögliche Updates und erstellen automatisiert Merge- oder Pull-Requests mit einer neueren Version [3].

RASP dient hingegen dem kontinuierlichen Schutz von Anwendungen und meldet jeden Angriff eigenständig – es ermöglicht einen operativen Einblick in sprach- und frameworkspezifische Schwachstellen. Mit inkrementeller Analyse agiert SCA während der Ausführung in einer Anwendung oder Laufzeitumgebung, sodass die Sicherheit somit auf die Anwendungsebene verlagert wird: Während der Ausführung werden Aufrufe oder Befehle in der Anwendung überprüft. Mittels dieser Technik lässt sich das Verhalten der Anwendung im Kontext analysieren, was eine Reaktion auf spezielle Softwareangriffe in Echtzeit ermöglicht.

Weitere automatisierte Tests

Eine effiziente DevSecOps-Strategie bestimmt die Risikotoleranz und führt eine Nutzen-/Risikoanalyse durch. Das wirft Fragen auf, die sowohl im Vorfeld als auch prozessbegleitend zu beantworten sind – ein wichtiger Faktor, um unter anderem die Zyklen für Sicherheitstests für eine bestimmte Anwendung zu bestimmen. Ohne Automatisierung von sich wiederholenden Aufgaben ist DevSecOps nicht effizient, denn die Durchführung manueller Sicherheitsprüfungen kann sich in der Pipeline langwierig gestalten. Automatisierte Tests sind zwar mit vielen Werkzeugen möglich. Jedoch ist es genau so wichtig, konventionelle Methoden für Sicherheitstests völlig neu zu bewerten und umzustrukturieren. Das ist kein einfaches Unterfangen, weil man gerade im Sicherheitsbereich seit vielen Jahrzehnten denselben Mustern folgt.

Das Automatisieren von Tests sollte auch Prüfungen auf Sicherheitsfunktionen im Abnahmeprozess einbeziehen, die Eingabevalidierungen und Funktionen zur Verifizierungsauthentifizierung/-autorisierung umfassen. Zur Automatisierung gehören zudem Sicherheits-Updates wie Patches für bekannte Schwachstellen innerhalb der DevOps-Pipeline sowie Funktionen zur System- und Service-Konfigurationsverwaltung. Letzteres ist zur Einhaltung von Sicherheitsrichtlinien wichtig: Hierdurch lassen sich manuelle Fehler vermeiden. Durch automatisierte Prozesse sinkt zudem der Aufwand für die agilen Teams.

Verwundbare Komponenten in Anwendungen lassen sich im Rahmen automatisierter Tests idealerweise bereits vor der Implementierung verhindern – mittels systematischer Scans kann man schon während der Programmierung Sicherheitsprobleme identifizieren. Regelmäßige Sicherheitstests (Black-Box-Checks) ermöglichen aber nicht nur ein frühes Erkennen und Schließen von Schwachstellen in der Software: Auch nach der Implementierung bleibt eine automatische Echtzeit-Überwachung, beispielsweise von verdächtigen Datenabfragen, möglich.

Perimeterschutz und Zero Trust

Wie auch in der klassischen IT-Absicherung sollten klassische Perimeter-Sicherheits-Architekturen sowie Monitoringmechanismen integrale Bestandteile in der Pipeline sein. Zudem entwickeln sich neue Lösungen, die den Perimeter-Ansatz ablösen: Zero-Trust-Architekturen (vgl. [4] und S. 14) verlagern Sicherheitsüberprüfungen etwa direkt in die Dienste – jeder untersucht seinen eigenen Traffic und filtert entsprechend. „Zero Trust“ eignet sich für DevSecOps deswegen so gut, weil die Teams ihre Services am besten verstehen und diese entsprechend schützen können.

Die Neudefinition und Verteilung der Zuständigkeiten führt dabei zu einer Reduktion von Komplexität und Erhöhung des Schutzes. Systeme und Verfahren wie Next-Generation-Web-Application-Firewalls (NGWAFs), RASP, CWPP und API-Fuzzing sollten hier ebenfalls zum Einsatz kommen. Web-Application-Firewalls (WAF) sind dabei als Plug-ins oder Appliances zu verstehen, die spezifische Signaturen in HTTP-Traffic filtern. Die meisten Cloudplattformen bieten mittlerweile native WAF-Dienste an, um gegen grundlegende HTTP- und DDoS-Angriffe zu schützen. Fuzzing adressiert hingegen APIs, dateibasierte Anwendungen und Protokolle, um echte Schwachstellen (und nur wenige False Positives) aufzuspüren, vor allem für Anwendungen, die in speicherunsicheren Sprachen wie C/C++ geschrieben sind – Fuzzing ist jedoch auch für Sprachen wie Go, Rust, Java und Python möglich.

Organisation und Kultur

DevOps steht für eine Kultur der funktionsübergreifenden Zusammenarbeit von Teams der Entwicklung und des IT-Betriebs. Deren unterschiedliche Ziele – Agilität in der Entwicklung versus Stabilität und Sicherheit im IT-Betrieb – müssen sich bei DevSecOps nun vereinen.

DevSecOps ist daher auch eine organisatorische und personelle Herausforderung und ist kein einfaches Unterfangen für ein Unternehmen mit bislang isolierten Teams. Auf Personalebene muss eine Zusammenarbeit (re-)organisiert werden, die offene und transparente Kommunikation ermöglicht und entsprechende Schulungen aller Teams zum Thema IT-Sicherheit in DevOps-Prozessen voraussetzt. Das Aufbrechen des herkömmlichen Silodenkens zwischen Entwicklungs-, Sicherheits- und Betriebsteams sowie die Sensibilisierung aller Beteiligten für ein einheitliches Sicherheitsbewusstsein sind unabdingbar, um ein Verantwortungsbewusstsein frühzeitig in den Entwurfs- und Lebenszyklus der Softwareentwicklung einzubringen.

Microservices-Technologie ermöglicht dabei das Ersetzen, Erweitern und Anpassen von Modulen entsprechend der Sicherheitsanforderungen. Einer Radcom-Studie [5] zufolge können allerdings auch neue Sicherheitslücken und höhere Risiken entstehen, wenn Rollen der Development-Security-Operations nicht eindeutig definiert sind – hier benötigt man unbedingt festgelegte Verantwortlichkeiten.

Infrastructure as Code (IaC) bedeutet ebenfalls eine hohe Lernkurve: Cloud-Architekturen, Cloud-Konfigurationssprachen und entsprechende Tools müssen ganzheitlich verstanden werden. Entsprechend brauchen Entwickler spezifische Sicherheitsschulungen, um Bedrohungen identifizieren zu können, Code-Reviews durchzuführen und SAST-Tools anzuwenden. Die Schulung in defensiver Kodierung sowie Konzepte, Risiken und Techniken der sicheren Programmierung sind für DevSecOps elementar.

In einer DevSecOps-Kultur sollte jedes Team einen Sicherheitsexperten für die Risikoanalyse vorhalten. Oberstes Ziel dabei ist, dass der Product-Owner in seinem Entwicklungsplan Operational-Security mit berücksichtigt.

Aber auch Sicherheitsexperten müssen umgekehrt wissen, wie man Code liest und schreibt. Hierbei ist es erforderlich, unter Einsatz moderner Softwareentwicklungswerkzeuge Sicherheitslücken aufzuspüren, um während der Entwicklungsphase entsprechende Maßnahmen ergreifen zu können. Sicherheitsexperten müssen mit CI- und CD-Pipelines sowie programmierbaren Konfigurationsmanagementtools zur automatischen Überprüfung und Durchsetzung von Sicherheits- und Compliance-Richtlinien vertraut sein – und sie sollten die verschiedenen Cloud-Architekturen und -Plattformen einschließlich deren Stärken und Schwächen kennen. Teams bekommen eine Gesamtverantwortung für Anwendungen und Services – nur so lässt sich Compliance erreichen.

Toolchain

Es gibt drei grundlegende Komponenten, die abgesichert werden müssen:

• Code und somit die Anwendung, während sie die Pipeline durchlaufen
• Werkzeuge, aus denen die Pipeline besteht
• Umgebung, in der sich die Pipeline befindet

Vor diesem Hintergrund bedingt eine DevSecOps-Strategie die Integration von Sicherheitskontrollen mittels automatisierter Toolchains (vgl. [6,7]). Dabei müssen etliche Punkte in der Pipeline Berücksichtigung finden, unter anderem:

Container und Microservices

• Schwachstellen- und Antiviren-Scans bei der Erstellung von Container-Images
• Scans von Container-Images und Code-Templates (z. B. Dockerfiles) zur Prüfung von Konfigurationsfehlern anhand bewährter Verfahren für die Einrichtung und Verwendung von Containern (z. B. DockerBench)
• Scans von Containern in Registries, um unsichere Images zu identifizieren
• Patch-Management für Anwendungen und Bibliotheken in Containern
• Härtung / sichere Konfiguration sowie gegebenenfalls Selbstheilung
• Signatur und Zertifizierung von Container-Images
• PKI für digitale Signaturen
• Scans nach eingebetteten Schlüsseln und hart kodierten Anmeldeinformationen
• rollenbasierter Zugriff, vorzugsweise nach Least-Privilege-Prinzip
• strikte Zugangskontrollen und zentrale Authentifizierungsmechanismen für Microservices
• Isolation von Containern mit Microservices für Datenübertragung und Speicherung

Infrastruktur zur Authentifizierung und Autorisierung

• zentrales Identity- und Access-Management (IAM) zur Nutzung von Standardfunktionen in Entwicklungsframeworks

Code/Anwendungen

• statische Code-Analyse
• Scannen nach eingebetteten Schlüsseln, hart kodierten Anmeldeinformationen und rollenbasierter Zugriff

Betriebssysteme

• Vulnerability- und Antiviren-Scans bei der Erstellung von Images virtueller Maschinen
• Patch-Management von Anwendungen und Software-Libraries
• Härtung
• sichere Konfiguration
• kryptografisch signierte und zertifizierte Images von virtuellen Maschinen

Release-Management

• asymmetrisch abgesicherte Releases mit signierten/zertifizierten Container- und OS-Images

Monitoring

• Erkennen von Angriffen auf Anwendungsdienste und Infrastruktur sowie das Management von Sicherheitsereignissen

Automatisierung ist das Herzstück des DevSecOps-Ansatzes. Dieser organisatorischen Herausforderung von „Shift-Left“-Sicherheitspraktiken sollte mittels Automatisierung so früh und so oft wie möglich während des gesamten Software-Development-Life-Cycle (SDLC) begegnet werden. Dabei ist der Einsatz entsprechender Tools wichtig!

Zur Umsetzung der genannten Prinzipien existiert eine große Anzahl von Werkzeugen, die idealerweise basierend auf der individuellen Unternehmenskultur in Form einer Toolchain aufeinander abgestimmt sind. Gartner definiert sieben Phasen entlang des Software-Lebenszyklus, an der sich die DevOps-Toolchain orientieren sollte:

Plan, Create, Verify, Preproduction, Release, Configure und Monitor [6]. Eine mögliche Orientierung zur Implementierung einer Toolchain zeigt Abbildung 2.

Open-Source-Tools

DevSecOps-Tools lassen sich prinzipiell in vier wesentliche Kategorien einteilen: Code-Scanner, Automatisierung, Threat-Intelligence und Testing (vgl. [8]). Die Liste der hier im Folgenden exemplarisch genannten Open-Source-Tools erhebt dabei keinen Anspruch auf Vollständigkeit.

Code-Scanner analysieren jede Zeile des Codes auf Sicherheit hinsichtlich Verwundbarkeit und Anomalien und melden diese. Dabei können auch Logikfehler untersucht werden (Hardcoding, Datenlecks, Umgehung von Berechtigungen, Hintertüren usw.). Beispiele sind Alerta (https://alerta.io), Brakeman (https://brakemanscanner.org) und Shiftleft (https://www.shiftleft.io).

Angesichts der heute genutzten Menge an Open-Source-Code ist es sehr wichtig, das Open-Source-Sicherheits-Management nicht zu vernachlässigen und eine dedizierte Lösung einzusetzen, die über die gesamte DevSecOps-Pipeline hinweg über Open-Source-Risiken aufklärt und alarmiert (siehe auch [9]). Ein Beispiel in diesem Bereich ist das Tool WhiteSource (www.whitesourcesoftware.com), das die Sicherheit, Lizenzierung und Qualität von Open-Source-Komponenten verfolgt und sie mit einer Datenbank von Open-Source-Repositories abgleicht, um Echtzeit-Warnungen sowie Priorisierung und Abhilfemaßnahmen zu liefern.

Zur Kontrolle von Quellcode lassen sich darüber hinaus auch entsprechende Dienste, wie beispielsweise von GitHub (https://github.com) und GitLab (https://gitlab.com), nutzen. Sie unterstützen die Verwaltung von Code-Repositories, Check-in-Workflows, Erstellung, Integration und die Ausführung automatisierter Build-Chains. Im Portfolio sind unter anderem integriertes Code-Scanning für die meisten gängigen Programmiersprachen, Scannen nach „Secrets“, Abhängigkeitsanalysen und andere Sicherheitstests vorhanden.

Automatisierung ist, wie bereits ausgeführt, von zentraler Bedeutung und kann das Scannen, Aufdecken und Beseitigen von Sicherheitslücken umfassen. Dies kann ereignisbasiert erfolgen: Sobald ein Auslöseereignis eintritt, werden Regeln überprüft, Anweisungen sowie Befehle ausgeführt und die Ergebnisse bereitgestellt. Darüber hinaus sind Scans gängiger Betriebssysteme (inkl. Linux und MacOS), Systemhärtung und Compliance-Tests möglich. Tools zur Automatisierung sind beispielsweise Stackstorm (https://stackstorm.com), OWASP Glue (https://github.com/OWASP/glue), Lynis (https://cisofy.com/lynis/) sowie gegebenenfalls auch Synk (https://snyk.io).

Im Sinne von Security by Design ermöglicht Threat-Intelligence die Identifikation und teilweise Vorhersage von Bedrohungen. In diesem Zusammenhang ist beispielsweise das Tool OWASP Threat Dragon (https://owasp.org/www-project-threat-dragon) zu nennen, das Bedrohungsmodell-Diagramme erstellt, um wahrscheinliche Bedrohungen zu erfassen. Zudem umfasst es eine Regel-Engine zur automatischen Generierung von Bedrohungen und anschließenden Abhilfemaßnahmen.

Und nicht zuletzt ist ein kontinuierliches Testen für das Deployment fehlerfreier Anwendungen von hoher Bedeutung. Ein automatisiertes Deployment, das sich auf wiederholbare, überprüfbare und sichere Bereitstellungsschritte stützt, reduziert Kosten und Risiken von Änderungen sowie die Notwendigkeit von Patches. Hierfür existieren Sicherheitstest-Frameworks, die selbstverifizierende Sicherheitsspezifikationen erstellen. Sowohl Webanwendungen als auch APIs lassen sich von extern
(ohne Zugriff auf den Zielquellcode) testen – und auch Sicherheitsaudits können für Zwecke einer kontinuierlichen Compliance unterstützt werden. Tools wie BDD-Security (https://github.com/iriusrisk/bdd-security), Chef InSpec (https://www.chef.io/products/chef-inspec) und GaunIt (http://gauntlt.org) sind bekannte Vertreter dieser Klasse.

Mit spezifischen Tools lassen sich zudem Complianceanforderungen und -richtlinien in Code umsetzen – und zwar auf einer Abstraktionsebene, die sowohl Entwickler als auch Prüfer verstehen. Gleichzeitig können sie auch die Ergebnisse der Prüfungen in die Build- und Delivery-Pipeline mit einbringen. Toolsets für derartige Konformitätstests wie AWS CloudFormation Guard (https://aws.amazon.com/de/blogs/mt/introducing-awscloudformation-guard-2-0/), Chef InSpec (https://docs.chef.io/inspec/), Conftest (www.conftest.dev), Dev-sec.io (https://dev-sec.io) oder Terraform Compliance (https://terraform-compliance.com) unterstützen Entwickler beim Schreiben von Tests und Auditoren bei der Prüfung von Code. Sie können somit Nachweise für die konsequente Umsetzung von Richtlinien erbringen (vgl. [11]).

Fazit

2019 sah Gartner als wesentliches Problem bei DevOps, dass Sicherheit und Compliance auf der Strecke blieben: DevOps-Praktiken würden zwar die Automatisierung fördern, jedoch wäre die Sicherheit noch traditionell manuell und prozesslastig. Zudem würden die meisten Entwickler noch zu wenig Kenntnisse über sicheres Coding mitbringen und konventionelle Ansätze zum Testen der Anwendungssicherheit wären nicht auf Geschwindigkeit und Transparenz ausgelegt [7].

Zwar existiert mittlerweile eine Awareness für die Notwendigkeit von Sicherheit in der agilen Softwareentwicklung im Kontext von DevOps. Doch noch immer werden Informations- und Anwendungssicherheit im Softwareentwicklungsprozess oft nur am Rande behandelt. In der Praxis sind meist noch zu wenige Sicherheits-Tests und -Teams von der ersten Planung bis zum Einsatz und Betrieb von IT-Anwendungen integriert.

Darüber hinaus existieren Zweifel am DevSec-Ops-Modell: Es herrscht die Meinung vor, dass es die Software verlangsamen, die Kosten erhöhen und andere Belastungen mit sich bringen würde. Studien widerlegen dies jedoch. Allerdings stellt API-Sicherheit in der agilen Softwareentwicklung oft ein Hemmnis für Geschwindigkeit und Innovation dar – nicht selten entstehen Wertekonflikte in Produktentwicklungsteams.

Produktmanager, die für die Entwicklung verantwortlich sind, fühlen sich von sicherheitsorientierten Teammitgliedern nicht selten ausgebremst. Dem kann man jedoch durch eine frühe Beteiligung und transparente Zusammenarbeit sowie schlanke Softwareentwicklung begegnen, die besonders auch die Transparenz für die API-Sicherheit erhöht. Hierdurch lassen sich Schwachstellen im Code schnell aufdecken und entsprechende Sicherheitsrichtlinien frühzeitig in der Pipeline ausarbeiten – und so mögliche Schwachstellen mit geringem Kostenaufwand beheben. Zudem ist es möglich, Code kontinuierlich zu analysieren, zu testen, auszuliefern und freizugeben. „Security as Code“ erfordert aber neue Fähigkeiten und neue Denk- und Arbeitsweisen sowie den Einsatz von Automatisierung.

Auch wenn DevSecOps einen gewissen Aufwand bedeutet, birgt eine solche Umstrukturierung mittelfristige Vorteile: Inkrementelle Software-Entwicklung mit integriertem Sicherheitsmanagement kann nicht nur Kosten für auftretende Probleme im Livebetrieb der Software reduzieren. Es erhöht auch die Produktqualität und somit auch die Kundenzufriedenheit – und langwierige Testphasen am Ende eines Entwicklungsprozesses werden obsolet.

Darüber hinaus ist die Automatisierung von Abläufen das wichtigste Instrument in einem DevSec-Ops-Framework: Sicherheit von Anwendungen und der Infrastruktur muss von Anfang an beachtet werden, sodass Sicherheitsfunktionen als fester Bestandteil im gesamten Lebenszyklus integriert sind. Dies setzt aber den Einsatz von Automatisierung von Sicherheitsfeatures voraus und die Wahl der richtigen Tools ist essenziell. Das Automatisieren von Sicherheitstests ist wichtig, um mit der Bereitstellung Schritt zu halten – allerdings muss bei der hohen Geschwindigkeit auch die Risikoerkennung mithalten. Deep-Scanning, Fuzzing und Penetrationstests oder Bug-Bounty-Programme sind weitere essenzielle Mechanismen. Neben der Tatsache, dass sich besonders schnelle Freigabezyklen erzielen und ein agiler Bereitstellungsprozess erreichen lassen, kann man damit Bedrohungen zuverlässiger erkennen und die allgemeine Sicherheit und Stabilität von Anwendungen erhöhen.

DevOps-Tools wachsen und verändern sich in rasantem Tempo – Container und Kubernetes erhöhen die Komplexität und eröffnen neue Angriffsvektoren und Sicherheitsrisiken. Entwicklungs- und Betriebsteams müssen die Sicherheit zu einem integralen Bestandteil des gesamten Lebenszyklus von Anwendungen machen, um kritische IT-Infrastrukturen abzusichern, vertrauliche Daten zu schützen und mit dem Wandel Schritt zu halten. Es existieren aber mittlerweile durchaus passende Frameworks, beispielsweise das Red-Hat-DevSecOps-Framework, das die wichtigsten Sicherheitsanforderungen während des gesamten DevOps-Lebenszyklus als Teil einer Defensein-Depth-Sicherheitsstrategie umfassen soll [10].

Last, but not least, eine häufige, aber dennoch wichtige Warnung: Wie DevOps sollte man auch DevSec-Ops nicht als Technologie, sondern vielmehr als kulturellen Wandel in der Softwareentwicklung verstehen!

Literatur

[1] Evren Eren, DevSecOps (1), <kes> 2021#6, S. 25
[2] Gedeon Rauch, Was ist Software Composition Analysis, DevInsider, Dev-Insider, März 2021, www.dev-insider.de/was-ist-software-composition-analysis-a-1001670
[3] Christian Kühn, DevSecOps – ein „Gratis“-Einstieg mit Open-Source-Tools, Informatik Aktuell, Mai 2021,
www.informatik-aktuell.de/entwicklung/methoden/devsecops-ein-gratis-einstieg-mit-open-source-tools.html
[4] Evren Eren, Der Weg zum Zero-Trust-Networking, <kes> 2020#6, S. 52 und <kes> 2021#1, S. 50
[5] radware, 2019 State of Web Application Security Report, Protecting Applications in the Microservice Era, Oktober 2019, https://blog.radware.com/wp-content/uploads/2019/10/FINAL-2019-WAS-Research.pdf
[6] Christopher Little, Joachim Herschmann, Avoid Failure by Developing a Toolchain That Enables DevOps, Whitepaper, Gartner, Oktober 2017, www.gartner.com/en/documents/3810934-avoid-failure-by-developing-atoolchain-that-enables-dev, online verfügbar via www.aservo.com/sites/default/files/avoid_failure_by_developing_342329.pdf
[7] Mark Horvath, Neil MacDonald, Integrating Security Into the DevOps Toolchain, Whitepaper, Gartner, November
2019, www.gartner.com/en/documents/3975263/integrating-security-into-the-devsecops-toolchain
[8] Firas Sozan, The Ultimate List of Open-Source DevSec-Ops Tools to Improve SRE Performance, Harrison Clarke, März 2021, www.harrisonclarke.com/devops-sre-recruiting-blog/the-ultimate-list-of-open-source-devsecopstools-to-improve-sre-performance
[9] Ayala Goldstein, 9 Best DevSecOps Tools To Integrate Throughout The DevOps Pipeline, WhiteSource-Blog, Juni 2021, www.whitesourcesoftware.com/resources/blog/devsecops-tools/
[10] Red Hat, How to deploy a comprehensive DevSecOps solution, Whitepaper, Juli 2021, www.redhat.com/en/resources/deploy-comprehensive-devsecops-solutionoverview
[11] Jim Bird, Eric Johnson, Frank Kim, Rethinking the Sec in DevSecOps: Security as Code, A SANS Survey, Juni 2021, erhältlich über https://info.veracode.com/sans-survey-rethinking-the-sec-in-devsecops.html (Registrierung erforderlich)

Prof. Dr. Evren Eren lehrt an der City University of Applied Sciences Bremen und forscht zu Mobile sowie IT-Security, Virtualisierung und Clouds.