DevSecOps-Kontrollen

DevSecOps bezeichnet das Schützen von Innovationen durch die Integration von Sicherheitsprozessen und -tools in den DevOps-Entwicklungsprozess.

Da DevOps selbst noch relativ neu ist und daher stark variiert, lässt sich ein erfolgreiches DevSecOps-Verfahren am besten umsetzen, wenn Fragen zur Sicherheit und ihrer Integration in den Entwicklungsprozess komplett verstanden werden. Diese Integrieren der Sicherheit sollte mit geringfügigen Änderungen am Code, an den Entwicklungsprozessen und an der Infrastruktur zum Hosten der Workload beginnen. Konzentrieren Sie sich zunächst auf Änderungen, die die stärksten positiven Auswirkungen auf die Sicherheit haben, dabei aber nur eine geringe Belastung für DevOps-Prozesse darstellen und keine zusätzlichen Qualifikationen erfordern.

In dieser Dokumentation werden die einzelnen Phasen eines CI/CD-DevOps-Prozesses (Continuous Integration und Continuous Delivery) beschrieben und die Sicherheitskontrollen genannt, die zuerst integriert werden sollten.

Planung und Entwicklung

In der Regel folgt die moderne Entwicklung einer agilen Entwicklungsmethodik. Scrum ist eine Implementierung der agilen Methodik, bei der jeder Sprint mit einer Planungsaktivität beginnt. Bei der Einführung von Sicherheit in diesen Teil des Entwicklungsprozesses sollten Sie sich auf Folgendes konzentrieren:

• Bedrohungsmodellierung: Betrachten Sie die Anwendung aus Sicht eines potenziellen Angreifers.
• IDE-Sicherheits-Plug-Ins und Hooks vor dem Commit: Führen Sie einfache statische Analysen innerhalb einer integrierten Entwicklungsumgebung (Integrated Development Environment, IDE) durch.
• Peer Reviews und sichere Programmierstandards: Ermitteln Sie effektive Standards für die sichere Programmierung, und führen Sie Peer Review-Prozesse und Hooks vor jedem Commit ein.

Es ist nicht obligatorisch, alle diese Schritte hinzuzufügen. Jeder Schritt hilft jedoch, Sicherheitsprobleme frühzeitig aufzudecken, wenn sie viel kostengünstiger und einfacher zu beheben sind.

Bedrohungsmodellierung

Die Bedrohungsmodellierung ist wohl die wichtigste Sicherheitsmaßnahme. Sie liefert sofortige Ergebnisse und hilft bei der Ausprägung einer Sicherheitsmentalität bei Entwickler*innen, durch die die Sicherheit in all ihren zukünftigen Projekten verbessert wird.

Dabei ist die Bedrohungsmodellierung ein recht einfaches Konzept, das aber bei Bedarf sehr detailliert und technisch werden kann. Bei der Bedrohungsmodellierung wird ein realistischer Überblick über die Sicherheit Ihrer Anwendung entwickelt und dokumentiert, der Folgendes umfasst:

• Wie können Angreifer den Entwurf der Anwendung ausnutzen?
• Beheben von Sicherheitsrisiken
• Wichtigkeit der Behebung von Fehlern

Sie versetzen sich bei der Bedrohungsmodellierung aktiv in die Rolle eines Angreifers. Es ermöglicht Ihnen, die Anwendung mit dem Blick eines Angreifenden zu sehen. Sie erfahren, wie Sie Versuche blockieren können, bevor Angreifende etwas dagegen tun können. Wenn Ihr Team im Entwurf Benutzerpersonas verwendet, können Sie den Angreifenden als böswillige Persona behandeln.

Es wurden unterschiedliche Ansätze für die Bedrohungsmodellierung veröffentlicht, die von einfachen Frage-Antwort-Methoden bis zu detaillierten toolbasierten Analysen reichen. Sie können Ihren Ansatz auf Methoden wie das STRIDE-Modell oder OWASP-Bedrohungsmodellierung stützen.

Bedrohungsmodellierung: Beginnen Sie einfach

Da einige Ansätze der Bedrohungsmodellierung sehr zeitaufwendig sind und viele Qualifikationen erfordern, empfiehlt es sich, mit einem einfacheren Ansatz mit grundlegenden Fragen zu beginnen. Einfachere Methoden sind zwar nicht so genau, sie lösen jedoch einen kritischen Denkprozess aus und ermöglichen die schnelle Erkennung größerer Sicherheitsprobleme.

