Sieben Tipps zum DevSecOps-Start

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.

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 zum Beispiel 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 zum Beispiel bei der Google Container Registry oder dem Dockerhub (Premium) der Fall.

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:

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:

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.

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.

Natürlich können auch Entwickler nicht immer zu einhundert Prozent richtig liegen. Deswegen brauchen sie die Hilfe anderer. Das Erstellen und Verwalten eines Bug-Bounty-Programms ist 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 Disclsure Richtlinie sagt Benutzern, wen sie im Falle eines Problems kontaktieren können und bittet sie Schwachstellen mitzuteilen, anstatt sie zu missbrauchen oder zu verkaufen.

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 (zum Beispiel Code Reviews).