Über unsMediaKontaktImpressum
Frank Pientka 13. Juli 2021

DevSecOps? Kontinuierlich sicherer entwickeln und bleiben

Agile Praktiken haben in vielen Projekten Einzug gehalten. Dabei werden mit Microservices durch immer größer werdende DevOps-Pipelines kleinere und schnellere Änderungen in Produktion gebracht. Da automatisierte Tests inzwischen die Basis für kontinuierliche Softwareentwicklung ist, wird das Thema Sicherheit immer noch oft vernachlässigt. Dabei kann man gerade hier mit frühzeitigen Tests Risiken und technische Schulden minimieren, ohne später hektisch auf bekannte Sicherheitslücken reagieren zu müssen.

Einfach ist nicht einfach

Die agile Softwareentwicklung hat sich bisher auf die Umsetzung von fachlichen User Stories konzentriert. Dabei kam man anfangs flott voran, wurde später jedoch immer langsamer, je mehr Qualitätsmängel auftraten. Bereits Barry Boehm hatte Anfang der 80er den Zusammenhang beschrieben, dass Fehler, je später sie auftreten, erheblich viel mehr Kosten, als wenn sie früher im Softwareprozess erkannt und behoben werden. Gleiches gilt auch für Sicherheitslücken. Vorsorgen geht hier vor Reparieren. Wenn man dafür bereits einen funktionierenden DevSecOps-Prozess hat, lassen sich auch Reparaturen schneller und sicherer durchführen.

Heute besteht eine Software aus einer Vielzahl, vor allem von Open-Source-Komponenten. Die Wiederverwendung von Open-Source-Komponenten ist ein wichtiger Schritt, um die wirklich wettbewerbsrelevanten Anforderungen umzusetzen. Doch nur weil die Open-Source-Komponenten umsonst angeboten werden, bedeutet das nicht, dass bei deren Verwendung keine Kosten anfallen. Zu einem Riskmanagement gehört, dass die rechtliche Unbedenklichkeit der verwendeten Open-Source-Lizenzen überprüft wird. Ebenso muss kontrolliert werden, ob die Open-Source-Komponenten keine Sicherheitslücken enthalten und auf dem Weg von der Erstellung zur Verwendung nicht verändert wurden.

Auch Infrastruktur ist Code

Eines der Erfolgsprinzipien von DevOps ist, dass alle Schritte automatisiert sind, um so den menschlichen Fehler-Faktor möglichst zu minimieren. Dadurch, dass Rechenleistungen inzwischen wenig kosten und durch die Virtualisierung Umgebungen auf Knopfdruck erstellt werden können, werden Umgebungen nur noch auf Bedarf automatisch installiert und konfiguriert. Das hat den Vorteil, dass Fehler schneller nachvollzogen werden können und Umgebungen nicht so schnell altern, da diese immer frisch und von Grund auf neu erstellt werden. Gerade durch den Einsatz von Containern und Kubernetes kann hier eine komplette Infrastruktur, inklusive Netzwerk und Speicher, aufgesetzt werden. Da diese Infrastruktur textuell beschrieben wird, können deren Dateien versioniert und getestet werden. Dies ist ein enormer Vorteil, da bei modernen DevOps-Pipelines alle Informationen aktuell an einer Stelle versioniert und nachvollziehbar vorliegt. So kann auf Fehler durch spätere Änderungen schneller reagiert werden, da die mögliche Ursache einfacher und zeitnaher gefunden werden kann. Da das Team sowohl für die Entwicklung als auch für den Betrieb der Software komplett verantwortlich ist, wirkt sich das auch auf den Bau und das Ausliefern der Komponenten aus. Protokolldateien und Gesundheitschecks sind hier wertvolle Mittel, um die Verfügbarkeit zusammen mit Resilienzmustern zu verbessern.

Gerade bei der Cloud-Native-Entwicklung muss das Team sich nicht nur um die Codequalität kümmern, sondern auch um die anderen beiden C’s: die Container und die Cluster (s. Abb. 2). Selbst wenn Container- und Clusterdistributionen hier ein wenig Pflegearbeit abnehmen, muss man trotzdem eine Strategie entwickeln, bekannte Sicherheitslücken proaktiv zu erkennen oder noch besser: per Design zu minimieren. Container altern oft schneller als gedacht und die dort verwendeten Bibliotheken enthalten innerhalb kurzer Zeit nach der Erstellung eines Container-Images oft hunderte Schwachstellen. Deswegen sollten die Container-Images möglichst nur das wirklich Notwendige enthalten und Komponenten, die öfters aktualisiert werden, in eine höhere Schicht ausgelagert werden. Auf jeden Fall sollen die Container-Images regelmäßig auf Sicherheitslücken überprüft und aktualisiert werden.

