Seite 2: Wie reif sind meine Analysen?

Inhaltsverzeichnis

Als Richtlinie zur Integration von Security-Checks in die eigene CI/CD-Pipeline können Entwickler das Reifegradmodell Security DevOps Maturity Model (SDOMM) verwenden. Es dient dazu, eine Roadmap für Projekte zu definieren, um ein bestimmtes Automatisierungslevel für Sicherheitsanalysen zu erreichen. Das Modell definiert hierzu vier Achsen mit jeweils vier erreichbaren Level. Je höher das erreichte Level innerhalb einer Achse ist, desto höher ist der Grad an Automation. Für jedes Level definiert das Reifegradmodell Maßnahmen, die zum Erreichen des jeweiligen Levels umzusetzen sind (wie das Durchführen dynamischer Anwendungsanalysen nach erfolgreicher Authentifizierung an der Anwendung).

Die erste Achse des Reifegradmodells bezieht sich auf die dynamischen Anwendungsanalysen ("Dynamic Depth"). Über die Achse "Static Depth" wird der Reifegrad der statischen Anwendungsanalysen gemessen. Weiterhin misst die Achse "Intensity" die Stärke der durchgeführten Analysen. Die Achse "Consolidation" erlaubt es, Rückschlüsse darauf zu ziehen, wie mit den identifizierten Ergebnissen im Nachgang umgegangen wird. Je nachdem, welcher Reifegrad im konkreten Anwendungsfall als Ziel gesetzt ist, lassen sich anhand dieser Einteilung konkrete Handlungsempfehlungen ableiten.

Dem Quellcode auf der Spur

Zum Durchführen statischer Codeanalysen existieren viele kommerzielle und freie Werkzeuge am Markt. Einige sind als Plug-in direkt in die eigene Entwicklungsumgebung integrierbar, sodass Entwickler bereits während der Implementierung Rückmeldungen zu potenziellen Sicherheitslücken erhalten. Darüber hinaus lassen sich die Analysetools in der Regel über Maven oder Gradle in den CI/CD-Prozess der Anwendung integrieren, sodass ein Build-Server wie Jenkins die Analysen automatisiert ausführt. Die generierten Reports stehen anschließend als HTML- oder XML-Dateien zur Verfügung.

Grundsicherheit mit dem OWASP Dependency Check

Die meisten Webanwendungen verwenden Frameworks und Drittanbieter-Bibliotheken, um den Entwicklungsprozess zu vereinfachen und zu beschleunigen. Doch auch diese können schwerwiegende Sicherheitslücken enthalten. Mit dem OWASP Dependency Check können Entwickler die verwendeten Abhängigkeiten auf bekannte Schwachstellen prüfen, ohne den kompletten Code der jeweiligen Bibliothek explizit scannen zu müssen. Hierfür ermittelt der Dependency Check die jeweilige Version der verwendeten Bibliothek und prüft diese gegen die National Vulnerability Database (NVD) des NIST. Diese Datenbank sammelt und bewertet alle veröffentlichten Sicherheitslücken zahlreicher Frameworks und Bibliotheken. Als Ergebnis erzeugt der OWASP Dependency Check einen Report, der die anfälligen Abhängigkeiten inklusive CVE-Code (Common Vulnerabilities and Exposures) auflistet. Entwickler können im Anschluss bei Bedarf über den eindeutigen CVE-Code weitere Informationen über den Angriffsvektor einholen und entsprechend reagieren. Um den OWASP Dependency Check automatisiert innerhalb eines Build-Servers auszuführen, kann ein eigener Gradle-Task innerhalb der build.gradle-Datei der Anwendung erstellt werden.

apply plugin: 'org.owasp.dependencycheck'

dependencyCheck {
    autoUpdate=true
    cveValidForHours=24
    format='HTML'
}

Die oberen Zeilen binden das entsprechende Gradle-Plug-in ein und definieren den Gradle Task dependencyCheck, den der Build-Server im Anschluss ausführen kann. Der Konfigurationswert cveValidForHours gibt an, wie lange die lokale Kopie der NVD gültig sein soll und wann sie über das Internet automatisch aktualisiert wird.

Die Verwendung des OWASP Dependency Checks hätte den Angriff auf Equifax 2017, der einen Schaden von mehreren Hundert-Millionen Dollar verursachte, verhindern können. Die Angreifer nutzten eine bekannte Sicherheitslücke im Apache-Struts-Framework, das Equifax verwendete. Mit dem OWASP Dependency Check wäre diese Sicherheitslücke frühzeitig in den Reports aufgefallen.