DevSecOps bedeutet, Sicherheit in DevOps einzubauen und Sicherheitsprüfungen früh in die CI/CD-Pipeline zu integrieren, mit dem Ziel, Sicherheitsprobleme so früh und so günstig wie möglich und fortlaufend zu erkennen.
Auf einen Blick
Das Ziel ist, Entwurfsfehler und Schwachstellen so früh und so günstig wie möglich zu finden und danach weiter zu suchen.
Eine einfache Pipeline kann mit Prüfungen auf Zugangsdaten in Git-Repositories, Komponentenanalyse, statischen Tests und Scans von Infrastructure-as-Code beginnen.
Für einen unter DORA fallenden Versicherer verlangt die delegierte DORA-Verordnung im Verfahren zum Testen von IKT-Systemen Quellcodeprüfungen mit statischen und dynamischen Tests; DevSecOps selbst schreibt sie nicht vor.
Was ist DevSecOps?
Nach der OWASP DevSecOps Guideline geht es bei DevSecOps darum, Sicherheit in DevOps einzubauen und früh in das Schreiben und Testen von Software einzubringen, damit sie mit dem Tempo von CI/CD mithält. Sicherheitsprobleme, ob Entwurfsfehler oder Schwachstellen in Anwendungen, sollen so früh und so günstig wie möglich erkannt und danach fortlaufend weiter erkannt werden. Auch der Baustein CON.8 des IT-Grundschutzes hält es für wesentlich, dass die Informationssicherheit über den gesamten Software-Entwicklungsprozess hinweg berücksichtigt wird und nicht erst in einer späteren Phase. Für von NIS-2 erfasste Einrichtungen nennt das BSI als Sicherheitsmaßnahme, dass bei der Entwicklung von Software und Systemen die Sicherheit von Anfang an im Sinne eines sicheren Entwicklungszyklus mitgedacht werden muss.
Ein Versicherer, der DevSecOps einführt, könnte etwa Sicherheitsprüfungen automatisiert in seine CI/CD-Pipeline einbetten; dort ließen sich auch Teile der Quellcodeprüfungen mit statischen und dynamischen Tests verankern, die Artikel 16 Absatz 3 der delegierten DORA-Verordnung für Finanzunternehmen im Testverfahren für IKT-Systeme vorsieht. Das Verfahren muss außerdem vorsehen, dass proprietäre Software und nach Möglichkeit der Quellcode von IKT-Drittdienstleistern oder aus Open-Source-Projekten vor der Einführung in der Produktionsumgebung analysiert und getestet werden.
Wie wird DevSecOps umgesetzt?
Eine einfache DevSecOps-Pipeline kann nach der OWASP DevSecOps Guideline mit mehreren Prüfschritten beginnen. Dazu zählt die Suche in Git-Repositories nach möglichem Durchsickern von Zugangsdaten, die Software Composition Analysis (SCA), der statische Anwendungssicherheitstest (SAST) und das Scannen von Infrastructure-as-Code auf Fehlkonfigurationen. Die Schritte lassen sich an den Softwareentwicklungszyklus oder die Softwarearchitektur anpassen, und Automatisierung kann schrittweise ergänzt werden.
Das BSI-Infopaket zu den NIS-2-Sicherheitsmaßnahmen nennt als Beispiele für Sicherheitsprinzipien, die von Anfang an in die Entwicklung von Software und Systemen einbezogen werden, Eingabevalidierung, Verschlüsselung und minimale Berechtigungen.
DevSecOps im Vergleich
DevSecOps ist nach OWASP das Einbringen von Sicherheit in DevOps. DevSecOps ersetzt DevOps also nicht, sondern baut auf einer DevOps-Pipeline auf und ergänzt sie um Sicherheitskontrollen; damit Sicherheit mit dem Tempo von CI/CD mithält, soll sie früh in das Schreiben und Testen von Software eingebracht werden.
Schutz im Ernstfall
Vorbeugen
- Sicherheitskontrollen auch auf die Software für Build, Deployment und Automatisierung anwenden, weil CI/CD-Werkzeuge oft selbst die Angriffsfläche erweitern.
- Ein unter DORA fallender Versicherer muss nach Artikel 16 der delegierten DORA-Verordnung Schwachstellen und Anomalien im Quellcode ermitteln und analysieren, einen Aktionsplan zu ihrer Behebung festlegen und dessen Umsetzung überwachen.
- Die Pipeline an den eigenen Softwareentwicklungszyklus anpassen und Automatisierung schrittweise ergänzen, statt von Beginn an alles aufzubauen.
Beispiele aus der Praxis
- Ein Entwicklungsteam ergänzt seine Pipeline zunächst um die Suche nach möglichen Zugangsdaten in Git-Repositories und baut weitere Prüfschritte nach und nach aus.
- Ein Team kombiniert für eine Anwendung statische und dynamische Tests als Quellcodeprüfung in seinem Entwicklungsablauf.
- Ein Versicherer könnte etwa Sicherheitsprüfungen als feste Schritte seiner CI/CD-Pipeline einrichten, die helfen, Schwachstellen früh zu erkennen.