Die Bedeutung von DevSecOps für Continuous Deployment
Bei DevSecOps geht es darum, den Aspekt der Sicherheit in den Software-Entwicklungszyklus (Software Development Lifecycle, SDLC) einzubeziehen. Durch die Integration von Sicherheit in die Kultur, Prozesse und Tools Ihres Teams wird eine Silo-Mentalität vermieden und sichergestellt, dass eine schnelle Bereitstellung nicht um den Preis von Sicherheitslücken erreicht wird.
DevOps verstehen
Bevor wir uns der Sicherheit zuwenden, wollen wir uns kurz dem Thema DevOps widmen,
einem Begriff, der eng mit dem Konzept der agilen Softwareentwicklung verbunden ist. Bei DevOps geht es darum, eine Kultur der Zusammenarbeit zwischen Softwareentwicklung und Operations zu schaffen, in der alle das gemeinsame Ziel verfolgen, ein wertvolles, funktionierendes Softwareprodukt effizient bereitzustellen. Um dies in die Praxis umzusetzen, setzt sich DevOps für robuste, automatisierte Prozesse ein, um die Bereitstellungszeiten zu verkürzen, schnelles Feedback zu fördern und dadurch einen Kreislauf kontinuierlicher Verbesserungen entstehen zu lassen.
Das klingt soweit überzeugend – aber wie bei jedem neuen Aufbruch sollten wir uns auch bei der Beschleunigung der Software-Bereitstellung die Frage stellen, ob wir nicht etwas Wichtiges vergessen haben. Leider war in der Vergangenheit ganz oft die Sicherheit dieses wichtige Etwas – und genau das möchte DevSecOps verhindern.
DevOps-Sicherheit
Die potenziellen Auswirkungen von Sicherheitslücken in Ihrer Software können gar nicht hoch genug eingeschätzt werden.
Dabei geht es nicht nur um finanzielle Verluste und Reputationsschäden. Durch Software-Sicherheitslücken sind in der Vergangenheit immer wieder enorme Mengen an vertraulichen Informationen in falsche Hände geraten, von internen Dokumenten über unveröffentlichte Produkte bis hin zu Passwörtern und anderen vertraulichen Kundendaten. Je nach Rechtsprechung kann der Verlust von Benutzerdaten schwerwiegende finanzielle Sanktionen und sogar strafrechtliche Folgen nach sich ziehen.
Trotz alledem nehmen viele Entwicklungsteams den Aspekt der Sicherheit eher als Belastung denn als Chance wahr. Sicherheitsaudits und Berichte verlangsamen den Entwicklungsfortschritt und verzögern oft die Auslieferung der neuesten coolen Funktionen. Aber diese Mentalität spielt den bösen Buben in die Hände: Wenn wir die Bedeutung der Sicherheit im Software-Entwicklungszyklus ignorieren, laufen wir Gefahr, der nächsten Wannacry- oder Heartbleed-Katastrophe den Weg zu bereiten.
Diese Exploits schafften es weltweit in die Schlagzeilen – doch ihre Ursprünge waren weitaus banaler. Sicherheitslücken entstehen, weil Programme von Menschen geschrieben werden und Menschen Fehler machen. Manche diese Fehler wurden bereits von anderen gemacht und sind daher leichter zu erkennen (wenn man weiß, wonach man suchen muss). Manche jedoch sind neu – ermöglicht zum Beispiel durch eine Kombination von Faktoren, die zuvor noch nie auf diese Weise zusammengetroffen sind.
Erhöht wird die Komplexität dadurch, dass fast jede Software Abhängigkeiten enthält. Unabhängig davon, ob es sich bei diesen Abhängigkeiten um Open-Source- oder proprietäre Software handelt, gibt es keine Garantie dafür, dass Fremdcode frei von Sicherheitslücken ist.
Wie kann also die Sicherheit in den Software-Entwicklungszyklus integriert werden? Der DevSecOps-Ansatz besteht darin, die Prinzipien, die schnellere und stabilere Releases ermöglicht haben – Zusammenarbeit, gemeinsame Verantwortung und weitestmögliche Automatisierung – auch auf Sicherheitsmethoden anzuwenden.
Linksshift für die Sicherheit
Die Wasserfall-Entwicklungsmethode folgt einer linearen Logik, beginnend mit der Erfassung der Anforderungen, gefolgt von Design-, Build-, Integrations- und Testphasen sowie – als krönenden Abschluss, normalerweise Monate oder Jahre nach Projektstart – dem Release.
Die Testphase bestand in der Regel aus langwierigen manuellen Prozessen für Qualitätssicherung, Sicherheitsprüfung und Abnahmetests. In einem Vorgang, der spöttisch als „über die Mauer werfen“ bezeichnet wird, wurde das Produkt von einer Funktion an die nächste übergeben, wobei jedes Team einen ausführlichen Bericht verfasste.
Eine dieser Phasen unterstand dem Team für Informationssicherheit (Infosec), das einen Sicherheitsbericht mit einer detaillierten Liste von Ergebnissen und Empfehlungen erstellte. Diese erforderten häufig Codeänderungen, nach denen die Software erneut dieselben Phasen durchlief, um festzustellen, ob alles ordnungsgemäß umgesetzt wurde. Kein Wunder, dass nach einem solch langwierigen Prozess jedes Release ein Grund zum Feiern war!
Die agile Softwareentwicklung, die DevOps-Bewegung und das Aufkommen des Cloud Computing haben jedoch eine neue Ära eingeläutet. Der Wettbewerb ist hart und die Geschwindigkeit entscheidend. Wenn wir nicht auf die Bedürfnisse unserer Benutzer*innen eingehen und Fehler umgehend beheben, werden sie bald einen anderen Anbieter finden, der dies tut. Die regelmäßige Bereitstellung von Mehrwert und die schnelle Umsetzung von Fehlerkorrekturen sind für viele Unternehmen zur Norm geworden, und die CI/CD-Pipeline spielt dabei eine tragende Rolle.
Obwohl der Begriff DevSecOps möglicherweise etwas anderes impliziert, war DevOps niemals auf den Ausschluss der Sicherheit hin konzipiert.
Leider sah die Realität jedoch oft so aus, dass die Infosec-Teams auch dann noch in ihren Silos isoliert blieben, als die Grenzen zwischen Entwicklungs- und Operations-Teams eingerissen wurden. Um diesem Missstand abzuhelfen, wurde das DevSecOps-Konzept – zusammen mit Alternativbegriffen wie SecDevOps, DevOpsSec und Rugged DevOps – aus der Taufe gehoben.
DevSecOps legt Wert darauf, die Sicherheit von Anfang an zu integrieren, erweitert die Kultur des gemeinsamen Kümmerns und der gemeinsamen Verantwortung auf Sicherheitsaspekte und integriert Sicherheitstests in das automatisierte Testsystem einer CI/CD-Pipeline. Wie beim Thema Operations geht es um die Idee, dass durch einen Linksshift der Sicherheit die Anforderungen und Best Practices in Bezug auf die Sicherheit einfacher berücksichtigt werden können, als wenn sie erst nach der Fertigstellung des Produkts nachgerüstet werden.
So kommt das Sec in DevSecOps: Sicherheit als Code
Für Uneingeweihte liegt der Gedanke nah, dass für einen Linksshift der Sicherheit nichts weiter erforderlich ist, als in der CI/CD-Pipeline eine neue Phase einzurichten, in der das Sicherheitsteam die Software nach Belieben testen kann.
Wie wir weiter unten sehen werden, haben manuelle Sicherheitstests zwar ihre Berechtigung. Aber wenn sich die Beschäftigung mit den Sicherheitsanforderungen auf einen einzigen Schritt am Ende der Pipeline beschränkt, ist das kaum anders, als wenn Sie die Software „über die Mauer werfen“ und warten, bis ein Bericht zurückkommt.
Das wahrscheinliche Ergebnis ist, dass entweder Empfehlungen ignoriert werden, weil ihre Umsetzung zu lange dauert, oder der gesamte Prozess jäh unterbrochen und das Release auf unbestimmte Zeit verschoben wird, um Probleme beheben und Risiken bewerten zu können. In beiden Fällen entsteht eine „Wir-gegen-sie“-Mentalität zwischen dem Sicherheitsteam und dem Rest des Unternehmens, und diese bringt keine Seite näher an das Ziel, nützliche, sichere Software zu veröffentlichen.
Aber was bedeutet dann die Linksshift-Methode für die Praxis? Es gibt zwar keine Patentlösung, die in jeder Situation hilft, aber die folgenden Tools und Techniken können dazu beitragen, die Sicherheit in den gesamten Software-Entwicklungszyklus zu integrieren.
Sicherheitschampions ernennen
Eine Kultur der gemeinsamen Verantwortung ist zwar wichtig, aber es genügt nicht, Ihrem Entwicklungsteam zu sagen, dass sie ab sofort gemeinschaftlich für die Softwaresicherheit verantwortlich sind. Mit den neuesten Entwicklungen bei Angriffsmethoden und Malware Schritt zu halten ist ein Vollzeitjob, und Sie können nicht erwarten, dass jeder das gleiche Maß an Fachwissen zu diesem Thema erwirbt. Wenn Sie hingegen einen Sicherheitschampion in ein multidisziplinäres Team holen, der die anderen Teammitglieder coacht und Best Practices weitergibt, können Sie das Verständnis für Sicherheit stärken und eine Kultur der Zusammenarbeit mit den Sicherheitsexperten fördern.
Sicherheit als Designkriterium definieren
Damit das Entwicklungsteam gemeinsam die Verantwortung für die Sicherheit der erstellten Software übernehmen kann, müssen Sicherheitsaspekte noch vor dem Schreiben des Codes berücksichtigt werden. Sie sollten in User Stories eingebunden, in Backlog-Review-Meetings thematisiert und bei der Planung jedes Sprints angesprochen werden. Nehmen Sie sich bei der Planung eines neuen Features die Zeit, das damit verbundene Risikopotenzial zu erörtern und zu minimieren.
Eine Strategie zur Bedrohungsmodellierung wie STRIDE oder ein Tool wie das OWASP-Cheatsheet können helfen, sich beim Einarbeiten in dieses neue Gebiet nicht zu verzetteln. Durch die Berücksichtigung der Sicherheit in der Designphase werden zwar nicht gleich alle Probleme beseitigt, aber es ist ein guter Start, der zur Förderung einer DevSecOps-Kultur beiträgt.
Pipeline um automatisierte Sicherheitstests erweitern
Die Automatisierung ist ein zentrales DevOps-Prinzip. Dadurch wird nicht nur die Ausführung von Aufgaben beschleunigt und vereinheitlicht, sondern auch dem Team die Möglichkeit gegeben, sich kreativer zu betätigen. Wenn Sie Ihre Software regelmäßig und häufig bereitstellen möchten, sollten Sie Ihrer Pipeline unbedingt automatisierte Sicherheitstests hinzufügen.
Beim Schreiben automatisierter Unit-, Integrations- und End-to-End-Tests sollten Sicherheitsmerkmale die gleiche Relevanz haben wie alle anderen Funktionen. Wenn Ihr Team Sicherheitsanforderungen bereits in User Stories integriert und Bedrohungsmodelle im Rahmen des Designprozesses besprochen hat, sind Tests zum Abdecken der Sicherheitsfunktionen eine natürliche Fortsetzung dieser Arbeit.
Kompetente Unterstützung einholen
Zusätzlich zu selbst geschriebenen Tests können Sie verschiedene Sicherheitstest-Tools nutzen, um das Vertrauen in die Qualität Ihres Codes zu stärken. Herkömmliche Sicherheitsscan-Tools waren zwar für den Einsatz in automatisierten CI/CD-Pipelines nicht gut geeignet, aber inzwischen sind CI/CD-Sicherheitstest-Tools verfügbar, die mit Blick auf die Automatisierung entwickelt wurden und sich in die Pipeline integrieren lassen. Die Ergebnisse werden auf dem Dashboard angezeigt oder direkt in die Bug-Tracking-Tools eingespeist. Wie bei allen automatisierten Tests sollte durch entsprechende Strukturierung für ein möglichst schnelles Feedback gesorgt werden.
Tools für statische Anwendungssicherheitstests (Static Application Security Testing, SAST) prüfen den Quellcode mittels statischer Codeanalysen auf bekannte Sicherheitslücken wie Pufferüberläufe und SQL-Injection-Gefahren. Da die statische Analyse auf den Quellcode angewendet wird, kann sie an einem sehr frühen Punkt der CI/CD-Pipeline – direkt nach einem Commit – erfolgen.
SAST-Tools sind sprachspezifisch und zum Teil in die IDE integriert, um beim Schreiben kontinuierliches Feedback zu geben oder Tests bei Bedarf auszuführen. Indem sie auf die konkrete Codezeile hinweisen, in der das Sicherheitsproblem gefunden wurde, bieten die SAST-Tools gezielte Unterstützung, die das Beheben von Problemen beschleunigt. Fehlalarme können jedoch ein Problem darstellen, und es ist wichtig, einzelne Warnungen stummschalten oder verwerfen zu können, da ansonsten die Gefahr besteht, dass alle SAST-Ergebnisse im Grundrauschen untergehen.
Das Gegenstück zu SAST ist DAST – das dynamische Testen der Anwendungssicherheit. Dabei wird die ausgeführte Anwendung als „Blackbox“ betrachtet und auf bekannte Schwachstellen überprüft – etwa Cross-Site-Scripting, Befehls- und SQL-Injection und unsichere Serverkonfigurationen. Da für die Anwendung von DAST-Tools ein Build der Anwendung erstellt und in einer Testumgebung bereitgestellt werden muss, erfolgt ihr Einsatz normalerweise erst später in der CI/CD-Pipeline.
Abhängigkeiten prüfen
Die Software-Komponentenanalyse (software composition/component analysis, SCA) ist eine weitere Art von automatisierten Sicherheitstests, die frühzeitig ausgeführt werden können. Wie bereits erwähnt enthält praktisch jede Software Open-Source-Bibliotheken und andere Fremdkomponenten, die Schwachstellen einschleusen können.
SCA-Tools sollten nicht nur die Abhängigkeiten prüfen, die Sie unmittelbar eingefügt haben, sondern in rekursiver Weise auch deren Abhängigkeiten – ein perfektes Beispiel für eine Aufgabe, die am besten Computern überlassen wird, insbesondere wenn wir bedenken, wie oft neue Abhängigkeiten zu einem Projekt hinzugefügt werden.
Neben der automatisierten Ausführung in der CI/CD-Pipeline sind einige SCA-Tools auch als IDE-Plugins verfügbar, um kontinuierliches Feedback geben zu können. Wie bei statischen und dynamischen Sicherheitstests sind auch SCA-Tests auf Schwachstellen begrenzt, die den Tools bekannt sind. Daher sollten Sie sicherstellen, dass Ihre Tools regelmäßig mit Daten zu neuen Exploits aktualisiert werden und die Bereiche abdecken, die für Ihr Produkt und Ihre Organisation am relevantesten sind. Wenn es jedoch darum geht, neue und unerwartete Exploits zu finden, ist menschliche Kreativität gefragt.
Das rote Team einsetzen
Das Konzept eines „roten Teams“ geht auf Kriegssimulationen zurück, in denen Mitglieder der eigenen Seite bei einem simulierten Angriff die Rolle des Feindes übernehmen, um Schwachstellen in der eigenen Verteidigung und Strategie zu identifizieren. Der gleiche Ansatz wird auch in der Softwareentwicklung mit großer Wirkung eingesetzt – etwa bei Penetrationstests oder „ethischem“ Hacking.
Damit ein rotes Team effektiv eingesetzt werden kann, darf es nicht an der Entwicklung des getesteten Systems teilgenommen haben. Wie beim explorativen Testen muss das rote Team unkonventionell denken und die Software anders als beabsichtigt verwenden.
Rote Teams können entweder in einer Staging-Umgebung (die möglichst weitgehend mit der Produktionsumgebung übereinstimmen sollte) oder „live“ in einem Produktivsystem eingesetzt werden. Wenn Sie sich für die letztere Option entscheiden, benötigen Sie allerdings entweder ein hohes Maß an Vertrauen in die Fehlermodi Ihres Produkts – oder eine hohe Toleranz seitens der Benutzergemeinde (und der Geschäftsführung).
Alle Schwachstellen als Fehler behandeln
Bei einem DevSecOps-Ansatz teilen sich alle die Verantwortung für die Sicherheit der Software. Daher ist es an der Zeit, Sicherheitsprobleme nicht mehr separat von „regulären“ Bugs zu betrachten. Alle sicherheitsbezogenen Fehler oder Schwachstellen, die in Ihrem System aufgedeckt werden, gehören in dasselbe Backlog wie alle anderen Probleme und sollten gemeinsam mit diesen priorisiert werden.
Die Verantwortung für die Behebung liegt beim gesamten Team und nicht etwa allein beim Sicherheitschampion. Durch diesen Ansatz werden Wissen und Know-how aufgebaut, die das Team auch in das nächste Projekt einbringen kann.
Produktiveinsatz beobachten
Trotz aller Bemühungen in den vorangegangenen Phasen des Software-Entwicklungszyklus besteht auch beim Live-System das Risiko, dass Hacker eine Schwachstelle finden. Es lohnt sich daher weiterhin, in Firewalls und Überwachungstools zu investieren, um sowohl Ihr Unternehmen als auch Ihre Benutzer*innen zu schützen. Eine neue Variante dieser Abwehrmechanismen sind RASP-Tools (Runtime Application Self Protection), die verdächtiges Verhalten automatisch erkennen und blockieren.
Fazit
Bei der Sicherheit einen Linksshift vorzunehmen bedeutet, die Sicherheit bei jeder Phase des Software-Entwicklungszyklus in die Hände des gesamten Teams zu legen. Wenn Sie DevOps-Methoden einsetzen, wird dieser Zyklus häufig wiederholt, sodass Sie und Ihr Team regelmäßig Feedback zum Verhalten und zur Verwendung Ihrer Software in der realen Welt erhalten. Durch die Integration der Sicherheit in Ihre CI/CD-Pipeline erhalten Sie regelmäßige Rückmeldungen zur Sicherheit Ihrer Anwendung, sodass Sie sie auf die gleiche Weise wie die restliche Anwendungsfunktionalität verbessern können.
Indem Sie Ihre Software auf bekannte Schwachstellen überprüfen und vor diesen schützen, stellen Sie zumindest sicher, dass Ihre Software mit den Angreifern Schritt hält, statt bekannten Exploits ungeschützt ausgeliefert zu sein. Wenn Sie jede neue Sicherheitslücke als Bug behandeln, sodass nach der Triage und Fehlerbehebung die Software in Zukunft stets auf das erneute Auftreten dieses Problems getestet wird, wird Ihre Software im Laufe der Zeit immer robuster.
Bei DevOps – und damit auch bei DevSecOps – ist die Kultur genauso wichtig wie die Tools und Prozesse, die eine schnelle und häufige Bereitstellung Ihrer Software ermöglichen. Ohne die Menschen kämen wir schließlich auch mit DevOps nicht sehr weit. Wenn Sie die Sicherheit in Ihren Software-Entwicklungszyklus integrieren möchten, ist es entscheidend, eine Kultur der gemeinsamen Verantwortung zu fördern statt gezielt nach einem Schuldigen zu suchen. Jeder sollte Sicherheitsbedenken äußern und darauf vertrauen können, dass er angehört wird – sei es während der Sprintplanung, bei Code-Reviews, beim manuellen Testen oder bei der Arbeit am Live-System. Gleichzeitig hat jeder die Verantwortung, die Bedeutung der Sicherheit zu erkennen und zu ihr beizutragen.