Automatisierte Erkennung von Softwaresicherheitslücken im Entwicklungsprozess: Maßnahmen für eine Jenkins Pipeline

Doch wie sieht es mit der Sicherheit in diesem Prozess aus? Das wohl bekannteste Tool für den CI/CD Prozess ist Jenkins. Dieser Artikel setzt sich mit Maßnahmen zur automatisierten Erkennung von Sicherheitslücken auseinander, die in eine Jenkins Pipeline integriert werden können.

Genauer genommen werden hierbei zwei Punkte untersucht:

• Wie kann man den neunten Platz der OWASP Top Ten „Nutzung von Komponenten mit bekannten Schwachstellen“ verhindern?
• Welches Codeanalyse-Tool deckt möglichst viele Sicherheitslücken im Code auf?

Für beide Punkte werden jeweils mehrere Tools untersucht. Für Punkt eins gibt es die Kandidaten: Dependency Check, Dependency Track (beide Open Source von OWASP) und der Repository Health Check in Nexus (als kommerzielle Version verfügbar). Für Punkt zwei gehen Spotbugs (mit FindSecBugs), SonarQube und dazu noch zwei kommerzielle Tools ins Rennen. Die kommerziellen Tools dürfen aus Lizenzgründen nicht genannt werden, deswegen werden sie nachfolgend als Tool A und B anonymisiert.

Nutzung von Komponenten mit bekannten Schwachstellen verhindern

Die Tools aus Punkt eins werden mithilfe von dem Framework Struts2 analysiert. Davon gibt es eine Version die anfällig für remote code executions ist.  Jeder der Kandidaten hat diese Version analysiert und als Risiko erkannt. Dabei stellte sich heraus, dass jeder dieser einen unterschiedlichen Einsatzzweck hat. Beispielsweise ist Dependency Check bestens dazu geeignet schnelle Analysen als Entwickler vorzunehmen. Dependency Track eignet sich hervorragend als zentrale Sammelstelle für Reports der Abhängigkeiten. Der Repository Health Check verfolgt einen anderen Ansatz. Er kontrolliert alle Ressourcen, die beispielsweise über Maven bezogen werden.  In einem Maven Projekt lassen sich die Einsatzszenarios wie folgt darstellen:

Nexus überbrückt die Kommunikation zwischen dem Entwickler und dem Maven Central Repository, dadurch werden alle Komponenten direkt auf Sicherheitslücken überprüft. Wirklich jede wird überprüft – auch die, welche man nur benötigt um Maven-Befehle auszuführen. Im Endeffekt lässt sich so nicht wirklich sagen, welche Komponenten nun tatsächlich in der Software verbaut werden und welche nur für dessen Entwicklung nötig sind. Für eine Jenkins-Pipeline eignet sich demnach Dependency Track am besten, da alle Abhängigkeiten zentral an einem Ort gespeichert werden.

Ein geeignetes SAST-Tool

Die Codeanalyse-Tools aus Punkt zwei werden gegen die Juliet Testsuite für Java getestet. Diese enthält 25.477 verschiedene Testszenarien und deckt dadurch 112 CWEs ab. CWE steht für Common Weakness Enumeration und beschreibt in der Software auftretende Fehler. Jeder der Kandidaten aus Punkt zwei hat diese Testsuite analysiert. Dadurch kommt folgendes Ergebnis zustande:

In der ersten Annahme versteht sich das kommerzielle Tool B als bestes Code Analyse Tool, da es die meisten CWEs erkennt. Durch den dazugehörigen Marketplace lässt sich SonarQube durch Plugins erweitern, so auch durch FindSecBugs. Benutzt man also FindSecBugs als Plugin in SonarQube, sehen die Ergebnisse wie folgt aus:

In Zahlen sind das 54 CWEs für SonarQube mit FindSecBugs, 48 CWEs für Tool B und 17 CWEs für Tool A.

Fazit

Die Ergebnisse zeigen, dass es in diesem Fall keiner kommerziellen Lösung bedarf. SonarQube mit dem FindSecBugs Plugin deckt rund 50% der Sicherheitslücken in der Juliet Testsuite ab. Wie viele Sicherheitslücken jedoch unter realen Bedingungen gefunden werden, lässt sich nur Abschätzen. Ganz davon abgesehen, welches Framework eingesetzt wird, muss man das passende SAST-Tool einsetzen. Mit Dependency Track lassen sich dich Komponenten eines Softwareprojekts einfach an einem Ort sammeln und auf vorhandene Sicherheitslücken analysieren. SonarQube und Dependency Track lassen sich einfach über Maven oder ein Plugin in eine Jenkins Pipeline integrieren.