Anwenden des Continuous Security Development Lifecycle-Ansatzes (Continuous SDL)

Innovation ist das Lebenselixier jeder Organisation im digitalen Zeitalter. Sie muss nicht nur gefördert, sondern auch aktiv geschützt werden. Innovationssicherheit schützt die Prozesse und Daten Ihrer Innovationen vor Cyberangriffen. Innovationen im digitalen Zeitalter bilden die Entwicklung von Anwendungen mithilfe der DevOps- oder DevSecOps-Methode. Dieser Ansatz ermöglicht es Organisationen, schnell Innovationen zu entwickeln, ohne auf herkömmliche Wasserfallzeitpläne zu warten, die Monate oder Jahre zwischen den Versionen dauern können.

Erfolgreiche Funktionen und Anwendungen erfüllen drei verschiedene Anforderungstypen:

• Funktional (Dev): Ihre Anwendung muss die Geschäfts- und Benutzeranforderungen erfüllen, die sich häufig schnell weiterentwickeln.
• Sicher (Sec): Ihre Anwendung muss gegenüber sich schnell entwickelnden Angriffen resilient sein und von Innovationen in Sicherheitsschutzmaßnahmen profitieren.
• Zuverlässig (Ops): Ihre Anwendung muss zuverlässig und effizient sein.

Diese drei Anforderungen in Einklang zu bringen und eine gemeinsame Kultur zu schaffen, ist von entscheidender Bedeutung, aber oftmals schwierig. Die Führungskräfte der Entwicklungs-, IT- und Sicherheitsteams müssen zusammenarbeiten, um diese Änderungen voranzutreiben.

Schauen Sie sich das folgende Video an, um mehr über die DevSecOps-Methode für sichere und schnelle Innovationen zu erfahren.

Integrieren von Sicherheit während des gesamten Entwicklungslebenszyklus

Es ist wichtig, die Sicherheit während des gesamten Entwicklungslebenszyklus zu integrieren, um den Entwurf, Code und andere Probleme schnell und frühzeitig zu identifizieren und zu korrigieren, während Personen an diesem Teil des Prozesses arbeiten. Durch diesen Ansatz werden später teurere und schwierige Korrekturen vermieden, die zu einer großen Menge an Nachbesserungen führen können.

Sicherheitsrisiken (und die Notwendigkeit, sie zu minimieren) können jederzeit im Entwicklungslebenszyklus auftreten:

• Design: Stellen Sie sicher, dass der Entwurf Angreifern nicht von sich aus erlaubt, nicht autorisierten Zugriff auf die Workload, deren Daten oder andere Unternehmensressourcen in der Organisation zu erhalten.
• Code: Stellen Sie sicher, dass das Schreiben (und Wiederverwenden) von Code Angreifern nicht die Möglichkeit gibt, die Kontrolle über die Anwendung zu übernehmen, um nicht autorisierte Aktionen auszuführen, die Kunden, Mitarbeiter, Systeme, Daten oder andere Unternehmensressourcen beschädigen. Fachkräfte in der Entwicklung sollten auch in einer sicheren Umgebung arbeiten, die es Angreifern nicht erlaubt, die Kontrolle ohne ihr Wissen zu übernehmen.
• Entwickelung und Bereitstellung: Stellen Sie sicher, dass die Prozesse für Continuous Integration und Continuous Deployment (CI/CD) nicht autorisierten Benutzern das Ändern des Codes und die Kompromittierung durch Angreifer verweigern.
• Ausführung: Stellen Sie sicher, dass die Umgebung, in der der Code ausgeführt wird (Cloud, Server, mobile Geräte, Sonstiges) den bewährten Methoden der Sicherheit für Personen, Prozesse und Technologien folgt, damit Angreifer die Workload nicht kompromittieren und missbrauchen können. Dieser Prozess umfasst unter anderem die Einführung bewährter Methoden, Konfigurationen der Sicherheitsbaseline.
• Zero Trust-Architektur und -Governance: Alle diese Phasen sollten Zero Trust-Prinzipe befolgen, um Verletzungen anzunehmen (Kompromittierungen annehmen), das Vertrauen explizit überprüfen und die geringsten Rechte gewähren, die für jedes Benutzerkonto, jede Computer-/Dienstidentität und Anwendungskomponente erforderlich sind.

