Martin Huschenbett beleuchtet, wie die statische Quellcode-Analyse mit Fortify Static Code Analyzer erfolgreich skaliert werden kann, um auch in größeren Entwicklungsvorhaben mit mehreren Projekten schnellstmöglich gute Ergebnisse zu erzielen.
Immer mehr Kunden erkennen die Relevanz von Anwendungssicherheit und stellen ihre Softwareentwicklung auf DevSecOps um. Dabei werden unter anderem Tools zur statischen Quellcode-Analyse genutzt, um potenzielle Sicherheitsrisiken im Quellcode frühzeitig zu erkennen und zu beheben. Ein solches Tool ist Micro Focus Fortify, das regelmäßig durch den Gartner Magic Quadrant als Marktführer ausgezeichnet wird.
In diesem Beitrag beleuchten wir, wie die statische Quellcode-Analyse mit Fortify Static Code Analyzer erfolgreich skaliert werden kann, um auch in größeren Entwicklungsumgebungen mit mehreren Projekten schnellstmöglich gute Ergebnisse zu erzielen. Bevor wir in das Thema einsteigen, zu Beginn noch ein kurzer Überblick über die Fortify Toolsuite sowie den klassischen Einsatz von SCA.
Static Code Analyzer (SCA)
Der Static Code Analyzer (SCA) ist ein klassisches Static Application Security Testing (SAST) Tool. Es ermöglicht mithilfe von diversen Plugins und Integrationen, zum Beispiel in Entwicklungsumgebungen (IDEs) oder CI/CD-Pipelines, das frühzeitige Erkennen von potenziellen Sicherheitsschwachstellen ab der ersten Zeile Quellcode.
Ein Scan besteht dabei aus drei Phasen:
- Translate – Übersetzen des Quellcodes in ein Zwischenmodell (Normalized Syntax Tree, NST), auf Basis dessen die Analyse durchgeführt wird
- Scan – Durchführung der Quellcode-Analyse anhand des übersetzten Quellcodes
- Review – Aufarbeiten der Ergebnisse durch den entsprechenden Mitarbeiter
WebInspect
WebInspect ermöglicht die dynamische Analyse einer Webanwendung zur Laufzeit, ist also ein Tool für die Kategorie Dynamic Application Security Testing (DAST). Dabei imitiert WebInspect einen echten Angreifer und führt automatisch Penetrationstests durch.
Software Security Center (SSC)
Das Software Security Center (SSC) ist das zentrale Repository der Scanergebnisse. Im SSC werden die Scanergebnisse der statischen Analyse mit SCA und der dynamischen Analyse mit WebInspect zusammengeführt und den Entwicklern inklusive ausführlicher Informationen zu den einzelnen Issues bereitgestellt.
Klassischer Einsatz
In einem klassischen Szenario wird der SCA mit Hilfe der entsprechenden Plugins in die CI/CD-Pipeline eingebunden. Am Beispiel Jenkins bedeutet das, dass ein neuer Agent hinzugefügt wird, auf welchem der Static Code Analyzer installiert ist. Dieser Agent wird dann in die entsprechende Pipeline eingebunden und führt die statische Analyse des Quellcodes durch. Im Folgenden ist eine solche typische Pipeline abgebildet:
In dieser Jenkins-Pipeline wird ein dedizierter Jenkins-Agent verwendet, um die SCA-Scans durchzuführen. Das funktioniert auch für einzelne Pipelines gut, allerdings treten bei dem klassischen Szenario Probleme auf, sobald man mehrere Projekte (gleichzeitig) scannen möchte.
Nachteile
Je nach Größe und Komplexität eines Projekts kann ein Scan unterschiedlich lange dauern. Wenn also mehrere Projekte einen Scan mit SCA durchführen möchten, es aber nur eine begrenzte Anzahl an Scannern gibt, kann es sein, dass der Scan eines Projekts den Scan eines anderen blockiert, weil er noch nicht fertig ist. Das heißt, dass es zu Verzögerungen oder zum Abbruch von Pipelines kommen kann. Falls ein Scanner aktualisiert wird oder es technische Probleme gibt, entstehen folglich auch Ausfallzeiten für die Pipelines und es bleiben Scan-Ergebnisse aus.
Um dem entgegenzuwirken, könnte man die Anzahl an Agenten mit SCA erhöhen. Allerdings bringt das wiederum den Nachteil mit sich, dass die neuen Agenten wieder neu konfiguriert und an die Projekte angebunden werden müssen. Außerdem entsteht dadurch auch eine höhere Leerlaufzeit für die Agenten, da diese nicht mehr voll ausgelastet werden. Hier kommt nun Fortify ScanCentral zum Einsatz.
Fortify ScanCentral
Fortify ScanCentral (ehemals CloudScan) ist eine Lösung, um den eigentlichen Scan-Prozess auszulagern, zum Beispiel in eine Private, Public oder Hybrid Cloud. Diese Lösung soll im Folgenden genauer beschrieben werden.
ScanCentral besteht aus drei Komponenten: ScanCentral Client, ScanCentral Controller und ScanCentral Sensoren.
Folgendes Schaubild soll die Architektur genauer darstellen:
Der ScanCentral Client ist eine Build-Maschine, welche den Quellcode in das Zwischenformat (NST) übersetzt. Der übersetzte Quellcode wird dann zusammen mit optionalen Informationen und Parametern als Fortify Static Code Analyzer Mobile Build Session verpackt und an den ScanCentral Controller weitergeleitet.
Der ScanCentral Controller ist ein eigenständiger Server, welcher die Scan-Aufforderungen zusammen mit den hochgeladenen Fortify Static Code Analyzer Mobile Build Sessions und den zusätzlichen Instruktionen erhält. Die Scan-Aufforderungen des ScanCentral Clients werden dann in die entsprechende Queue abgelegt. Sobald ein ScanCentral Sensor, welcher der jeweiligen Queue zugewiesen ist, frei wird, lädt er sich die entsprechenden Daten herunter und führt die Quellcode-Analyse aus. Die Ergebnisse werden nach Abschluss des Scans an den Controller zurückgemeldet. Der Controller lädt die Ergebnisse wiederum in das Software Security Center hoch, damit sie den Entwicklern und der Sicherheitsabteilung zur Verfügung stehen.
Vorteile
Im Vergleich zum „klassischen“ Ansatz hat die Einbindung von Fortify ScanCentral einige Vorteile.
Es ist nicht mehr nötig, für jede Pipeline einen einzelnen SCA-Scanner bereitstellen, sondern der ScanCentral Client wird als zentraler Anlaufpunkt für das Ausführen der Quellcode-Scans genutzt. Die Erfahrungen bei unseren Kunden haben gezeigt, dass es meistens ausreichend ist, ein oder zwei ScanCentral Clients bereitzustellen, welche dann in die Pipelines eingebunden werden. Diese erfahren dadurch eine höhere Auslastung und die Ressourcen werden besser genutzt.
Das trifft ebenfalls auf die eigentlichen SCA-Scanner zu, die ScanCentral Sensoren. Dadurch, dass der Controller die Auslastung der Sensoren überwacht und die Scan-Aufträge entsprechend zuweist, entsteht auch eine optimierte Ressourcennutzung der Sensoren, da diese nicht mehr an ein oder zwei Pipelines gebunden sind, sondern alle anfallenden Scan-Aufträge annehmen können.
Sollten die eigenen Systemressourcen für einen Scan nicht ausreichend verfügbar sein, kann bei den bekannten Cloud-Anbietern wie Amazon Web Services oder Microsoft Azure eine Maschine mit entsprechender Leistung für die Durchführung des Scans hinzugezogen werden, welche sich einfach in den bestehenden Pool an Sensoren eingliedern lässt. Wenn diese Maschine nicht mehr benötigt wird, kann sie aus dem Pool entfernt werden, ohne dass die Pipelines angepasst werden müssen.
Des Weiteren kommt es zu weniger Ausfallzeiten in den Pipelines. Falls ein Sensor nicht verfügbar ist, weil gerade Updates installiert werden oder es technische Probleme gibt, übernimmt ein anderer freier Sensor den Scan. Die Ergebnisse landen also am Ende trotz Ausfall im Software Security Center. ScanCentral eignet sich also hervorragend, um die Scan-Dichte über mehrere Entwicklungsprojekte hinweg erfolgreich zu skalieren und zu parallelisieren. Dabei werden Ressourcen so optimal wie möglich ausgenutzt und die Wartbarkeit der entsprechenden CI/CD-Pipelines verbessert sich ebenfalls.
