Durch das Aufkommen von agilen Projektmethoden und die dadurch immer kürzer werdenden Releasezyklen stossen klassische Entwicklungsmethoden an ihre Grenzen. Die Frage lautet daher: Wie lässt sich die Geschwindigkeit erhöhen ohne Abstriche bei Qualität und Sicherheit in Kauf zu nehmen? DevSecOps sieht das Thema Sicherheit als eine gemeinsame Verantwortung über den kompletten Lebenszyklus einer Anwendung.
Klassische Softwareentwicklung vs. DevOps
Klassische Softwareentwicklung erfolgt anhand eines wasserfallähnlichen Prozesses. Jede Phase im Entwicklungsprozess ist fix einem IT Bereich zugeordnet. Die einzelnen Bereiche sind siloartig voneinander getrennt und optimieren ihre, meist händischen, Prozesse auf ihre eigenen Tätigkeiten. Die Entwicklungsabteilung plant und programmiert neue Releases. Diese werden von IT Security einem Audit unterzogen und an den IT Betrieb übergeben um sie während des nächsten Wartungsfenster anhand von Checklisten aufzuschalten. Vom Abschluss der Entwicklung bis zur Inbetriebnahme können leicht Wochen vergehen. Ausserdem sind die vielen manuellen Tätigkeiten fehleranfällig.
DevOps ist nicht einfach nur ein neues Vorgehensmodell, sondern eine Mischung aus Kulturwechsel und Automatisierung von Prozessen durch den Einsatz von neuen Methoden und Tools. Ziel ist es, nicht mehr in Silos zu denken, sondern den Entwicklungsprozess ganzheitlich zu optimieren um damit die Qualität von Softwareprodukten zu steigern. Der Fokus liegt auf der Entwicklung (Dev) und dem Betrieb (Ops). Die zwei am häufigsten eingesetzten Methoden sind:
- Continuous Integration: Jedes Mal, wenn Entwickler neuen Code in das zentrale Repository einpflegen wird automatisch ein neuer Release aus dem Quellcode erstellt und auch gleich getestet. Dies hilft Fehler frühzeitig zu finden und erhöht die Geschwindigkeit neue Versionen bereitstellen zu können.
- Continuous Delivery: Neben dem Build- wird hierbei zusätzlich der Deploymentprozess automatisiert. Dies kann im einfachsten Fall ein einfacher Kopiervorgang sein. In komplexeren Szenarien jedoch auch den automatischen Aufbau der für den Betrieb benötigten Infrastruktur enthalten. Der Übergang von der Build- zur Deploymentphase ist aber auszulösen.
Der Bereich IT Security ist bei DevOps aussen vor und führt dadurch zu Verzögerungen zwischen der Build- und Deploymentphase. Bei kurzen Entwicklungszyklen kann dies dazu führen, dass noch während des Audits eines Release schon weitere Versionen zur Prüfung eingereicht werden.
DevOps vs. DevSecOps
Bei DevSecOps ist IT Security nicht mehr länger eine isolierte Rolle, sondern integraler Bestandteil der einzelnen DevOps Phasen. Mögliche Techniken dafür sind:
- TDD: Entwickler schreiben Tests vor der Implementierung der Businesslogik. Dadurch lässt sich wiederholt die fehlerfreie Funktionsfähigkeit des Codes prüfen.
- Code Analyse: Mit Hilfe von Analyzer lassen sich sowohl mögliche Schwachstellen im Code automatisch finden als auch verwendete Bibliotheken auf bekannte Schwachstellen prüfen.
- Check-In Policies: Neuer Code darf erst nach der Prüfung durch andere Entwickler dem Hauptzweig hinzugefügt werden.
- Automatisierte Tests: Durch verschieden Arten von Tests werden sowohl einzelne Komponenten als auch das komplette System automatisch geprüft.
- Infrastructure as Code: Automatische Deployments in Verbindung mit Policies verhindern manuelle Fehler und stellen die Einhaltung von Sicherheitsrichtlinien sicher.
- Continuous Scanning: Auch wenn zum Zeitpunkt des Buildprozesses keine Sicherheitslücken in den eingesetzten Bibliotheken bekannt waren, kann sich dies über die Zeit ändern. Daher ist dies vorlaufend zu prüfen.
Das Ganze funktioniert aber nur, wenn alle beteiligten Personen über die nötige (Security) Awareness und das nötige Know-How verfügen. Daher ist fortlaufendes Training unerlässlich.
Weiterführende Literatur / Links
DevSecOps-Kontrollen – Cloud Adoption Framework | Microsoft Docs