Was ist DevSecOps?

Technologieinnovationen werden häufig im Kontext eines schnellen, schlanken und agilen Entwicklungsansatzes entwickelt, der Entwicklung und Operationen in einen DevOps-Prozess kombiniert und Sicherheit in diesen Prozess integriert, um Risiken für den Innovationsprozess, das Wachstum der Organisation und die vorhandenen Ressourcen in der Organisation zu minimieren. Durch die Integration der Sicherheit verwandelt sich der Prozess in einen DevSecOps-Prozess.

Sicherheit von Anfang an

Wenn Organisationen DevOps und andere schnelle Innovationsmethoden einführen, muss die Sicherheit direkt in sämtliche Abläufe der Organisation und alle Entwicklungsprozesse einbezogen werden. Wird die Sicherheit erst zu einem späteren Zeitpunkt in den Prozesses integriert, ist dies zumeist teurer, und Korrekturen sind häufig aufwendig.

Verschieben Sie die Sicherheit auf der Zeitachse nach links, um sie in die Bereitstellung, den Entwurf, die Implementierung und den Betrieb von Diensten und Produkten zu integrieren. Wenn Entwicklungsteams auf DevOps umstellen und Cloudtechnologien einführen, muss Sicherheit Teil dieser Transformation sein.

Beim Wasserfallmodell war Sicherheit üblicherweise ein Qualitätsmerkmal nach Abschluss der Entwicklung.

Mit DevOps wird das herkömmliche Entwicklungsmodell (Personen, Prozesse und Technologien) auf die Betriebsteams ausgedehnt. Durch diese Änderung kommt es zu weniger Konflikten, die durch die Trennung der Entwicklungs- und Betriebsteams verursacht wurden. Auf dieselbe Weise dehnt DevSecOps DevOps auf die Sicherheitsteams aus, um Konflikte durch deren Trennung zu verringern.

DevSecOps bedeutet die Integration der Sicherheit in jede Phase des DevOps-Lebenszyklus – von der Idee bis zur Planung, dem Architekturentwurf, der iterativen Anwendungsentwicklung und dem Betrieb. Alle Teams müssen sich gleichermaßen an den Zielen für Innovationsgeschwindigkeit, Zuverlässigkeit und Sicherheitsresilienz ausrichten. Dabei ist ein gegenseitiges Verständnis für die Bedürfnisse der jeweils anderen Teams wichtig, und alle Teams sollten unabhängig von der Quelle zuerst an den wichtigsten Problemen arbeiten.

Die Organisationsmethodik des Cloud Adoption Frameworks bietet weitere Kontextinformationen zu DevSecOps-Strukturen in einer Organisation. Weitere Informationen finden Sie unter Anwendungssicherheit und DevSecOps-Funktionen.

Gründe für DevSecOps

DevOps steht für Agilität – DevSecOps steht für sichere Agilität.

Nahezu jede Organisation auf der Welt versucht durch Softwareentwicklung und Innovationen einen Wettbewerbsvorteil zu erzielen. Das Schützen von DevOps-Prozessen ist entscheidend für den Erfolg jeder Organisation. Angreifer haben diese Umstellung auf benutzerdefinierte Anwendungen längst wahrgenommen und greifen zunehmend solche Anwendungen an. Sehr häufig enthalten diese neuen Anwendungen große Mengen wertvollen geistigen Eigentums, mit ebenso wertvollen neuen Ideen, die auf dem Markt noch einzigartig sind.

Zum Schutz dieser Innovation müssen Organisationen potenzielle Sicherheitslücken und Angriffsvektoren sowohl im Entwicklungsprozess als auch in der Infrastruktur beseitigen, in der die Anwendungen gehostet werden. Dieser Ansatz muss sowohl für die Cloud als auch für lokale Ressourcen gelten.

Angreifer können ihre Ziele erreichen, indem sie Schwachstellen entweder im Entwicklungsprozess, in der zugrunde liegenden Infrastruktur für Workloads oder beides ausnutzen:

• Entwicklungsangriffe mit Schwächen im Anwendungsentwurf und Entwicklungsprozess. Angreifer finden beispielsweise Code, der keine Eingabe überprüft (allgemeine Angriffe wie die Einschleusung von SQL-Befehlen zulässt). Auch können sie feststellen, dass die Anwendung eine schwache Verschlüsselung (oder keine Verschlüsselung) für die Kommunikation verwendet. Darüber hinaus können Angreifer Hintertüren im Code platzieren, über die sie später auf Ressourcen in Ihrer Umgebung oder der Ihrer Kunden zugreifen können.
• Infrastrukturangriffe können mit Standardangriffen Endpunkt- und Infrastrukturkomponenten kompromittieren, auf denen der Entwicklungsprozess gehostet wird. Außerdem können Angreifer einen mehrstufigen Angriff durchführen, bei dem gestohlene Anmeldeinformationen oder Schadsoftware verwendet werden, um von anderen Bereichen der Umgebung aus auf die Entwicklungsinfrastruktur zuzugreifen.

Darüber hinaus ist es aufgrund des Risikos von Angriffen auf die Softwarelieferkette aus folgenden Gründen wichtig, die Sicherheit in Ihre Prozesse zu integrieren:

• Schützen Ihrer Organisation vor schädlichem Code und Sicherheitsrisiken in Ihrer Quellcode-Lieferkette
• Schützen Ihrer Kunden vor Sicherheitsproblemen in Ihren Anwendungen und Systemen, die zu Rufschädigung, Haftung oder anderen negativen geschäftlichen Auswirkungen auf Ihre Organisation führen können

DevSecOps-Journey

Die meisten Organisationen stellen fest, dass DevOps oder DevSecOps für jede bestimmte Workload oder Anwendung tatsächlich ein zweistufiger Prozess ist. Ideen werden zuerst in einem sicheren Raum entwickelt und später als Minimum Viable Product (MVP) in die Produktion freigegeben. Sie werden dann iterativ und kontinuierlich aktualisiert.

Dieses Diagramm zeigt den Lebenszyklus bei diesem Innovationsansatz:

Sichere Innovation ist ein integrierter Ansatz für beide Phasen:

• Bei der Ideenentwicklung wird eine anfängliche Idee überprüft und für die erste Verwendung in der Produktion vorbereitet. Diese Phase beginnt mit einer neuen Idee und endet, wenn das erste Produktionsrelease die MVP-Kriterien (Minimum Viable Product) für Folgendes erfüllt:
  • Entwicklung: Die Funktionalität erfüllt die Mindestanforderungen des Unternehmens.
  • Sicherheit: Alle Funktionen erfüllen die gesetzlichen Compliance-, Sicherheits- und Schutzanforderungen für die Verwendung in der Produktion.
  • Betrieb: Die Funktionalität erfüllt die Mindestanforderungen an Qualität, Leistung und Support, um als Produktionssystem eingesetzt werden zu können.
• DevOps: Diese Phase umfasst den fortlaufenden iterativen Entwicklungsprozess der Anwendung oder Workload, der kontinuierliche Innovationen und Verbesserungen ermöglicht.

Der Imperativ auf Führungsebene: Verbinden von Kulturen

Um diese drei Anforderungen zu erfüllen, müssen alle drei Kulturen zusammengeführt werden, damit auch alle Teammitglieder sämtliche Anforderungen respektieren und zusammen an den gemeinsamen Zielen arbeiten.

Die Integration dieser Kulturen und Ziele in einen echten DevSecOps-Ansatz kann schwierig sein, aber es ist die Mühe wert. In vielen Organisationen treten aufgrund von Konflikten zwischen Entwicklungs-, IT-Betriebs- und Sicherheitsteams, die unabhängig voneinander arbeiten, Probleme auf:

• Langsame Fertigstellung und geringe Agilität
• Qualitäts- und Leistungsprobleme
• Sicherheitsprobleme

Dass Probleme auftreten, ist zwar normal und bei neuen Entwicklungen erwartbar, aber Konflikte zwischen den Teams erhöhen häufig die Anzahl und den Schweregrad dieser Probleme erheblich. Oft treten solche Konflikte auf, weil sich ein oder zwei Teams einen „politischen“ Vorteil versprechen und die Anforderungen anderer Teams wiederholt außer Kraft setzen. Mit der Zeit nehmen nicht behandelte Probleme an Größe und Schweregrad zu. Wenn sie ungelöst bleiben, könnte sich dies mit dem DevOps-Ansatz noch verschlimmern, da die Geschwindigkeit der Entscheidungsfindung zunimmt, um eine schnelle Entwicklung von Geschäftsanforderungen und Kundenpräferenzen zu erfüllen.

Zur Lösung dieser Probleme muss eine gemeinsame Kultur geschaffen werden, in der die Anforderungen von Entwicklung (Dev), Sicherheit (Sec) und Betrieb (Op) berücksichtigt werden, die von der Führungsebene unterstützt werden. Dieser Ansatz ermöglicht Ihren Teams, besser zusammenzuarbeiten und die dringendsten Probleme in einem Sprint zu lösen. Dabei spielt es keine Rolle, ob die Sicherheit oder die Betriebsstabilität verbessert oder wichtige Geschäftsfunktionen hinzugefügt werden.

Führungstechniken

Diese Schlüsseltechniken können Führungskräften dabei helfen, eine gemeinsame Kultur aufzubauen:

1. Niemand gewinnt alle Diskussionen: Führungskräfte müssen sicherstellen, dass keine einzelne Instanz alle Entscheidungen fällt, da dies zu einem Ungleichgewicht führen kann, das sich negativ auf das Unternehmen auswirkt.
2. Erwarten Sie kontinuierliche Verbesserungen, keine Perfektion: Die Erwartungen der Führungskräfte sollten kontinuierliche Verbesserungen und kontinuierliches Lernen sein. Ein erfolgreiches DevSecOps-Programm lässt sich nicht über Nacht umsetzen. Es ist vielmehr eine fortlaufende Reise mit schrittweisen Fortschritten.
3. Berücksichtigen Sie sowohl gemeinsame Interessen als auch individuelle Werte: Achten Sie darauf, dass die Teams sehen können, dass sie an gemeinsamen Ergebnissen arbeiten und jede Person etwas dazu beiträgt, was die anderen nicht können. Bei allen Anforderungen geht es immer um das Erschaffen und Schützen derselben Unternehmenswerte. Das Entwicklungsteam versucht, neue Werte zu schaffen, während die Betriebs- und Sicherheitsteams versuchen, diese Werte vor unterschiedlichen Risikoszenarien zu schützen und damit zu erhalten. Führungskräfte auf allen Organisationsebenen sollten diese Einheit auch kommunizieren und wissen, wie wichtig es für den kurzfristigen und langfristigen Erfolg ist, dass alle Anforderungen erfüllt werden.
4. Sorgen Sie für eine gemeinsame Basis: Alle Teammitglieder sollten grundlegende Kenntnisse über Folgendes haben:
   • Geschäftliche Notwendigkeit: Das Team sollte genau wissen, welche Erlöse auf dem Spiel stehen. Dies sollte sowohl den aktuellen Umsatz (wenn der Dienst offline ist) als auch den potenziellen zukünftigen Umsatz einschließen, der durch eine Verzögerung bei der Bereitstellung von Anwendungen und Features beeinträchtigt werden würde. Nutzen Sie dabei direkte Informationen von den beteiligten Führungskräften.
   • Wahrscheinliche Risiken und Bedrohungen: Basierend auf den Daten vom Threat Intelligence-Team (sofern vorhanden) sollten alle Teams ein Verständnis für die wahrscheinlichen Bedrohungen für das Anwendungsportfolio erhalten.
   • Anforderungen an die Verfügbarkeit: Das Team sollte dieselben Vorstellungen von den betrieblichen Anforderungen haben. Dazu gehören z. B. die notwendige Betriebszeit, die erwartete Lebensdauer der Anwendung und Problembehandlungs- und Wartungsanforderungen (z. B. das Patchen während der Dienstausführung).