Die folgenden einfachen Fragemethoden werden Ihnen den Einstieg erleichtern:

• Einfache Fragemethode von Microsoft: Bei dieser Methode werden spezifische technische Fragen gestellt, mit denen häufige Fehler im Sicherheitsentwurf aufgedeckt werden.
• OWASP-Bedrohungsmodellierung: Bei dieser Methode stellen Sie sich einfache, nicht technische Fragen, um den Prozess der Bedrohungsmodellierung einzuleiten.

Sie können einen oder beide dieser Ansätze anwenden, je nachdem, was für Ihr Team besser funktioniert.

Wenn Ihr Team mit dem Prozess vertraut ist, können sie erweiterte Techniken aus dem Microsoft-Sicherheitsentwicklungslebenszyklus anwenden. Zudem kann das Team Tools zur Bedrohungsmodellierung wie das Microsoft Threat Modeling Tool integrieren, um tiefere Einblicke zu erhalten und den Prozess zu automatisieren.

Eine weitere hilfreiche Ressource ist dieser Leitfaden zur Bedrohungsmodellierung für Entwickler*innen.

Sicherheits-Plug-Ins für die IDE und Hooks vor dem Commit

Für die Entwickler liegt der Fokus häufig auf der Geschwindigkeit für die Fertigstellung, und Sicherheitskontrollen können den Prozess verlangsamen. In der Regel wird der Prozess verzögert, wenn die Sicherheitsüberprüfungen in der Pipeline beginnen. Das Entwicklerteam findet nach dem Pushen des Codes in das Repository potenzielle Sicherheitsrisiken. Um diesen Prozess zu beschleunigen und sofortiges Feedback zu erhalten, empfiehlt es sich, Schritte wie IDE-Sicherheits-Plug-Ins und Hooks vor dem Commit einzuführen.

Sicherheits-Plug-Ins der integrierten Entwicklungsumgebung (IDE) erkennen verschiedene Sicherheitsprobleme während des Entwicklungsprozesses, d. h. in der dem Entwicklerteam vertrauten IDE. Plug-Ins können sofortiges Feedback bereitstellen, wenn der geschriebene Code ein potenzielles Sicherheitsrisiko birgt. Plug-Ins können auch auf Risiken in der Bibliothek oder im Paket von Drittanbietern hinweisen. Je nach der gewählten IDE sind viele Open-Source- oder kommerzielle Plug-Ins verfügbar, die von Sicherheitsunternehmen bereitgestellt werden.

Sie sollten auch darüber nachdenken, ein Framework vor dem Commit einzufügen, sofern das Versionskontrollsystem dies zulässt. Ein Framework vor dem Commit stellt Git-Hookskripts bereit, die das Ermitteln von Problemen ermöglichen, bevor Code an die Code Review übermittelt wird. Ein Beispiel ist vor dem Commit, das Sie in GitHub einrichten können.

Peer Reviews und sichere Programmierstandards

Pull Requests sind in jedem Entwicklungsprozess Standard. Ein Aspekt des Pull Request-Prozesses sind Peer Reviews, mit denen häufig unentdeckte Mängel, Fehler oder Probleme aufgrund von menschlichen Fehlern erkannt werden können. Es hat sich bewährt, eine Sicherheitsfachkraft oder ein erfahrenes Mitglied des Sicherheitsteams einzubeziehen, um Entwickler*innen vor dem Erstellen eines Pull Requests in den Peer Review-Prozess einzubinden und anzuleiten.

Leitfäden für sichere Programmierverfahren helfen Entwicklern dabei, grundlegende Prinzipien für die sichere Programmierung zu erlernen und zu erfahren, wie sie angewandt werden sollten. Es gibt sichere Programmiermethoden wie die OWASP Secure Coding Practices, die in die allgemeinen Abläufe integriert werden können.

Committen des Codes

In der Regel erstellen, verwalten und teilen Entwickler ihren Code in Repositorys wie GitHub oder Azure Repos. Bei diesem Ansatz gibt es eine zentrale Bibliothek von Code mit Versionskontrolle, an der problemlos ganze Entwicklerteams zusammenarbeiten können. Wenn jedoch viele Projektbeteiligte an derselben Codebasis arbeiten, birgt dies auch das Risiko von Änderungen. Diese können zu Sicherheitsrisiken oder dem unbeabsichtigten Einfügen von Anmeldeinformationen oder Token in Commits führen.

