DevSecOps: Sicherheit in CD-Pipelines

Erfahre, wie sich DevSecOps auf die CD-Pipeline auswirkt und beeinflusst, wie agile Entwicklungsteams mit dem Thema Sicherheit umgehen.

Juni Mukherjee Juni Mukherjee

Was ist DevSecOps?

Mit dem Begriff "DevSecOps" wird ein auf Sicherheit ausgelegter Softwareentwicklungszyklus (Software Development Life Cycle, SDLC) mit Continuous Delivery bezeichnet. DevSecOps beruht auf den allgemeinen Erkenntnissen und Best Practices von DevOps. Werden DevOps-Werte für die Softwaresicherheit herangezogen, wird die Sicherheitsüberprüfung zu einem aktiven, integrierten Bestandteil des Entwicklungsprozesses. Bisher wurde die Sicherheit leider oft als sekundäres System betrachtet. Die Informationssicherheitsbeauftragten wenden sich oft gegen Ende des SDLC an die Entwicklerteams. Auch wenn gute Absichten dahinterstehen, kann es frustrierend sein, wenn Sicherheitslücken erst am Ende des SDLC entdeckt werden.

DevSecOps verwandelt herkömmliche Sicherheitsansätze in aktive Verfahren im SDLC. Mit der Einführung von DevOps traten Verfahren wie Continuous Integration (CI) und Continuous Delivery (CD) auf den Plan. Diese Verfahren ermöglichen aktive Tests und die Überprüfung der Codekorrektheit im Rahmen eines agilen Entwicklungsprozesses. In ähnlicher Weise sorgt DevSecOps dafür, dass Sicherheitsaudits und Penetrationstests Teil der agilen Entwicklung werden. Laut DevSecOps-Grundsatz sollte Sicherheit von Grund auf in Produkte integriert und nicht erst im Nachhinein auf fertige Produkte angewendet werden.

Schlüssel im Schloss | Atlassian CI/CD

Warum DevSecOps?

Kurz gesagt: Sicherheit. Die Sicherheit von Software ist wichtiger denn je, da Technologie in vieler Hinsicht eine Lebensgrundlage geworden ist. Sicherheitsverletzungen gehören heutzutage zu den größten Bedrohungen für Unternehmen und Behörden. Verschiedene große Unternehmen sind in letzter Zeit Opfer von Hackerangriffen geworden, was erhebliche Konsequenzen und Rücktritte in Führungspositionen zur Folge hatte. Gescheiterte Führungskräfte bestimmen die Schlagzeilen und Kunden verlieren nach und nach das Vertrauen in die kompromittierten Serviceanbieter.

DevSecOps-Prinzipien fördern die Zusammenarbeit und verhindern späte Übergaben an Sicherheitsprofis. Die Vorteile werden beim Vergleich der Durchlaufzeiten vor und nach der Umstellung deutlich. Vor der Implementierung von DevSecOps kann es vorkommen, dass dein Produkt in letzter Minute als nicht sicher bewertet wird, was mehrere kostspielige Iterationen nötig macht. Hast du DevSecOps erst einmal implementiert, sind Goldstandards für die Sicherheit von Anfang an in dein Produkt integriert. Die Wahrscheinlichkeit, unerwartete Fehler erst in letzter Minute zu finden, sinkt so deutlich.

Die Frage ist also nicht "Warum DevSecOps?", sondern wie ein erfolgreicherer Betrieb im DevSecOps-Zeitalter aussieht. Für Unternehmen, die noch herkömmliche Sicherheitsverfahren verfolgen, ist DevSecOps hervorragend geeignet, um alte Strukturen aufzubrechen. Die Lösungen hierfür basieren auf deinem Technologie-Stack und deiner Architektur – es gibt keine Universallösung von einer zentralen Organisation.

Der Sicherheitsansatz deines Unternehmens stärkt seine Glaubwürdigkeit auf dem Markt und das Kundenvertrauen. Behalten wir dies im Hinterkopf und schauen wir uns nun an, wie DevSecOps zum Continuous-Everything-Paradigma passt.

DevSecOps und Continuous Everything

Sicherheitsschwachstellen können nicht nur in importierten OSS-Bibliotheken (Open-Source-Software) enthalten sein, sondern auch in unserem selbst geschriebenen Code. Tausende von Entwicklern programmieren jeden Tag, ohne dass die manuellen Codeüberprüfungen damit Schritt halten können. Hier zeigt sich der wahre Vorteil von DevSecOps.

DevSecOps und Continuous Everything sind zwei Seiten einer Medaille. DevSecOps passt perfekt zum Continuous-Everything-Grundsatz und sorgt für Kontinuität bei der Sicherung deiner Softwareprodukte.