5. Veranschaulichen und modellieren Sie das gewünschte Verhalten: Führungskräfte sollten das Verhalten, das sie von ihren Teams wünschen, öffentlich klarstellen und vorleben. Zeigen Sie z. B. Bescheidenheit, legen Sie den Fokus auf das Lernen, und respektieren Sie die anderen Fachrichtungen. Außerdem könnten Entwicklungsmanager z. B. den Wert von Sicherheit und hochwertigen Anwendungen diskutieren oder Sicherheitsmanager die Bedeutung schneller Innovationen und einer hohen Anwendungsleistung erörtern.
6. Überwachen Sie die Spannungen aufgrund der Sicherheit: Sicherheit führt zwangsläufig zu Spannungen, die Prozesse verlangsamen. Führungskräfte müssen daher unbedingt den Grad und die Art der Konflikte durch die Sicherheit überwachen:
   • Gesunde Spannung: Ähnlich wie der Widerstand beim Training einen Muskel stärker macht, stärkt die Integration des richtigen Maßes an Sicherheitsspannungen im DevOps-Prozess die Anwendung, indem zum richtigen Zeitpunkt kritisches Denken erzwungen wird. Das Ziel sollte also sein, dass die Teams diese Erkenntnisse verstehen und anwenden, um die Sicherheit zu verbessern, indem sie z. B. überlegen, warum und wie ein Angreifer versuchen könnte, eine Anwendung zu kompromittieren, und indem sie wichtige Sicherheitsfehler finden und beheben.
   • Ungesunde Spannung: Achten Sie auf Konflikte, die mehr Werte verhindern als sie schützen. Dies geschieht häufig, wenn die von Tools generierten Sicherheitsfehler eine hohe Rate an False Positives aufweisen (z. B. Fehlalarme) oder wenn der Aufwand zur Behebung von Sicherheitsproblemen die möglichen Auswirkungen eines Angriffs bei Weitem übersteigt.
7. Beziehen Sie die Sicherheit in die Budgetplanung ein: Stellen Sie sicher, dass das Sicherheitsbudget in einem sinnvollen Verhältnis zu anderen Investitionen in die Sicherheit steht. Denken Sie dabei z. B. an Veranstaltungen wie Konzerte, bei denen das Budget ganz selbstverständlich die Security einschließt. Einige Organisationen planen generell 10 % der Gesamtkosten für die Sicherheit ein, damit bewährte Sicherheitsmethoden konsistent angewandt werden können.
8. Legen Sie gemeinsame Ziele fest: Sorgen Sie dafür, dass Leistungs- und Erfolgsmetriken für Anwendungsworkloads die Entwicklungs-, Sicherheits- und Betriebsziele widerspiegeln.

Hinweis

Im Idealfall sollten die Teams diese Ziele gemeinsam festlegen, um das Engagement zu steigern. Das gilt übrigens sowohl für die gesamte Organisation als auch für bestimmte Projekte oder Anwendungen.

Festlegen des DevSecOps-MVP

Wenn eine Idee in die Produktion überführt werden soll, muss sichergestellt werden, dass ihre Funktionalität die Mindestanforderungen für jeden Anforderungstyp erfüllt, sie also als Minimum Viable Product (MVP) gelten kann:

• Entwicklerteams (Dev) konzentrieren sich darauf, die geschäftlichen Anforderungen für die schnelle Bereitstellung von Funktionen und die Erwartungen von Benutzern, Kunden und Führungskräften zu erfüllen. Legen Sie die Mindestanforderungen fest, damit eine Funktion zum Erfolg der Organisation beitragen kann.
• Sicherheitsteams (Sec) konzentrieren sich auf die Einhaltung von Complianceverpflichtungen und den Schutz vor Angreifern, die ständig versuchen, sich unberechtigt Zugriff auf die Ressourcen der Organisation zu verschaffen. Legen Sie die Mindestanforderungen fest, um gesetzliche Complianceanforderungen zu erfüllen, den Sicherheitsstatus zu gewährleisten und sicherzustellen, dass Sicherheitsvorgänge aktive Angriffe schnell erkennen und darauf reagieren können.
• Betriebsteams (Ops) konzentrieren sich auf Leistung, Qualität und Effizienz und stellen sicher, dass die Workload auch langfristig einen Mehrwert schaffen kann. Legen Sie die Mindestanforderungen fest, um sicherzustellen, dass die Workload auch ohne große Architektur- oder Entwurfsänderungen in naher Zukunft ausgeführt und unterstützt werden kann.

Die Definitionen des MVP können sich im Lauf der Zeit ändern, und sie unterscheiden sich bei verschiedenen Workloadtypen, während das Team aus eigenen Erfahrungen und von anderen Organisationen lernt.

Natives Integrieren von Sicherheit in den Prozess

Sämtliche Sicherheitsanforderungen müssen darauf ausgerichtet werden, nativ in den vorhandenen Prozess und die vorhandenen Tools integriert zu werden. Zum Beispiel:

• Entwurfsaktivitäten wie die Bedrohungsmodellierung sollten in die Entwurfsphase integriert werden.
• Tools zur Sicherheitsüberprüfung sollten in CI/CD-Systeme (Continuous Integration und Continuous Delivery) wie Azure DevOps, GitHub oder Jenkins integriert werden.
• Sicherheitsprobleme sollten über dieselben Systeme und Prozesse wie für die Nachverfolgung anderer Fehler gemeldet werden und z. B. dasselbe Priorisierungsschema nutzen.

Die Integration der Sicherheit in den Prozess sollte kontinuierlich optimiert werden, wenn die Teams neue Erkenntnisse erlangen und die Prozesse ausgereifter werden. Über Sicherheitsüberprüfungen und Risikobewertungen sollte sichergestellt werden, dass eine Risikominderung in den gesamten Entwicklungsprozess, den endgültigen Dienst in der Produktion und die zugrunde liegende Infrastruktur integriert wird.

Weitere Informationen zu DevSecOps finden Sie unter Technische DevSecOps-Kontrollen.

Tipps zur Journey

Während der Umstellung sollten Sie kontinuierlich auf die schrittweise Umsetzung des Idealzustands hinarbeiten. Viele Organisationen haben auf dieser Journey mit der Komplexität und anderen Herausforderungen zu kämpfen. In diesem Abschnitt werden einige gängige Herausforderungen beschrieben, denen Organisationen gegenüberstehen.