Um dieses Risiko zu minimieren, sollten sich Entwicklerteams für eine Überprüfungsfunktion für Repositorys entscheiden und sie implementieren. Tools zum Scannen von Repositorys führen eine statische Codeanalyse von Quellcode in Repositorys durch. Die Tools suchen nach Sicherheitsrisiken oder Anmeldeinformationenänderungen und kennzeichnen alle Elemente, die bearbeitet werden müssen. Diese Funktion dient als Schutz vor menschlichen Fehlern und stellt damit einen nützlichen Schutz für verteilte Teams dar, in denen viele Personen im selben Repository zusammenarbeiten.

Verwaltung von Abhängigkeiten

Bis zu 90 % des Codes in aktuellen Anwendungen enthält Elemente wie oder basiert auf externen Paketen und Bibliotheken. Wenn im Quellcode Abhängigkeiten eingefügt werden, ist es wichtig, potenzielle Risiken zu behandeln. Viele Bibliotheken von Drittanbietern weisen schwerwiegende Sicherheitsprobleme auf. Außerdem wird bei Entwicklungen nicht immer der beste Lebenszyklus verfolgt und die Abhängigkeiten auf dem neuesten Stand gehalten.

Stellen Sie sicher, dass Ihr Entwicklungsteam weiß, welche Komponenten in ihre Anwendungen einbezogen werden sollen. Sie möchten sichere und aktuelle Versionen aus bekannten Quellen herunterladen. Und sie möchten über einen Prozess verfügen, um Versionen auf dem neuesten Stand zu halten. Ihr Team kann Tools wie vom Projekt OWASP Dependency-Check, WhiteSource oder andere nutzen.

Es reicht nicht aus, sich nur auf die Sicherheitsrisiken von Abhängigkeiten oder deren Lebenszyklus zu konzentrieren. Es ist auch wichtig, die Sicherheit von Paketfeeds im Blick zu behalten. Es gibt einige bekannte Angriffsvektoren bei Paketverwaltungssystemen: Typosquatting, Kompromittierung vorhandener Pakete, Ersetzungsangriffe und andere. Daher müssen die für die Paketverwaltung verantwortlichen Personen diese Risiken berücksichtigen. Weitere Informationen finden Sie unter 3 Wege zur Risikominimierung bei der Verwendung privater Paketfeeds.

Statische Anwendungssicherheitstests

Nachdem sich Ihr Team mit den Bibliotheken von Drittanbietern und der Paketverwaltung befasst hat, ist es wichtig, den Schwerpunkt zu verlagern und die Codesicherheit zu verbessern. Es gibt verschiedene Möglichkeiten, die Codesicherheit zu verbessern. Sie können IDE-Sicherheits-Plug-Ins verwenden. Oder Sie können eine inkrementelle statische Analyse vor dem Commit und Commit-Überprüfungen wie zuvor besprochen durchführen. Es ist auch möglich, eine vollständige Quellcodeüberprüfung durchzuführen, um Fehler aufzudecken, die bei den vorherigen Schritten übersehen wurden. Die Überprüfung eines großen Codeblocks ist notwendig, kann aber Stunden oder sogar Tage dauern. Durch diesen Ansatz kann die Entwicklung verlangsamt und erheblich aufwendiger werden.

Ein Team muss jedoch irgendwo beginnen, wenn statische Codescanmethoden implementiert werden. Eine Möglichkeit besteht darin, eine statische Codeanalyse in der Continuous Integration einzufügen, um die Sicherheit zu überprüfen, sobald Änderungen vorgenommen werden. Ein Beispiel ist SonarCloud. Es enthält mehrere SAST-Tools (Static Application Security Testing) für verschiedene Programmiersprachen. SonarCloud bewertet und verfolgt die technischen Schulden mit dem Schwerpunkt auf der Wartbarkeit. Das Tool prüft die Qualität und den Stil des Codes und bietet sicherheitsspezifische Prüffunktionen. Auf dem Markt sind aber noch viele weitere kommerzielle und Open-Source-Tools verfügbar.

