Was ist DevSecOps?
DevSecOps ist ein Ansatz, der Sicherheit als grundlegenden Bestandteil des DevOps-Modells integriert, sodass Sicherheitspraktiken von Beginn der Entwicklung an zur Entwicklungs- und Betriebsarbeit gehören.
Technische Einordnung: Entwicklung, Sicherheit und Betrieb werden entlang des Softwarelebenszyklus verbunden. Sicherheit ist damit keine ausschließlich nachgelagerte Prüfung, sondern wird in Entwicklungs-, Liefer- und Betriebsabläufe einbezogen.
Für wen ist DevSecOps relevant?
DevSecOps ist für Organisationen sowie Fach- und Führungskräfte relevant, die Software entwickeln, liefern oder betreiben. Der gesamte Entwicklungslebenszyklus kann einbezogen werden.
Abgrenzung der Behördenpraxis: Die NIST-Demonstration betrachtet cloudbasierte IT-Entwicklung in mittleren bis großen Unternehmen aus bestimmten Sektoren und fokussiert zunächst nachgebildete Closed-Source-Umgebungen. Diese Merkmale begrenzen das Demonstrationsprojekt, nicht den allgemeinen Anwendungsbereich von DevSecOps. Eine spätere Behandlung von Open-Source-Entwicklung im Projekt ist möglich.
Wann und wie wird DevSecOps eingeführt?
Es gibt keinen universell verbindlichen Auslöser und keine fest vorgeschriebene Prozessfolge. Die Organisation entscheidet risikobasiert, ob und wie sie DevSecOps einführt oder weiterentwickelt.
Autoritative technische Beschreibung: Charakteristisch sind früh integrierte Sicherheitspraktiken, häufig automatisierte Sicherheitstests, Sicherheitsprüfungen in CI/CD sowie die zeitnahe Identifikation, Priorisierung und Behandlung von Schwachstellen. Die konkreten Kontrollen, Technologien und Abläufe hängen von den Anforderungen, den verfügbaren Werkzeugen und den Fähigkeiten des Entwicklungsteams ab.
Wie funktioniert eine DevSecOps-Pipeline?
Eine typische NIST-Referenzumsetzung umfasst die Phasen Plan, Develop, Build, Test, Release, Deploy und Operate. Kontinuierliche Rückkopplung verbindet die Phasen. Kontrollgates prüfen vor dem Übergang, ob Änderungen weitergegeben werden können; solche Gates können technisch oder organisatorisch ausgestaltet sein.
CI/CD-Pipelines automatisieren dabei Build-, Integrations-, Delivery- und Deployment-Abläufe. Die genannten Phasen sind ein Referenzmodell: Technologien, Aktivitäten und konkrete Prozesse dürfen je nach Organisation und Gruppe erheblich variieren.
Welche Grenzen hat DevSecOps?
DevSecOps ist weder ein einheitliches Werkzeugset noch eine Einheitsarchitektur. NIST ordnet den Ansatz als eine von mehreren Entwicklungsmethoden ein und bezeichnet sein Referenzmodell als Leitfaden, nicht als universelle Lösung.
Automatisierung ersetzt organisatorische Kontrollen nicht zwingend. Zudem bildet das NIST-Referenzmodell nicht sämtliche Aktivitäten eines Produktlebenszyklus ab. Es ist deshalb auf den jeweiligen Kontext anzupassen und nicht als vollständige Sollarchitektur zu behandeln.
Welche Fristen und Schwellenwerte gelten für DevSecOps?
Für DevSecOps als technischen Ansatz bestehen keine allgemeine Frist, kein einheitlicher Startzeitpunkt und kein numerischer Schwellenwert. Konkrete Anforderungen können sich unabhängig vom Begriff aus organisations- oder sektorspezifischen Vorgaben ergeben.
Häufige Fehlannahmen
- „DevSecOps ist ein bestimmtes Produkt.“ Nein. Es ist ein anpassbarer Ansatz; Werkzeuge und Technologien können erheblich variieren.
- „DevSecOps setzt eine Cloud- oder Closed-Source-Umgebung voraus.“ Nein. Diese Merkmale beschreiben den begrenzten Umfang der NIST-Demonstration, nicht eine allgemeine Voraussetzung.
- „Automatisierung ersetzt organisatorische Kontrolle.“ Nein. Kontrollgates können technisch oder organisatorisch sein; Automatisierung ist kein zwingender Ersatz für Steuerung und Aufsicht.
- „Jede Organisation muss dieselben Phasen und Werkzeuge einsetzen.“ Nein. Das Referenzmodell ist ein Leitfaden und ausdrücklich keine Einheitslösung.
- „Der Begriff DevSecOps legt feste Termine oder Kennzahlen fest.“ Nein. Aus dem technischen Ansatz selbst folgen weder allgemeine Fristen noch numerische Schwellenwerte.
Was die Geschäftsleitung tun sollte
Praxisempfehlung: Die folgenden Schritte sind risikobasierte Managementmaßnahmen und keine Behauptung einer allgemein verbindlichen Pflicht.
- Geschäfts- oder Missionsanforderungen, Risikotoleranz und verfügbare Ressourcen als Leitplanken für sichere Entwicklungsaktivitäten festlegen.
- Den bestehenden Entwicklungs- und Lieferprozess mit geeigneten sicheren Entwicklungspraktiken abgleichen und Lücken priorisieren.
- Menschen, Prozesse und Technologien passend zum Risiko auswählen; dabei Kosten, Machbarkeit und Anwendbarkeit berücksichtigen.
- Frühe Sicherheitsprüfungen, geeignete automatisierte Tests und technische oder organisatorische Kontrollgates in die Abläufe einplanen.
- Verantwortlichkeiten und Rückkopplungswege für die Identifikation, Priorisierung und Behandlung von Schwachstellen festlegen.
Der NIST Secure Software Development Framework kann hierfür als Ausgangspunkt dienen. Er ist keine starre Checkliste; keine bestimmte Kombination seiner Umsetzungsbeispiele ist vorgeschrieben.
Für die Geschäftsleitung
DevSecOps betrifft Organisationen, die Software entwickeln, liefern oder betreiben, und kann den gesamten Entwicklungslebenszyklus erfassen. Die zentrale Entscheidung besteht nicht in der Beschaffung eines einzelnen Werkzeugs, sondern in der risikogerechten Verbindung von Menschen, Prozessen und Technologie. Für einen nachvollziehbaren Nachweis sollte die Leitung die gewählten Leitplanken, den Abgleich des Ist-Zustands, priorisierte Verbesserungen, Verantwortlichkeiten und die Gründe für Auswahl oder Verzicht dokumentieren.
Quellen
Amtliche technische Quellen:
- NIST NCCoE: DevSecOps Introduction, insbesondere Abschnitte 1, 1.1.1, 1.2 und 1.3.
- NIST NCCoE: DevSecOps Notational Reference Model, insbesondere Abschnitte 3 und 3.1.
- NIST: Secure Software Development Framework, insbesondere „SSDF Practices“ und „SSDF Use“.