Continuous-Delivery-Pipelines sind die praktische Umsetzung des Continuous-Everything-Paradigmas. Sie unterstützen deine Teams dabei, jeden Commit zu prüfen. Dabei ist es sinnvoll, automatisierte Sicherheitsprüfungen in die Pipeline zu integrieren, um frühzeitige Warnmeldungen zu erhalten, und mögliche Sicherheitsschwachstellen unablässig zu überwachen. Integrierte Continuous-Security-Ansätze wachsen mit deinem Unternehmen.

Sowohl Unit-Tests als auch die statische Codeanalyse werden nah am Quellcode durchgeführt und es sind Überprüfungen möglich, ohne den Code auszuführen. Dabei gilt: Fehler verursachen niedrige Kosten in der Testumgebung, mittlere Kosten in der Staging-Umgebung und hohe Kosten in der Produktionsumgebung. Daher solltest du in Unit-Tests und statische Analysen für die Sicherheit investieren. Sie sind günstig und schnell und verhindern spätere Probleme.

Implementieren von Continuous Security: Unit-Tests

Als ersten Schritt zur Implementierung von Continuous Security solltest du Unit-Tests für die Sicherheit einführen.

In den Grundlagen einer Continuous-Delivery-Pipeline haben wir Komponenten als die kleinsten Einheiten definiert, die sich verteilen und testen lassen. Sie können anhand von Unit-Tests überprüft werden. Unit-Tests für die Sicherheit sind ebenso wichtig wie andere Unit-Tests, trotzdem wird diese Kategorie von Teams gern übersehen.

SAST

Neben Verstößen gegen Best Practices für das Programmieren erkennen Tools zur statischen Codeanalyse Sicherheitsschwachstellen in deinem eigenen Code und in (potenziell unsicheren) Bibliotheken, die du importierst. Dies wird als SAST (Static Analysis Security Testing) bezeichnet, und moderne Tools lassen sich gut in die Continuous-Delivery-Pipeline integrieren. Du musst nur darauf achten, dass dein SAST-Scanner zur Programmiersprache deiner Wahl passt.

Aber Achtung: SAST kann oft falsch positive Ergebnisse melden und infolgedessen eine Persistenzebene einplanen, die dafür sorgt, dass sich Pipelines "erinnern". Falsch positive Ergebnisse können Teams frustrieren und dafür sorgen, dass sie nicht mehr auf Benachrichtigungen zu Pipeline-Problemen reagieren – und das kann gefährlich werden. Sobald Teams erkannt und verifiziert haben, dass es sich bei einem Fehler um ein falsch positives Ergebnis handelt, darf die Pipeline den Fehler nicht immer wieder neu melden. Andernfalls könnte die Folge sein, dass Teams SAST deaktivieren oder so einstellen, dass Pipelines SAST-Fehler komplett ignorieren sollen.

DAST

Lose miteinander verbundene Komponenten bilden zusammen ein Subsystem. Diese Subsysteme können bereitgestellt und mithilfe von DAST (Dynamic Analysis Security Testing) auf Sicherheitsschwachstellen geprüft werden. Anders als bei SAST wird bei DAST eine Anwendung von außen im laufenden Betrieb untersucht – so würde auch ein Angreifer vorgehen. DAST-Scanner können unabhängig von konkreten Sprachen arbeiten, weil sie von außen mit der Anwendung interagieren.

Eine Sicherheitsstrategie sollte sowohl SAST als auch DAST umfassen, da beide einzigartige Vorteile bieten. Integriere daher beide Ansätze in deine CD-Pipeline, um früh Feedback zu erhalten.

DevSecOps ist die Zukunft der Sicherheit

Heutzutage muss sich jeder nicht nur um die Qualität, sondern auch um die Sicherheit kümmern. Schränke dein Gesichtsfeld nicht aufgrund der Aussagen einiger selbst ernannter Experten ein. Reaktive Unternehmen und Führungskräfte, die dies in der Vergangenheit taten, mussten mit schwerwiegenden Konsequenzen leben – und überarbeiten nun ihre Sicherheitsstrategie mit einem neuen Budget.

Sicherheitsexperten arbeiteten früher isoliert und ihre Kapazitäten waren davon abhängig, wie viele Sicherheitsmitarbeiter in ihrem Bereich angestellt waren. Du solltest stattdessen einen agilen, dezentralen DevSecOps-Ansatz verfolgen und deine Teams umschulen, damit sie selbst aktiv werden können. Außerdem solltest du deine Produktentwicklungsteams in die Pflicht nehmen, um Streit zwischen den Entwicklern und der InfoSec-Abteilung vorzubeugen.

Sicherheit ist nicht nur eine geschäftliche Priorität – dank der engagierten DevSecOps-Community ist jetzt der perfekte Zeitpunkt gekommen, um Sicherheit in die Continuous-Delivery-Pipeline zu integrieren. Mit der Kombination aus Kontinuität und Sicherheit liegen die goldenen Zeiten der Softwarebereitstellung noch vor uns.