Um sicherzustellen, dass die Feedbackschleife funktioniert, muss das Tool unbedingt optimiert werden. Sie möchten False Positive-Ergebnisse minimieren und klares, umsetzbares Feedback über zu behebende Probleme erhalten. Darüber hinaus sollten Sie einen Workflow implementieren, der Codecommits im Standardbranch verhindert, sobald Ergebnisse vorliegen. Sie möchten sowohl Qualitäts- als auch Sicherheitsergebnisse abdecken. Auf diese Weise wird Sicherheit zu einem integralen Teil der Komponententests.

Schützen von Pipelines

DevOps übernimmt die Automatisierung auf eine andere Ebene, da alles im Entwicklungslebenszyklus eine Pipeline durchläuft. Continuous Integration und Continuous Delivery (CI/CD) sind ein wichtiger Aspekt der modernen Entwicklungszyklen. Bei CI/CD führt Ihr Team regelmäßig den gesamten Entwicklungscode in einer zentralen Codebasis zusammen. Darauf basierend werden automatisch die standardmäßigen Build- und Testprozesse ausgeführt.

Infrastrukturpipelines sind ein zentraler Bestandteil des Entwicklungsprozesses. Die Verwendung von Pipelines zum Ausführen von Skripts oder Bereitstellen von Code in Produktionsumgebungen kann besondere Sicherheitsanforderungen mit sich bringen. Sie möchten sicherstellen, dass sich aus Ihren CI/CD-Pipelines keine Möglichkeiten ergeben, bösartigen Code auszuführen, Anmeldedaten zu stehlen oder eine Angriffsfläche zu bieten. Außerdem möchten Sie gewährleisten, dass nur der vom Team zur Veröffentlichung vorgesehene Code bereitgestellt wird.

Die DevOps-Teams müssen sicherstellen, dass geeignete Sicherheitskontrollen für die Pipeline implementiert werden. Je nach ausgewählter Plattform gibt es unterschiedliche Leitfäden für den Umgang mit diesen Risiken. Weitere Informationen finden Sie unter Schützen von Azure Pipelines.

Erstellen und Testen

Viele Organisationen verwenden Build- und Releasepipelines, um die Prozesse zum Erstellen und Bereitstellen von Code zu automatisieren und zu standardisieren. Mit Releasepipelines können Entwicklungsteams iterative Änderungen an Codeabschnitten schnell und in großem Maßstab vornehmen. Die Teams benötigen keinen großen Zeitaufwand für die erneute Bereitstellung oder das Upgrade vorhandener Umgebungen.

Die Verwendung von Releasepipelines ermöglicht es Teams auch, Code von Entwicklungsumgebungen über Testumgebungen schließlich in die Produktion zu übertragen. Die Entwicklungsteams sollten im Zuge der Automatisierung aber auch Sicherheitstools einschließen, die automatisierte Tests anhand von Skripts ausführen, wenn sie Code in Testumgebungen bereitstellen. Die Tests sollten Komponententests für Anwendungsfunktionen umfassen, um Schwachstellen oder öffentliche Endpunkte zu ermitteln. Die Tests stellen einen gewollten Zugriff sicher.

Dynamische Sicherheitstests für Anwendungen

Im klassischen Wasserfall-Entwicklungsmodell wurden Sicherheitsmaßnahmen in der Regel erst am Ende vorgenommen, also direkt vor der Einführung in die Produktion. Einer der beliebtesten Sicherheitsansätze sind Penetrationstests oder Pen-Tests. Penetrationstests ermöglichen es einem Team, die Anwendung aus einer Black-Box-Sicherheitsperspektive zu betrachten, d. h. aus der Sicht eines Angreifenden.

Ein Penetrationstest umfasst mehrere Aktionspunkte. Einer dieser Punkte wird als dynamischer Anwendungssicherheitstest (Dynamic Application Security Testing, DAST) bezeichnet. Ein DAST ist ein Sicherheitstest für Webanwendungen, mit dem Sicherheitsprobleme in der ausgeführten Anwendung ermittelt werden, indem überprüft wird, wie die Anwendung auf speziell vorbereitete Anforderungen reagiert. DAST-Tools werden auch als Sicherheitsrisikoscanner für Webanwendungen bezeichnet. Ein Beispiel ist das Open-Source-Tool OWASP Zed Attack Proxy (ZAP). Es findet Sicherheitsrisiken in der ausgeführten Webanwendung. OWASP ZAP scannt auf unterschiedliche Weise: je nach Konfiguration als passiver Baselinescan oder als vollständiger Scan.

Der Nachteil von Pen-Tests ist, dass sie Zeit kosten. Ein gründlicher Pen-Test kann bis zu mehreren Wochen dauern. Angesichts der rasanten DevOps-Entwicklung ist dieser Zeitrahmen womöglich kaum tragbar. Es ist dennoch sinnvoll, während des Entwicklungsprozesses eine einfachere Version eines Penetrationstests hinzuzufügen, um Probleme aufzudecken, die beim SAST und in vorherigen Schritten möglicherweise übersehen wurden. Dabei können DAST-Tools wie OWASP ZAP hilfreich sein.

Entwicklerteams können OWASP ZAP als Task in die Pipeline integrieren. Während der Ausführung wird der OWASP ZAP-Scanner im Container gestartet. Dann führt er einen Scan durch und veröffentlicht die Ergebnisse. Dieser Ansatz ist vielleicht nicht perfekt, da es kein vollständiger Penetrationstest ist, aber dennoch ist er sehr hilfreich. Es ist eine zusätzliche Qualitätskontrolle im Entwicklungszyklus zur Verbesserung des Sicherheitsstatus.

Überprüfen von Cloudkonfiguration und Infrastruktur

Neben dem Überprüfen und Schützen des Codes für Anwendungen ist sicherzustellen, dass auch die Umgebungen sicher sind, in denen die Anwendungen bereitgestellt werden. Sichere Umgebungen sind der Schlüssel für Organisationen, die sich schnell entwickeln, innovativ sein und neue Technologien nutzen möchten. Sichere Umgebungen helfen Teams auch dabei, schnell neue Umgebungen für Experimente zu erstellen.

Mit den Azure-Funktionen können Unternehmen Sicherheitsstandards in Umgebungen erstellen, wie z. B. mit Azure Policy. Mit Azure Policy können Teams auch Richtliniensätze erstellen. Die Richtliniensätze verhindern das Erstellen bestimmter Workloadtypen oder Konfigurationselemente wie öffentliche IP-Adressen. Diese Leitplanken ermöglichen Teams, in einer sicheren und kontrollierten Umgebung zu experimentieren und die richtige Balance zwischen Innovation und Governance zu finden.

Eine der Möglichkeiten, wie DevOps die Zusammenarbeit zwischen Entwicklungsabteilung und Betrieb verbessern kann, besteht darin, dass sich die bestehende Infrastruktur mithilfe eines „Infrastructure-as-Code“-Ansatzes umwandeln lässt.

Infrastructure-as-Code (IaC) ist die Verwaltung von Infrastruktur (Netzwerken, virtuellen Computern, Lastenausgleichsmodulen und der Verbindungstopologie) in einem beschreibenden Modell. Dabei wird die gleiche Versionsverwaltung verwendet, wie sie das DevOps-Team für Quellcode nutzt. Bei der Anwendung eines IaC-Modells wird analog zu dem Prinzip, dass durch den gleichen Quellcode immer die gleiche Binärdatei generiert wird, jedes Mal die gleiche Umgebung generiert. IaC ist eine zentrale DevOps-Methode, die mit Continuous Delivery verwendet wird.

Bei DevSecOps wird die Sicherheit weiter zum Anfang verschoben. Es geht auch nicht mehr nur um die Sicherheit der Anwendung, sondern auch um die der Infrastruktur. Eine der Möglichkeiten, wie DevSecOps die Infrastruktursicherheit unterstützt, besteht darin, Sicherheitsüberprüfungen einzubeziehen, bevor die Infrastruktur in der Cloud bereitgestellt wird. Wenn die Infrastruktur zu Code wird, gelten für diese die gleichen Sicherheitsmaßnahmen wie für die Anwendungssicherheit. Für die Prüfung der Infrastruktursicherheit auf der Grundlage der von Ihnen gewählten IaC-Strategie gibt es verschiedene Sicherheitstools.

Mit dem Übergang in die Cloud stellt die Containerisierung für Teams einen beliebten Ansatz bei Entscheidungen zur Anwendungsarchitektur dar. Bei einigen Containerrepositorys werden die Images überprüft, um Pakete mit bekannten Sicherheitsrisiken abzufangen. Es besteht aber trotzdem das Risiko, dass ein Container veraltete Software enthält. Deshalb ist es wichtig, Container auf Sicherheitsrisiken zu überprüfen. Es gibt sehr viele Open-Source- und kommerzielle Sicherheitstools für diesen Bereich, von denen einige eine enge Integration in den CD-Prozess unterstützen. Die Sicherheitstools helfen Teams bei der Einführung von DevSecOps für Infrastruktur als Code und insbesondere bei der Nutzung von Containern.

