Quick-Win-Tipps, um schnell mit DevSecOps zu beginnen

Das Schlagwort DevSecOps ist derzeit in aller Munde. 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.

Anzeige

Janosch Maier, Co-Founder von Crashtest-Security hat 6 Quick-Win-Tipps zusammengestellt, um mit DevSecOps durchzustarten.

1. 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.

2. Ü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.

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.

3. 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

4. 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

5. 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.

6. 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.

7. 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 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.

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).

Maier Janosch

Crashtest-Security -

Co-Founder

Anzeige

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.