Sicherheit bei DevOps-ProjektenSieben Quick-Win-Tipps, um schnell mit DevSecOps zu beginnen

Die Möglichkeit, agile Entwicklung und Anwendersicherheit auf die nächste Stufe zu bringen, begeistert Programmierer: Viele Entwicklungsteams haben DevOps bereits in ihren Workflow integriert, um agiler und kundennäher zu arbeiten. Doch das bietet neben vielen Chancen auch ein schwerwiegendes Risiko. Denn das immer schneller werdende Tempo, mit dem Entwicklungsteams neue Funktionen entwickeln, führt häufig zu einem Mangel an Sicherheit innerhalb dieser Webanwendungen.

Durch die Verwendung des DevSecOps-Ansatzes und dem kontinuierlichen Testen der Software von Anfang an können Entwickler sichere Webanwendungen erstellen und Sicherheitsmängel minimieren. Die immer wiederkehrende Verbesserung dieses Prozesses ermöglicht es Entwicklungsteams schließlich eine kontinuierliche Sicherheit für ihre Webanwendungen zu erreichen.

Diese Vorteile überzeugen: Immer mehr Entwickler wollen DevSecOps verwenden und fragen sich, wie sie bei der Integration starten sollen. Die folgenden sechs Quick-Win-Tipps verdeutlichen, wie Unternehmen mit einem DevSecOps-Ansatz möglichst problemlso durchstarten können.

Abhängigkeitsprüfung durchführen

Viele Entwickler verwenden in ihren Anwendungen Bibliotheken. Ihre eigenen Anwendungen mögen sicher sein, aber das hilft nicht wirklich, wenn die verwendeten Abhängigkeiten verwundbar sind.

Deswegen müssen Entwickler auch diese auf Schwachstellen überprüfen. Tools, die dafür geeignet sind, finden sich für verschiedene Programmiersprachen zum Beispiel hier, hier oder hier.

Überprüfung der Docker Container

Docker-Container helfen, den Code so schnell wie möglich bereitstellen zu können. Doch auch hier sollten Entwickler auf die Sicherheit achten. Denn dasselbe, was für ihre Bibliotheken gilt, gilt auch für Docker Basis-Container. Entwickler müssen darauf achten, dass sie nur vertrauenswürdige Basis-Container verwenden – wie z.B. die offiziellen Linux-Distributionen oder Images der verwendeten Programmiersprachen – und sie sollten überprüfen, ob diese bereits Schwachstellen enthalten.

Einige Provider, auf denen die gebauten Container gehostet werden, können diese Überprüfung für die Entwickler durchführen. Dies ist z.B. bei der Google Container Registry oder dem Dockerhub (Premium) der Fall.

Bloß nicht root verwenden

Das Standardkonto in den meisten Docker-Containern ist root. Das sollten Entwickler aus Sicherheitsgründen jedoch nicht verwenden. Stattdessen lohnt es sich, ein normales Benutzerkonto zu erstellen. Das funktioniert mit den folgenden Codezeilen im Dockerfile:

# Nutzeraccount appuser anlegen

RUN adduser –disabled-password –gecos “ appuser

# Zum Nutzeraccount appuser wechseln

USER appuser

Sicherheits-Peer-Reviews durchführen

Unabhängig davon, wie erfahren Entwickler sind, besteht die Chance, dass ihr Code Sicherheitsmängel aufweist. Eine einfache Möglichkeit, den Code auf Sicherheitsprobleme zu überprüfen, ist die Implementierung von Peer Reviews – also die Überprüfung des Codes durch andere Programmierer – in die Entwicklungsprozesse. Peer Reviews sind ein hervorragendes Werkzeug für die Codequalität.

Die Überprüfung durch einen anderen Entwickler können Programmierer nutzen, um sich auf die Sicherheit zu konzentrieren und logische Fehler zu vermeiden, die zu Problemen führen können. Ein weiterer Vorteil: Selbst wenn die Bewertungen ergeben, dass es keine offenen Probleme gibt, können Programmierer kontinuierlich mehr über sichere Programmierung erfahren, indem Sie sich die Arbeit anderer ansehen.