Dadurch, dass ein Entwickler sich nicht mehr nur um die Erstellung und das Testen seines Codes kümmert, sondern die dauerhafte Nutzbarkeit der Dienste in Produktion das Erfolgskriterium ist, muss sich der Entwickler auch mit Betriebs- und Sicherheitsaspekten beschäftigen, um so ein umfassendes Verständnis ihrer Aufgaben zu erhalten und geeignete Maßnahmen umsetzen zu können.

Das DevOps Research and Assessment (DORA) Forschungsprogramm hat hierfür vier Hauptmetriken (Lead Time, Change Fail, Deployment Frequency, Time to Restore) identifiziert. Gerade die Reparaturzeit-Matrix kann durch die kontinuierliche Anwendung von Sicherheitstest nachweislich reduziert werden.

Ein weiterer Vorteil eines DevOps-Teams ist auch das gemeinsame Verständnis der Anwendung und das Ausbalancieren der unterschiedlichen Interessen. Durch die verkürzten Feedback- und Kommunikationswege werden Konflikte und Wartezeiten frühzeitig minimiert.

Sicherheit ist kein Ziel, sondern eine Reise

Die Sicherheit eines Systems wurde oft durch ein externes Audit festgestellt. Das sollte die Unabhängigkeit der Ergebnisse gewährleisten, da der Ersteller oft selbst blind für die eigenen Fehler ist. Außerdem waren zur Durchführung von Sicherheitstests oft spezielle Kenntnisse und Werkzeuge von Nöten, die in der Firma nicht in ausreichenden Maßen immer verfügbar waren. Ein Nachteil der externen Sicherheitstests war, dass sie oft nur sporadisch und nicht kontinuierlich durchgeführt werden konnten. Erst wenn das komplette System in einer produktionsnahen Umgebung getestet verfügbar war, konnten die meisten Sicherheitstests stattfinden. Bis dann die Testergebnisse analysiert und umgesetzt wurden, verging noch einmal viel Zeit, so dass entweder das System weiterhin unsicher blieb oder viel Aufwand zur Hebung des Sicherheitsniveaus nötig waren. Ein Konflikt zwischen Dev und Ops war vorprogrammiert, da oft nicht klar war, wer für die Konfiguration gerade der sicherheitsrelevanten Elemente zuständig war.

Ein großer Fortschritt war hier, wenn schon frühzeitig möglichst viele Sicherheitstests durchgeführt werden konnten und die Änderbarkeit der Konfiguration möglichst für jede Umgebung einfach und nachvollziehbar angepasst werden konnte. Neben den statischen Sicherheitstests (SAST) an den äußeren Eingabe-Schnittstellen gehört die Überprüfung der verwendeten Open-Source-Komponenten auf bekannte Schwachstellen zu den einfachen und günstigen Sicherheitsmaßnahmen. Dadurch dass hier Open-Source-Komponenten kontinuierlich auf neuere Versionen aktualisiert wurden, wurden die technischen Schulden minimiert und größere Versionssprünge verloren ihren Schrecken. Selbst wenn bei akuten Zero-Day-Lücken schnell reagiert werden musste, konnte das im normalen Entwicklungsprozess untergebracht werden, ohne dass die Softwarequalität darunter leiden musste.

Die statischen Anwendungs-Sicherheitstests  (SAST) können um weitere Testarten, wie dynamische Anwendungs-Sicherheitstests (DAST), Softwarekomponenten-Schwachstellenanalyse (SCA), interaktive Anwendungs-Sicherheitstests (IAST) und Runtime-Anwendungslaufzeit-Selbstschutz (RASP) ergänzt werden. Vor allem die Softwarekomponenten-Schwachstellenanalyse bringt einen großen Nutzen bei relativ geringem Aufwand, da hier bekannte und bereits behobene Schwachstellen einfach parallel mitgetestet werden können und das Hochsetzen deren Versionsnummern automatisch erfolgen kann.