Übergang in die Produktion und den Betrieb

Wenn die Lösung für die Produktion bereitgestellt wird, ist es wichtig, ihren Sicherheitsstatus weiter zu überwachen und zu verwalten. In dieser Phase des Prozesses ist es an der Zeit, sich auf die Cloudinfrastruktur und die Anwendung insgesamt zu konzentrieren.

Überprüfen von Konfiguration und Infrastruktur

Um Einblicke in Cloudabonnements und die Ressourcenkonfiguration über mehrere Abonnements hinweg zu erhalten, verwenden Sie die Azure-Mandantensicherheitslösung vom AzSK-Team.

Azure umfasst Überwachungs- und Sicherheitsfunktionen. Diese Funktionen erkennen ungewöhnliche Ereignisse oder Konfigurationen, die überprüft und möglicherweise behoben werden müssen, und geben entsprechende Warnmeldungen aus. Technologien wie Microsoft Defender für Cloudund Microsoft Defender für Cloud sind Erstanbietertools, die nativ in die Azure-Umgebungen integriert sind. Diese Technologien ergänzen die Umgebungs- und Codesicherheitstools. Zudem ermöglichen sie eine gründliche Sicherheitsüberwachung, damit Organisationen schnell und sicher experimentieren und Innovationen hervorbringen können.

Penetrationstests

Penetrationstests sind eine empfohlene Vorgehensweise, um nach Sicherheitsrisiken in der Infrastruktur- oder Anwendungskonfiguration zu suchen, die potenzielle Schwachstellen für Angriffe darstellen.

Viele Produkte und Partner bieten Dienste für Penetrationstests an. Microsoft stellt ebenfalls einen Leitfaden für Penetrationstests in Azure bereit.

Typische Tests umfassen Folgendes:

• Tests an Ihren Endpunkten, um Sicherheitsrisiken aufzudecken
• Fuzz-Testing (Suchen von Programmfehlern durch nicht wohlgeformte Eingabedaten) Ihrer Endpunkte
• Portüberwachung Ihrer Endpunkte

Handlungsrelevante Informationen

Die Tools und Techniken in diesem Leitfaden bieten ein ganzheitliches Sicherheitsmodell für Organisationen, die sich schnell entwickeln und mit neuen Technologien experimentieren möchten, um Innovationen zu fördern. Ein Schlüsselelement von DevSecOps sind datengesteuerte, ereignisgesteuerte Prozesse. Anhand dieser Prozesse können Teams potenzielle Risiken erkennen, bewerten und darauf reagieren. Viele Unternehmen entscheiden sich für die Integration von Warnmeldungen und Nutzungsdaten in ihre IT-Service-Management-Plattform (ITSM). Das Team kann dann bei Sicherheitsereignissen denselben strukturierten Workflow anwenden, dem es auch bei anderen Incidents und Anforderungen folgt.

Feedbackschleifen

Alle diese Techniken und Tools ermöglichen Teams das Ermitteln und Kennzeichnen von Risiken und Sicherheitslücken, die untersucht und möglicherweise behoben werden müssen. Betriebsteams, die eine Warnung erhalten oder bei der Untersuchung eines Supporttickets ein potenzielles Problem feststellen, benötigen eine Route zurück an das Entwicklungsteam, um Elemente für die Überprüfung zu kennzeichnen. Eine reibungslose, auf Zusammenarbeit ausgelegte Feedbackschleife ist wichtig, um Probleme schnell beheben zu können und Sicherheitsrisiken so weit wie möglich zu minimieren.

Ein gängiges Muster für Feedback ist die Integration in ein Arbeitsverwaltungssystem für Entwicklungsprojekte, wie Azure DevOps oder GitHub. Eine Organisation kann Warnungen oder Incidents mit Arbeitselementen für Entwickler*innen verknüpfen, um Maßnahmen zu planen und zu ergreifen. Über diesen Prozess können Entwickler Probleme innerhalb ihres Standardworkflows aus Entwicklung, Tests und Release effektiv beheben.