Als Anleitung für die Codeüberprüfungen eignen sich dabei folgende Schritte:

• Code schreiben
• Code an das Repository senden
• Erstellen eines Pull-Requests
• Code von einem Kollegen checken lassen
• Sein Feedback nutzen, um den eigenen Code zu verbessern (das kann solange wiederholt werden, bis beide zufrieden sind)
• Mergen des Pull-Requests und Bereitstellen der Software.

Sich immer die Frage stellen: „Was könnte schief gehen?“

Statt nur auf schnelle Erfolge zu setzen, sollten Entwickler sich immer die Frage stellen „Was könnte schief gehen?“. Ist es eine fehlerhafte Authentifizierung? Ein logischer Fehler? Eine Überlastung des Systems? Denn diese Gedanken während der Implementierung können dafür sorgen, dass die Fehler im fertigen Produkt nicht auftreten.

Auch sogenannte „Evil User Stories“ und „Abuse Cases“ können Entwickler als Ticket Typen im Issue Tracking System zu ihren normalen „User Stories“ oder „Bugs“ hinzuzufügen, um sich die Frage „Was könnte schief gehen“ wirklich immer zu stellen.

Automatisierte Sicherheitstests durchführen

Softwareentwicklung ohne Funktionstests ist kaum vorstellbar. Die Wahrscheinlichkeit ohne Tests alle Funktionen korrekt zu implementieren gleicht Null. Automatisierte Unit- und Integrationstests unterstützen Entwickler hierbei ungemein. Dasselbe gibt es auch für Sicherheitstests. Für automatisierte Sicherheitstests gibt es verschiedene Alternativen:

• Statische Code Analyzer wie zum Beispiel das OpenSource Tool Sonarqube prüfen den Programmcode nicht nur auf Sicherheitsprobleme, sondern auch auf technische Altlasten.
• Dynamische Sicherheitsscanner prüfen die laufende Anwendung auch Sicherheitslücken, indem sie automatisiert einen Angreifer simulieren. Hier gibt es Open Source Tools, wie zum Beispiel OWASP ZAP und kommerzielle Anbieter wie Crashtest Security.

Wichtig dabei ist, dass die Sicherheitsscanner in die CI/CD Build Pipeline integriert werden, um jeden Release automatisch auf Sicherheitslücken zu testen.

Erstellen einer Richtlinie zum verantwortungsvollen Offenlegen von Sicherheitslücken

Natürlich können auch Entwickler nicht immer 100 Prozent richtig liegen. Deswegen brauchen sie die Hilfe anderer. Das Erstellen und Verwalten eines Bug-Bounty-Programms bedeutet eine Menge Arbeit, und zudem gefällt es nicht jedem Programmierer, wenn andere seine Anwendung die ganze Zeit hacken – auch nicht für den guten Zweck. Die Erstellung einer Responsible Vulnerability Disclosure Richtlinie sagt Benutzern, wen sie im Falle eines Problems kontaktieren können und bittet sie Schwachstellen mitzuteilen, anstatt sie zu missbrauchen oder zu verkaufen.

Bonus-Tipp: Die eigene Infrastruktur als Code erstellen

Sieben Tipps sind nicht genug? Ok, dieser Tipp benötigt jedoch etwas mehr Aufwand: Programmierer sollten als zusätzliche Sicherheitsschicht ihre Infrastruktur als Code mit Tools wie terraform erstellen.

Dadurch können sie sichere Basisressourcen wie Serverinstanzen mit einer guten TLS-Konfiguration oder vorkonfigurierte Firewalls erstellen. Entwickler können dafür die gleichen Sicherheitsverfahren wie für ihren Anwendungscode verwenden (z.B. Code Reviews).

Janosch Maier ist Co-Founder von Crashtest-Security.

Crashtest-Security