Java-Webanwendungen beim Build auf Sicherheit überprüfen
Geregelt durchleuchtet
Security-Tests und -Analysen sollten ein fester Bestandteil des Build-Prozesses sein. Dazu stehen verschiedene Open-Source-Tools zur Verfügung. Der Artikel stellt einige von ihnen vor und gibt Tipps zu ihrer Konfiguration.
Wer Sicherheitsrichtlinien in irgendeiner Form bei der Entwicklung berücksichtigt, möchte deren Einhaltung möglichst automatisiert überprüfen können und den Entwicklern Feedback zur Verfügung stellen. Hierfür bietet sich der Build-Prozess an, denn dieser ist meist schon automatisiert und lässt sich ohne großen Aufwand durch Tools und Plug-ins erweitern.
Das Standard-Setup einer Build-Chain im Java-Ökosystem besteht meist aus dem Continuous-Integration-System Jenkins nebst SonarQube zur statischen Codeanalyse. Der folgende Artikel konzentriert sich daher auf Jenkins als Build-Server. Viele Security-Plug-ins, darunter die vorgestellten, sind auch für SonarQube verfügbar oder lassen sich per Maven unabhängig vom Build-Server direkt aufrufen und so in andere Anwendungen integrieren.
Wo genau man Security-Checks ansiedelt, ist Geschmackssache. Wichtig ist nur, einen Check stets nur ein einziges Mal auszuführen. Jeder Scan kostet Zeit und verzögert das Feedback für die Entwickler. Security-Scans haben teils dramatische Auswirkungen auf die Build-Zeit und können den Build-Server stark unter Last setzen. Für Builds, die nach einem Push automatisch anlaufen und „nur“ die erfolgreiche Integration der Codeanpassungen überprüfen sollen, ist eine solche Verzögerung meist nicht akzeptabel.
Schlimmer noch: Sie bedroht die Akzeptanz der Sicherheitsrichtlinien durch die Entwickler. Wer lange auf die Ergebnisse eines Build warten muss, ist viel eher geneigt, die lang laufenden Scans auszuschalten. Security-Scans sind daher besser in Nightly oder anderen unabhängig von Codeanpassungen laufenden Builds aufgehoben.
Security-Scans dürfen nicht nerven
Nach dem Build gilt es, die Scan-Ergebnisse zu prüfen und bei Bedarf dem Team zur Bearbeitung zuzuweisen. Der dafür Verantwortliche wird häufig als Security Champion bezeichnet, er ist meist auch mit der Pflege eventueller False-Positive-Listen betraut sowie mit der Optimierung der Scans. Dass man für diese Aufgabe jemanden auswählt, der über ein Mindestmaß an Kenntnissen in Sachen Sicherheit verfügt, sollte klar sein. Der Security Champion soll auch die Ergebnisse der Scans den Entwicklern vermitteln – und zwar so verständlich, dass die zugrunde liegenden Fehler zukünftig vermieden werden.
Bevor es nun mit einigen ausgewählten Open-Source-Tools losgeht, noch eine Warnung vorab: Keines davon ersetzt einen Pentest oder andere Maßnahmen rund um die sichere Softwareentwicklung. Sie stellen nicht mehr und nicht weniger als eine sinnvolle Erweiterung dar und sollten ergänzend zu anderen Maßnahmen eingesetzt werden.
Zudem finden diese Tools vor allem bei den ersten Einsätzen lediglich die „low hanging fruits“. Ohne Optimierung für die jeweilige Webanwendung bleiben die identifizierten Schwachstellen auf diesem Niveau. Doch bereits damit lässt sich die Sicherheit einer Webanwendung verbessern und die Messlatte für einen Pentester beziehungsweise Angreifer anheben. Dieser ist dann nicht mehr mit einer simplen SQL-Injection oder einem einfachen XSS-Angriff (Cross-Site-Scripting) erfolgreich, sondern muss sich ausgefeilterer Varianten bedienen. Greifen diese, gilt es zu prüfen, inwieweit sie als Scans in eines der Tools übernommen und damit zukünftig ebenfalls automatisiert werden können.