Nicht erst seit dem Bekanntwerden von Heartblead, Shellshock und Poodle ist es für Softwareunternehmen wichtig, sich mit der Sicherheit der von ihnen bereitgestellten Anwendungen zu beschäftigen und Entwicklungsleitlinien für sichere Software zu entwickeln.
Ein Bewusstsein für Anwendungssicherheit etablieren
Es ist für jedes Unternehmen empfehlenswert sich zur Wahrung ihrer Geschäftsgrundlage und im Sinne ihrer Kunden der Thematik anzunehmen und einen Prozess zur Etablierung von Best Practices und Erarbeitung von Leitlinien für sichere Software aufzunehmen.
Die Hauptaufgabe kommt hierbei dem Aufbau des Bewusstseins und dem Verständnis von Anwendungssicherheit innerhalb der gesamten IT und im besonderen der Entwicklungs-, DevOps- und Systemadministratorenteams zu. Das langfristige Ziel ist die intrinsische Motivation Sicherheitsaspekte in der Anwendungsentwicklung zu berücksichtigen. Doch was ist für das eigene Unternehmen oder Projekt sinnvoll und womit sollte man beginnen?
Ein guter Einstiegspunkt für Webanwendungen ist das Open Web Application Security Project (OWASP). Es bietet einen umfassenden Themenüberblick und viele Einstiegsmöglichkeiten:
- Anleitungen für Entwickler, Tester und Organisationen
- Best Practices
- Frameworks und Referenzimplementierungen
sowie mit der
- TOP 10 eine Übersicht über die häufigsten Sicherheitsrisiken in Webanwendungen.
Auf den in der TOP 10 genannten Punkt der Prüfung von Softwareprojekten auf verwendete Abhängigkeiten mit bekannten Sicherheitslücken wollen wir hier näher eingehen.
Abhängigkeiten mit bekannten Sicherheitslücken erkennen
Die Vielzahl der besonders im Java Umfeld frei verfügbaren Anwendungen und Open-Source-Bibliotheken führt zu komplexen Abhängigkeitsbäumen innerhalb von Software, die manuell nicht zu überschauen und zu überwachen sind. Um frühzeitig mögliche Sicherheitsrisiken zu identifizieren, sollte in kurzen Intervallen eine Überprüfung der Abhängigkeiten stattfinden und die Ergebnisse den Entwicklungsteams mitgeteilt werden.
Das frei verfügbare Projekt OWASP Dependency Check bietet für Java und .NET die Möglichkeit diese Überprüfung automatisiert vorzunehmen.
Das Projekt prüft alle Abhängigkeiten gegen die öffentlich verfügbare National Vulernability Database (NVD) des NIST auf Common Vulnerability und Exposures (CVE) Einträge und listet die Treffer mit vielen Details wie Einstufung, Angriffsvektoren und z.B. Referenzen zu Bestätigungen durch die Hersteller in einem Bericht.
Die Java Version kann als Jenkins oder Maven Plug-In, Ant Task oder auf der Kommandozeile ausgeführt werden und eignet sich somit besonders für zeitgesteuerte bzw. durch ein Source Control Management ausgelöste Builds.
Jenkins Integration
Die Installation und Konfiguration des OWASP Dependency Check erfolgt unkompliziert über das Plug-In-Management und die Konfiguration von Jenkins. Es gibt die Möglichkeit statt gegen die NVD-Datenbank des NIST gegen eine lokale Kopie der XML-Datenbank zu prüfen. Dies ist sinnvoll, falls der Continuous Integration Server nicht mit dem Internet verbunden ist. In diesem Fall muss natürlich anderweitig für eine Aktualisierung der XML-Datenbank gesorgt werden.
Die Konfiguration auf Job Ebene erfolgt als Post Step und einer darauf folgenden Post Build Aktion in denen
- False-Positives unterdrückt,
- das Updaten der Datenbank deaktiviert,
- Qualitätsschwellen abhängig von der Schwere der Lücken definiert,
- das Fehlschlagen des Builds konfiguriert
werden können.
Die Ergebnisse und Berichte können zusätzlich zur Darstellung in Jenkins (s.u.) auch als HTML Datei gespeichert werden.
Maven Plug-In
Die Einbindung als Maven Plug-In bietet ähnliche Konfigurationsmöglichkeiten wie das Jenkins Plug-In. Es können bestimmte Arten zur Identifizierung der Bibliotheken de- bzw. aktiviert werden. Für den Nexus-Analyzer, der Bibliotheken anhand ihres Hashwertes erkennt, kann die Adresse zum Artifactory konfiguriert werden. Falls ein unternehmensinternes Artifactory als Spiegelung des Maven Central verwendet wird, kann z.B. dessen Adresse verwendet werden. Alternativ kann das öffentliche Sonatype Repository verwendet werden, hierzu ist allerdings Netzzugriff nötig.
<pluginManagement>
<plugins>
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>1.2.6</version>
<configuration>
<skipProvidedScope>true</skipProvidedScope>
<skipRuntimeScope>true</skipRuntimeScope>
<nexusAnalyzerEnabled>true</nexusAnalyzerEnabled>
<nexusUrl>https://repository.sonatype.org/service/local/</nexusUrl>
<aggregate>true</aggregate>
<assemblyAnalyzerEnabled>false</assemblyAnalyzerEnabled>
<nuspecAnalyzerEnabled>false</nuspecAnalyzerEnabled>
<format>ALL</format>
</configuration>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
Hinweis für Multi-Module Projekte: In einem Maven Multi-Module Setup sollte für die Ausführung des Plug-In in allen Kind-Modulen das Updaten der NVD-Datenbank deaktiviert werden, da dies sehr zeitintensiv ist und die Buildzeit extrem verlängert wird. Es reicht aus, das Update nur einmal mit der Master-POM auszuführen.
<plugin> ... <configuration> <autoUpdate>false</autoUpdate> </configuration> </plugin>
Die Vorteile im Überblick
Die zeitnahe Analyse der Abhängigkeiten und das frühe Feedback an die Entwickler helfen dabei:
- die Verwendung von Komponenten, die bekannte Sicherheitslücken haben, zu vermeiden
- über neue Sicherheitslücken frühzeitig informiert zu werden um darauf reagieren zu können
- ein Bewusstsein für Sicherheitsaspekte zu etablieren
und somit zu sicherer Software beizutragen.
Hilfreich kann es weiterhin sein, zusätzlich regelmäßige Updates auf aktuelle Versionen von Abhängigkeiten mit in den Softwareentwicklungsprozess einzuplanen. Eine hohe Testabdeckung unterstützt Entwickler dabei den Aufwand so gering wie möglich zu halten und mögliche Inkompatibilitäten schnell zu erkennen.