Sicherer SDLC, SAST- und DAST-Tools

Der Secure Software Development Lifecycle (SSDLC) integriert Sicherheitsaktivitäten in jede Phase der Softwareentwicklung – von den Anforderungen über Entwurf, Programmierung, Tests und Bereitstellung bis hin zur Wartung. Beim herkömmlichen SDLC wird Sicherheit als Prüfung in der letzten Phase behandelt, was teuer und ineffektiv ist. Die Philosophie des sicheren SDLC besteht darin, Schwachstellen so früh wie möglich zu finden und zu beheben, da während des Entwurfs entdeckte Fehler wesentlich kostengünstiger behoben werden können als Fehler, die erst in der Produktion gefunden werden.

Shift left bedeutet, Sicherheit in eine frühere Phase zu verlagern (auf der Entwicklungszeitleiste nach links), statt sie erst am Ende nachträglich hinzuzufügen. In der Praxis bedeutet dies, Sicherheitsanforderungen in User Stories aufzunehmen, während des Entwurfs eine Bedrohungsmodellierung durchzuführen, während der Entwicklung Code-Reviews und SAST auszuführen und vor der Veröffentlichung DAST durchzuführen. Teams, die Sicherheit nach links verlagern, entdecken Schwachstellen zu dem Zeitpunkt, an dem sie am kostengünstigsten behoben werden können – während der Entwicklung und nicht in der Produktion.

Bedrohungsmodellierung identifiziert und dokumentiert Sicherheitsbedrohungen während der Entwurfsphase systematisch. Das Modell STRIDE kategorisiert Bedrohungen in: Spoofing, Manipulation, Abstreitbarkeit, Offenlegung von Informationen, Denial of Service und Rechteausweitung. PASTA (Process for Attack Simulation and Threat Analysis) ist eine risikozentrierte Methodik, die die Ziele von Angreifern simuliert. Bedrohungsmodelle liefern priorisierte Gegenmaßnahmen, bevor eine einzige Codezeile geschrieben wurde.

SAST (White-Box-Tests) analysiert Quellcode, Bytecode oder Binärdateien, ohne die Anwendung auszuführen, und sucht nach Codemustern, die mit bekannten Schwachstellen verbunden sind. SAST-Tools können die gesamte Codebasis schnell überprüfen und Probleme wie fest codierte Zugangsdaten, SQL-Injection-Sinks und unsichere Deserialisierung melden. Sie werden innerhalb der IDE oder der CI-Pipeline ausgeführt und melden Fundstellen mit Datei- und Zeilennummern, wodurch die Behebung unkompliziert wird.

Eine wichtige Einschränkung von SAST ist die Tendenz zu Fehlalarmen – Code wird als anfällig markiert, obwohl er tatsächlich sicher ist. Diese Alarmmüdigkeit führt dazu, dass Entwickler Fundstellen verwerfen, ohne sie zu untersuchen. SAST-Tools können außerdem keine Laufzeitkonfigurationsprobleme, von Laufzeitverhalten abhängige Authentifizierungsfehler oder Schwachstellen in Aufrufen von APIs Dritter erkennen. SAST ist am effektivsten, wenn es mit einer Schulung der Entwickler kombiniert wird, damit Fundstellen korrekt bewertet und priorisiert werden.

DAST (Black-Box-Tests) testet eine laufende Anwendung, indem Angriffspayloads an deren HTTP-Endpunkte gesendet und die Antworten auf Hinweise auf Schwachstellen analysiert werden. DAST erfordert keinen Zugriff auf den Quellcode – die Anwendung wird so getestet, wie es ein Angreifer tun würde. DAST eignet sich besonders gut zum Auffinden von Laufzeitproblemen wie der Umgehung der Authentifizierung, in Antworten reflektiertem XSS und einer fehlerhaften Serverkonfiguration. Zu den DAST-Tools gehören OWASP ZAP, Burp Suite und Netsparker.

SAST und DAST ergänzen einander, anstatt miteinander zu konkurrieren. SAST findet Probleme auf Codeebene frühzeitig und lässt sich in die IDE integrieren, hat jedoch keinen Einblick in das Laufzeitverhalten. DAST findet Laufzeitschwachstellen und benötigt keinen Quellcode, kann jedoch keine Codepfade überprüfen, die von seinen automatisierten Prüfungen nicht ausgelöst werden. Durch die gemeinsame Verwendung – SAST in der CI-Pipeline und DAST in einer Staging-Umgebung – wird die Abdeckung von Schwachstellen im gesamten SDLC maximiert.

IAST kombiniert Aspekte von SAST und DAST, indem die Anwendung zur Laufzeit instrumentiert wird. Ein IAST-Agent läuft innerhalb der Anwendung (auf dem Server) und beobachtet die Codeausführung, während Testdaten durch die Anwendung fließen. Er kann manipulierte Benutzereingaben über Codepfade bis zu sensiblen Senken verfolgen und so Schwachstellen mit einer geringeren Fehlalarmrate als reines SAST finden. IAST ist besonders effektiv in Java- und .NET-Anwendungen und lässt sich auf natürliche Weise in funktionale Testläufe integrieren.

Software Composition Analysis (SCA) identifiziert Open-Source-Bibliotheken und Abhängigkeiten von Drittanbietern in einer Anwendung und vergleicht sie mit Schwachstellendatenbanken (NVD, OSV). Da moderne Anwendungen möglicherweise Hunderte von Abhängigkeiten einbinden – viele davon transitiv –, sind SCA-Tools wie OWASP Dependency-Check, Snyk und Renovate unverzichtbar, um bekannte CVEs zu erkennen, bevor Angreifer sie in Ihrer Lieferkette ausnutzen.

Die Integration von Sicherheitstools in CI/CD-Pipelines stellt sicher, dass kein Code die Produktion erreicht, ohne Sicherheitsprüfungen zu bestehen. Eine typische DevSecOps-Pipeline führt Folgendes aus: SAST bei jedem Commit, SCA bei Änderungen an Abhängigkeiten, das Scannen von Container-Images vor dem Push in eine Registry, IaC-Scanning für Terraform/CloudFormation und DAST gegen eine Staging-Bereitstellung. Fehlgeschlagene Sicherheitsprüfungen blockieren den Build und etablieren eine Kultur, in der Sicherheit standardmäßig aktiviert ist.

Automatisierte Tools können ein auf Sicherheitslogik ausgerichtetes menschliches Code-Review nicht ersetzen. Ein Peer-Review sollte überprüfen, ob: Authentifizierungs- und Autorisierungsprüfungen an den richtigen Stellen erfolgen, die Fehlerbehandlung keine sensiblen Informationen preisgibt, kryptografische Funktionen zugelassene Algorithmen und Parameter verwenden und die Geschäftslogik nicht umgangen werden kann. Security Champions in Entwicklungsteams – Entwickler mit Sicherheitsschulung – schließen die Lücke zwischen dem Sicherheitsteam und der Entwicklung.

Testen Sie Ihr Verständnis der CompTIA-Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Der sichere SDLC integriert Sicherheit in alle Entwicklungsphasen, statt sie erst am Ende nachträglich hinzuzufügen, SAST analysiert Code ohne Ausführung, während DAST laufende Anwendungen testet und SCA identifiziert anfällige Open-Source-Abhängigkeiten, während CI/CD-Sicherheitsprüfungen die Ergebnisse automatisch durchsetzen. Als Nächstes behandeln wir Verzeichnisdienste mit LDAP und Active Directory.