• Weiterbildung und ein Wechsel der Kultur sind wichtige erste Schritte: You go to war with the army you have (Sie müssen den Krieg mit Ihrer eigenen Armee führen). Ihr bestehendes Team muss häufig neue Fähigkeiten erlernen und neue Sichtweisen übernehmen, um die anderen Aspekte des DevSecOps-Modells zu verstehen. Diese Weiterbildung und die Veränderung der Kultur erfordern Zeit und Konzentration und eine besondere Förderung durch Führungskräfte sowie regelmäßige Nachbereitung, damit jede beteiligte Person die Vorteile der Veränderung vollständig verstehen und erkennen kann. Eine drastische Veränderung von Kulturen und Fertigkeiten kann manchmal die berufliche Eignung einzelner Personen infrage stellen und birgt daher Potenzial für heftigen Widerstand. Es ist wichtig, das Warum, Was und Wie der Veränderung für alle Beteiligten und ihre Situation verständlich zu machen.
• Veränderungen dauern Zeit: Sie können nur so schnell voranschreiten, wie Ihre Teams sich an die neuen Auswirkungen auf ihre Arbeit anpassen können. Die Teams müssen auch während der Umstellung weiterhin ihre bestehenden Aufgaben erledigen. Sie müssen daher sorgfältig priorisieren, was am wichtigsten ist, und Ihre Erwartungen an die Geschwindigkeit dieser Änderungen anpassen. Nutzen Sie als Strategie für Ihre Organisation das Prinzip „Krabbeln, Gehen, Laufen“, bei dem die wichtigsten und grundlegenden Elemente an erster Stelle stehen.
• Begrenzte Ressourcen: Eine Herausforderung, mit der Organisationen in der Regel frühzeitig konfrontiert sind, besteht darin, sowohl für die Sicherheit als auch für die Anwendungsentwicklung Personal mit geeigneten Fertigkeiten zu finden. Wenn Organisationen effektiver zusammenarbeiten, finden sie möglicherweise passende Mitarbeiter, z. B. Entwickler mit einem besonderen Sicherheitsverständnis oder Sicherheitsexperten mit Programmierhintergrund.
• Umstellungen bei der Art von Anwendungen, Code und Infrastruktur: Die technische Definition und Erstellung einer Anwendung ändert sich mit der Einführung von Technologien wie serverlosen Lösungen, Clouddiensten, Cloud-APIs und codefreien Anwendungen wie Power Apps. Diese Umstellung verändert auch die Entwicklungsmethoden und die Anwendungssicherheit und ermöglicht sogar Nichtentwicklern, Anwendungen zu erstellen.

Hinweis

Bei einigen Implementierungen werden Verantwortlichkeiten in Bezug auf Betrieb und Sicherheit in der Rolle Site Reliability Engineer (SRE, Websitezuverlässigkeits-Techniker) zusammengefasst.

Auch wenn das Übertragen dieser Zuständigkeiten an eine einzelne Rolle für einige Organisationen der ideale Endzustand sein kann, stellt dies häufig eine extreme Veränderung gegenüber den geltenden Unternehmensverfahren, der Kultur, den Tools und den Fertigkeiten dar.

Auch wenn Sie ein SRE-Modell als Ziel verfolgen, sollten Sie beim Einbetten von Sicherheit in DevOps die praktischen kurzfristigen Ziele und inkrementellen Fortschritte anwenden, die in diesem Leitfaden beschrieben werden, um sicherzustellen, dass Sie eine gute Rendite (ROI) erzielen und die dringendsten Anforderungen erfüllen. Dadurch werden Ihren Betriebs- und Entwicklungsmitarbeitern nach und nach Sicherheitsaufgaben übertragen, sodass sie dem Ziel eines SRE näher kommen (sofern Ihre Organisation plant, dieses Modell später zu übernehmen).

Nächste Schritte

Einen ausführlicheren Leitfaden zu DevSecOps finden Sie unter den technischen DevSecOps-Kontrollen.

Informationen dazu, wie GitHub Advanced Security Sicherheit in Ihre CI/CD-Pipelines (Continuous Integration und Continuous Delivery) integriert, finden Sie unter About GitHub Advanced Security (Informationen zu GitHub Advanced Security).

Weitere Informationen und Tools zur Umsetzung von DevSecOps durch die IT-Organisation von Microsoft finden Sie unter Secure DevOps Kit for Azure (Azure-Kit für sicheres DevOps).