Viele der bekannten OWASP-Top-10-Schwachstellen lassen sich durch automatisierte Tests finden:

  • A1:2017-Injection,
  • A4:2017-XML External Entities (XXE),
  • A5:2017-Broken Access Control,
  • A6:2017-Security Misconfiguration und
  • A9:2017-Using Components with Known Vulnerabilities.

Andere benötigen oft ergänzende manuelle Tests:

  • A2:2017-Broken Authentication,
  • A3:2017-Sensitive Data Exposure,
  • A7:2017-Cross-Site Scripting (XSS),
  • A8:2017-Insecure Deserialization und
  • A10:2017-Insufficient Logging & Monitoring.

DevSecOps iss keine Tool-Frage

Auch wenn es einige Hersteller so bewerben – DevSecOps ist keine Tool-Frage! Da auch die DevSecOps-Pipeline permanent gepflegt werden muss, ist es wichtig, dass diese Änderungen vorher in einer Testumgebung getestet werden, bevor diese in der produktiven Umgebung verwendet werden. Hier hat eine gemanagte und integrierte DevSecOps-Suite, wie sie von GitHub oder GitLab angeboten wird, Pflegevorteile durch den selbst integrierten und gemanagten Best-of-Breed-Ansatz. Auch wenn viele Teilprodukte als Container-Image zur Verfügung stehen, ist die Pflege und die Integration der vielen Erweiterungen ein nicht zu unterschätzender Aufwand.

Da viele Anwendungen heute cloud-native entwickelt werden, bietet sich an, die von vielen Cloud-Providern angebotenen gemanagten DevOps-Dienste zu verwenden, da diese bereits gut in die typischen Clouddienste des Providers integriert sind. Dem gegenüber steht bei Multi-Cloud-Projekten ein Einarbeitungsaufwand in die unterschiedlichen Produkte. Da GitHub oder GitLab sowohl On-Premise als auch auf Basis der meisten Cloud-Provider zur Verfügung stehen, ist das eine Vereinfachung, wenn überall dieselbe Basis für alle Cloud-Projekte verwendet werden kann.

Aktuelle Auswertungen im jährlich stattfindenden "State of DevOps Report" zeigen eindrücklich, wie Firmen, die schon länger konsequent auf DevSecOps setzen, erhebliche Effizienz- und Qualitätsvorteile gegenüber anderen Marktbegleitern haben. Nicht nur, dass ihre Teams konsequenter schneller und öfters liefern. Sie können auch schneller auf Fehlersituationen reagieren und das echte Feedback unter Live-Bedingungen in die Weiterentwicklung einfließen lassen.

Regeln für erfolgreiche DevSecOps    

Als Regeln für den erfolgreichen Einsatz von DevSecOps-Prinzipien und -Werkzeugen lassen sich zusammenfassen:

  • Beginne mit Sicherheit von Anfang an.
  • Versuche, möglichst viele Sicherheitstest über alle Phasen zu automatisieren.
  • Halte deine DevSecOps-Pipeline einfach, sauber, aktuell und sicher.
  • Überwache deine Software-Komponenten kontinuierlich auf bekannte Schwachstellen.
  • Kenne deine Abhängigkeiten und überprüfe diese regelmäßig.
  • Gieße deine Sicherheitsrichtlinien in automatisiert ausführbare Prüfregeln.
  • Vertraue nur geprüften Quellen, fische nicht in trüben Gewässern!

Fazit

Agile Softwareentwicklung hat sich die letzten Jahre weiterentwickelt. Mit DevSecOps steht der nächste größere Schritt an, um schneller auf Änderungen oder Sicherheitslücken reagieren zu können. Der durch DevSecOps eingeleitete Kulturwandel (Shift Left) ist ein wichtiger Baustein auf dem Weg in die Cloud. Das oberste Ziel bei DevSecOps lautet, Verschwendung zu vermeiden, Fehlerrate reduzieren und die Qualität nachhaltig zu erhöhen, um mehr Geschäftswert zu erzeugen. Nur wer DevSecOps wirklich lebt, kann Cloud-Native-Services kontinuierlich sichern liefern und verbessern.

DevSecOps bedeutet weniger Risiko und mehr Konzentration auf das Wesentliche.

Autor

Frank Pientka

Frank Pientka arbeitet als Principal Software Architect bei der MATERNA SE in Dortmund und sorgt für mehr Qualität in der Software.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben