Kontinuierliche Sicherheit in DevSecOps

Was ist kontinuierliches Sicherheitsmonitoring?

Kontinuierliches Sicherheitsmonitoring ist die natürliche Weiterentwicklung der Sicherheit. Die moderne Softwareentwicklung bewegt sich in Richtung eines Modells, bei dem alles kontinuierlich abläuft – von der Integration bis zur Bereitstellung und zum Deployment. Herkömmliche Sicherheitsansätze konzentrieren sich darauf, Software-Releases nach der Produktion zu testen. Das führt jedoch zu Engpässen in der Entwicklung und kann dazu führen, dass Schwachstellen in die Produktion gelangen. Kontinuierliche Sicherheit integriert stattdessen Sicherheitsmaßnahmen in den Entwicklungsprozess. So werden Risiken reduziert und Engpässe beseitigt, damit Releases schneller bereitgestellt werden können.

Welche Vorteile bietet kontinuierliche Sicherheit?

Die moderne Softwareentwicklung ist durch komplexe Architekturen und Infrastrukturschichten geprägt. Ansätze wie Cloud-native Anwendungen, Microservices und Containerisierung ermöglichen es Entwicklerinnen und Entwicklern, Code schneller zu testen und bereitzustellen. Releases sind in der Regel klein und schnell. In Produktionsumgebungen kann es täglich mehrere Deployments geben.

DevOps-Sicherheit erfordert einen neuen Ansatz, um mit der rapide zunehmenden Veränderungsgeschwindigkeit von Software Schritt zu halten. Herkömmliche Sicherheitsmethoden testeten Software erst am Ende des Entwicklungszyklus oder nach dem Deployment in die Produktion. Häufig waren externe Teams für die Tests zuständig, was zu Reibungsverlusten zwischen Entwicklung und Sicherheit führte.

Darüber hinaus eignen sich herkömmliche Sicherheitsansätze nicht gut für moderne Softwarearchitekturen und Infrastrukturen. Cloud-Infrastruktur lässt sich innerhalb weniger Minuten bereitstellen. Die Architektur ist nicht klar definiert. Das ist für moderne Entwicklerinnen und Entwickler attraktiv, vergrößert aber die Angriffsfläche und erschwert deren Absicherung. Herkömmliche Sicherheitsansätze sind für Tests in solchen Umgebungen nicht gut gerüstet.

Kontinuierliche Sicherheit ist eine natürliche Erweiterung von DevOps-Praktiken und integriert Sicherheit in die CI/CD-Pipeline. Sie steht in engem Zusammenhang mit dem Konzept DevSecOps und dem Shift-Left-Ansatz für Sicherheit. Entwicklungsteams übernehmen Verantwortung für die Sicherheit des Codes, damit Probleme so früh wie möglich im Entwicklungsprozess erkannt und behoben werden. So beschleunigt kontinuierliche Sicherheit die Bereitstellung von Funktionen und automatisiert zugleich Sicherheitsanforderungen – für bessere Governance und mehr Sicherheit.

Wie lässt sich kontinuierliche Sicherheit in CI/CD-Pipelines integrieren?

Kontinuierliche Sicherheit integriert Richtlinien und Tests direkt in die CI/CD-Pipeline und schützt Infrastruktur und Anwendungen in jeder Phase des Softwareentwicklungszyklus:

Threat Modeling

Threat Modeling findet idealerweise in den frühesten Phasen des SDLC statt. Dabei modellieren Entwicklerinnen und Entwickler, welche Änderungen sich aus der Ausführung von Code ergeben würden, ohne den Code tatsächlich auszuführen. So erhalten sie nahezu sofortiges Feedback und können die Auswirkungen des Codes auf die Sicherheit testen.

Threat Modeling kann schnell komplex werden. Ein Ansatz dafür ist STRIDE. Er umfasst jeweils eine eigene Analyse der häufigsten Angriffsarten:

• Spoofing (Identitätsfälschung)

• Tampering (Manipulation)

• Repudiation (Abstreitbarkeit)

• Information disclosure (Offenlegung von Informationen)

• Denial of service (Dienstverweigerung)

• Elevation of privilege (Rechteausweitung)

Methoden wie STRIDE helfen Ihnen zu bewerten, was Sie entwickeln, was schiefgehen könnte, wie Sie Risiken mindern und wie Sie Ihren Prozess zur Bedrohungsabwehr bewerten können.

Threat Modeling muss außerdem so geplant werden, dass es gut zur DevSecOps-Kultur passt. Traditionell gab es dafür zahlreiche frühe Treffen zwischen Entwicklungsteams und Sicherheitsexpertinnen und -experten. Kontinuierliche Sicherheit verfolgt beim Threat Modeling einen Shift-Left-Ansatz: Es wird früher in den Entwicklungsprozess verlagert. Gleichzeitig kommt bei Tools von Drittanbietern ein „Extend-Right“-Ansatz zum Einsatz, um Bedrohungen auch in späteren Phasen der Pipeline automatisch zu erkennen und zu mindern.

Code- und Design-Reviews

Sobald der Code geschrieben ist, sollte er überprüft werden, um sicherzustellen, dass er wie vorgesehen funktioniert und keine Schwachstellen oder Sicherheitsprobleme enthält. Dazu gehören die Bereinigung und Validierung aller Eingaben mit einer geprüften Bibliothek, die Durchsetzung sicherer Authentifizierung sowie das Scannen auf Schwachstellen in Software-Abhängigkeiten und zahlreiche weitere Sicherheitsprüfungen.

Weitere Best Practices finden Sie in diesem von uns erstellten Spickzettel für Code-Reviews.

Tests

Sobald der Code im Hinblick auf Sicherheit und Design geprüft wurde, ist es Zeit, ihn zu testen. In dieser Phase erstellen Entwicklerinnen und Entwickler eine produktionsähnliche Sandbox und testen den Code unter diesen Bedingungen. Dazu gehören automatisierte Tests von Netzwerkaufrufen, Eingabevalidierung, Autorisierung, Protokollen und Zugriffskontrollen. Protokolliert die Anwendung Sicherheitsmetriken korrekt? Ist der Zugriff auf den richtigen Personenkreis beschränkt?

Kontinuierliche Sicherheitstests ermöglichen auf diese Weise schnelles Feedback. Dazu kann auch die Bereitstellung und das Testen von Infrastrukturressourcen gehören. In einer auf AWS bereitgestellten Testumgebung kann beispielsweise ein Tool namens Managed Config Rules sicherstellen, dass Cloud-Ressourcen die Best Practices für Sicherheitskonfigurationen einhalten.

Produktion

Mit dem Deployment in die Produktion endet der Weg des Codes – nicht aber die Arbeit an der Sicherheit. Ressourcen können geändert, hinzugefügt oder entfernt werden. Deshalb müssen Anwendungen in der Produktion kontinuierlich auf die Einhaltung von Unternehmens-, Branchen- oder behördlichen Standards getestet werden. Zur Produktionssicherheit können automatisiertes Patchen, Konfigurationsmanagement und die automatische Aktualisierung von Abhängigkeiten gehören.

Sehen wir uns einige Best Practices an, mit denen Sie ein wirksames Programm für kontinuierliche Sicherheit aufbauen können.

Welche Best Practices sollten Sie bei einem Prozess für kontinuierliche Sicherheit befolgen?

Kontinuierliche Sicherheit erfordert Planung

Es reicht nicht, dem DevOps-Team Sicherheitsziele zu übergeben und zu erwarten, dass es die entsprechenden Verfahren umsetzt und durchsetzt. Die Verantwortung für Integrationen sollte nicht allein bei den Entwicklungsteams liegen. Sicherheitsteams sollten darauf achten, kontinuierliche Sicherheit mit möglichst wenig Unterbrechungen einzuführen – angefangen bei der Planungsphase. Sicherheits- und DevOps-Teams sollten von Anfang an gemeinsam Funktionen und Audits einbeziehen und während des gesamten Prozesses zusammenarbeiten.

Die Planung beginnt mit Threat Modeling, sobald ein System, eine Anwendung oder eine User Story konzipiert wird. Anwendungssicherheitstests sollten bei Codeänderungen und nach der Integration automatisch ausgeführt werden. Mögliche Probleme sollten zur Überprüfung markiert und die Ergebnisse Entwicklerinnen und Entwicklern direkt in ihren gewohnten Entwicklungstools angezeigt werden.

Der Prozess sollte so weit wie möglich automatisiert werden. Ein Deployment sollte beispielsweise von Sicherheitsmetriken und der Laufzeitsicherheit abhängig sein.

Infrastruktur erfordert besondere Aufmerksamkeit

Die Flexibilität von Cloud-Infrastrukturen macht geeignete Richtlinien und deren konsequente Durchsetzung notwendig. Dazu kann gehören, nicht benötigte Dienste zu deaktivieren, unnötige Ports zu schließen, Berechtigungen durchzusetzen und sicherzustellen, dass in der Produktionsumgebung keine Entwicklungstools installiert sind.

Code muss auf sicheren Betriebssystemen und mit aktuellen App-Versionen erstellt werden. Auch Sicherheitskontrollen für Clustergrößen, Berechtigungen für gemeinsam genutzte Infrastruktur sowie Infrastruktur- oder Plattformpartner müssen durchgesetzt werden.

Regelmäßige Tests durchführen (Penetrationstests, Bug-Bounty-Programme)

Tests sind unverzichtbar. Sie stellen sicher, dass der Code vor der Veröffentlichung sowohl funktionsfähig als auch sicher ist. Tests lassen sich außerdem automatisieren, um Verzögerungen durch manuelle Prüfungen zu vermeiden. Sie können Angriffsvektoren aufdecken, potenzielle Sicherheitsschwachstellen identifizieren und nach ihrem möglichen Ausmaß einordnen.

Diese Tests sollten auch auf Infrastruktur, Netzwerke und alle anderen Bereiche angewendet werden, die als Code abgebildet sind. Ziel ist es, sämtliche Komponenten einer Anwendung zu analysieren und sicherzustellen, dass der gesamte Technologie-Stack angemessen geschützt ist.

Tools einsetzen, die Sicherheit fördern, ohne die Entwicklung zu beeinträchtigen

Moderne Tools erleichtern es Entwicklerinnen und Entwicklern, die Sicherheit direkt in die CI/CD-Pipeline zu integrieren. Tools für statische Anwendungssicherheitstests (SAST) können während der Softwareentwicklung eingesetzt werden, um Probleme und Schwachstellen in aktualisiertem Code zu finden. So können SAST-Tools beispielsweise erkennen, ob eine Benutzereingabe eine datenbankbezogene Funktion auslösen und dadurch eine Sicherheitsschwachstelle verursachen könnte – eine sogenannte SQL-Injection.

Traditionell wurden SAST-Tools als separater CI-Prozess eingesetzt. Moderne SAST-Tools können dagegen bereits während der Erstellung des Quellcodes schnelle, umsetzbare Rückmeldungen geben. Sie weisen nur wenige falsch-positive Ergebnisse auf und liefern außerdem Hinweise zur Behebung. Die Tools sind auf Entwicklerinnen und Entwickler ausgerichtet und lassen sich in IDE, CLI und andere bereits genutzte Tools integrieren.

Tools für die Software Composition Analysis (SCA) sind eine weitere wertvolle Technologie für kontinuierliche Sicherheit. Damit können Entwicklerinnen und Entwickler Änderungen am Quellcode vor dem Zusammenführen auf Schwachstellen in Abhängigkeiten prüfen.

Policy Engines und Lint-ähnliche Tools sind zwei weitere Tooltypen, die bei jeder Codebereitstellung durch Entwicklerinnen und Entwickler ausgeführt werden können. Tools zur Verwaltung von Secrets wie Vault tragen zusätzlich dazu bei, Code in Cloud-Infrastrukturen und Anwendungen zu schützen.

Snyk-Tools für kontinuierliche Sicherheit

Es gibt zahlreiche Tools, um Schwachstellen während des gesamten Entwicklungszyklus zu finden und zu beheben. Snyk zeichnet sich durch den Fokus auf Entwicklerinnen und Entwickler sowie seine erstklassige Sicherheitsplattform aus.

Abhängigkeiten aktuell zu halten, ist für Entwicklerinnen und Entwickler oft eine Hürde. Woher wissen Sie, wann ein Update nötig ist? Sind die Änderungen sinnvoll? Führen sie zu Fehlern oder verhindern sie die Kompilierung? Kontinuierliche Updates für Abhängigkeiten mit häufigeren, kleineren Änderungen machen das Problem leichter beherrschbar. Entwicklerinnen und Entwickler können Tools nutzen, um Updates automatisch freizugeben und zusammenzuführen, sofern die Tests bestanden werden. Das führt letztlich zu kürzeren Deployment-Zeiten und vollständiger Automatisierung vom Pull Request bis zur Produktion.

Open-Source-Abhängigkeiten sind ein Bereich, der besondere Aufmerksamkeit erfordert. Snyk Open Source testet den Code automatisch in der CI/CD-Pipeline, um Schwachstellen zu erkennen und zu beheben, bevor sie in die Produktion gelangen. Sobald Code in Produktion ist, überwacht Snyk ihn auf neu entdeckte Schwachstellen – mithilfe einer proprietären Schwachstellendatenbank.

Kurz gesagt: Code-Scans sind eine zentrale Voraussetzung für kontinuierliche Sicherheit. Wenn Sie nicht scannen, welche Schwachstellen oder Fehler könnten dann unentdeckt bleiben?