Frühzeitig über Sicherheitslücken im Projekt informiert werden

Veraltete Software im Produktivbetrieb

Unabhängig von der verwendeten Technologie, wie beispielsweise der Programmiersprache oder dem Framework, veralten Software-Projekte nach ihrer Produktivsetzung. Deshalb weiß jeder Software-Entwickler, dass bei länger laufenden Projekten, der Technologie-Stack von Zeit zu Zeit aktualisiert werden sollte. Modernisierungen stellen oftmals neue Funktionalitäten bereit, führen zu mehr Systemstabilität sowie Leistungsoptimierungen und beheben insbesondere aufgetretene Security-Lücken. Angesichts zunehmender Cyberbedrohungen ist es unerlässlich, frühzeitig über diese Sicherheitslücken in seinen Projekten informiert zu sein.

Hier stellt sich die Frage, ob manuelle Überprüfungen zur Aktualität in regelmäßige Abständen reichen, wenn Security-Lücken plötzlich bekannt werden? Woher weiß man, ob das Projekt betroffen ist? Die Antwort lautet: Es geht schneller und einfacher mit einem Werkzeug wie Trivy

Scanning mit Trivy

Das Open Source Werkzeug Trivy scannt ein Projekt auf Schwachstellen und falsche Konfigurationen. Es werden die gängigen Programmier-Sprachen mit ihren Abhängigkeiten unterstützt. Neben Programmier-Sprachen und deren Abhängigkeiten können auch beispielsweise Betriebssysteme und IaC (Infrastructure as Code) Konfigurationen untersucht werden.

Sehr angenehm ist, dass mit Trivy von außen auf ein Projekt geschaut werden kann und es müssen in der eigentlichen Software keine Erweiterungen, wie bspw. maven Plugins, installiert werden oder auch keine Konfigurationen vorgenommen werden. Das Projekt wird ganzheitlich untersucht.

Das Ergebnis ist ein Report der betroffenen Komponenten mit ihrer bekannten CVE-Nummer (Common Vulnerabilities and Exposures). CVE-Einträge sind öffentlich verfügbar und enthalten grundlegende Informationen zur Schwachstelle und der Kritikalität, aber keine technischen Details oder Exploits. Außerdem ist die empfohlene sichere Version aufgeführt, ab der das Problem behoben ist. Sofern verwendet, können auch Probleme in IaC-Dateien wie z.B. in einem Dockerfile angezeigt werden. Ein Beispiel für eine Auffälligkeit ist die Nutzung des root User in Docker.

Läuft eine Anwendung in einem Docker Container wird vor einer Analyse mit Trivy das Docker Image mit der Anwendung erstellt. Das Image wird an Trivy für die Durchführung der Analyse, wie im nachfolgenden Aufruf beispielhaft dargestellt, übergeben.

Andere Möglichkeiten für die Durchführung der Analysen ist die Erstellung von SBOM-Dateien, die anschließend an Trivy übergeben werden.

Für unser Beispiel müssten allerdings für eine Java-Applikation sowie für Docker eine solche Datei erstellt werden. Das Erstellen der SBOM-Dateien bedingt wiederum für Docker und die Java-Applikation die Installation eines Plugins. Insofern ist der erste Weg wesentlich einfacher.

Reporting der Ergebnisse

Für die Visualisierung der Ergebnisse stehen verschiedene Formate zur Verfügung und es können auch eigene Templates genutzt werden. Im oben gezeigten Beispiel wird in der Kommandozeile eine Tabelle generiert. Das nachfolgende Kommando zeigt dagegen die Erzeugung eines HTML-Reportes, wobei ein eigenes Template genutzt wird.

Die beiden nachfolgenden Screenshots zeigen einen Ausschnitt der gefundenen Security-Lücken für das Docker Image und die damit ausgelieferte Java-Applikation. Die Kritikalität ist farblich hervorgehoben und die Version der Bibliothek, mit der das Problem behoben wurde, ist ebenfalls sichtbar. Es handelt sich hierbei um eine produktive Version, die längere Zeit nicht aktualisiert werden konnte und deshalb wurden für Docker und Java jeweils über 20 Probleme festgestellt.

Die einzelnen Lücken können nach Kritikalität bewertet werden und ob sie überhaupt für die aktuelle Applikation relevant sind. Wenn die Aktualisierung einer Bibliothek aufgrund von Abhängigkeiten größere Aufwände verursacht, muss anhand der Kriterien abgewogen werden, ob dies zum aktuellen Zeitpunkt sinnvoll ist.

In unserem Fall konnten sämtliche involvierten Komponenten aktualisiert werden. Nach der Migration verblieb lediglich eine Java Bibliothek, die aufgrund von Abhängigkeiten nicht aktualisiert werden konnte. Das nachfolgende Bild illustriert eindrucksvoll auf der linken Seite die Findings vor der Migration und auf der rechten Seite das einzige verbliebene Finding nach der Migration.

Wie wurden die Findings behoben?

• Wechsel des Docker JDK-Base Images. Zum einen wurde auf ein Docker Image mit Java 21 statt bisher Java 17 gesetzt und zum anderen erfolgte der Wechsel von einem Ubuntu Image auf das leichtgewichtigere Alpine Image
• Für die Java-Applikation wurde neben der JDK-Version das genutzte Micronaut-Framework von der Version 3 auf die aktuelle Version 4 migriert. Des Weiteren wurden extern über gradle eingebundene Java-Bibliotheken genutzt

Automatisierung mit GitLab CI/CD

Bisher konnte gezeigt werden, wie durch die Nutzung mit Trivy Schwachstellen erkannt werden. Ziel sollte jedoch sein die Erkennung zu automatisieren, damit bei kritischen Problemen schnell reagiert werden kann. Ist ein Tool wie GitLab CI/CD im Einsatz, bietet sich die Integration in den Build-Prozess an. Trivy stellt hierfür entsprechende Anleitungen für verschiedene Build-Werkzeuge zur Verfügung.

Durch die Integration in eine Build-Pipeline kann beispielsweise abhängig von der Kritikalität der Build abgebrochen werden und eine Notification erfolgen. Nachfolgend ist eine Konfiguration aufgeführt, bei der nur Findings in den Kategorien CRITICAL und HIGH zu einem Abbruch führen.

In unserer Pipeline wird die trivy-Analyse ausgeführt, bevor ein fertiges Image in der Docker Registry bereitgestellt wird. Dies verhindert eine Veröffentlichung im Falle von schwerwiegenden Problemen.

Trivy in Kombination mit Renovate

Renovate ist ein populäres Tool, das auch in vielen Open Source Projekten genutzt wird, und in einer gewissen Verwandtschaft zu Trivy steht. Beide Tools automatisieren Aufgaben, um den Entwicklungsprozess zu erleichtern und helfen bei der Sicherheit und Wartung von Softwareprojekten.

Trivy ist jedoch grundsätzlich für Sicherheitsscans (Container, Repositories, Betriebssysteme) konzipiert und erkennt Schwachstellen. Renovate hat seinen Schwerpunkt dagegen auf der Erkennung von veralteten Abhängigkeiten und erstellt Pull Requests für Updates. Es bietet also Möglichkeiten zur automatischen Abhängigkeitsaktualisierung.

Beide Tools können in einem Projekt gemeinsam betrieben werden. Renovate kann beispielsweise Minor-Updates automatisch nachziehen und für Major-Updates Pull-Requests erstellen. Trivy scannt, angestoßen durch die Pipeline, sämtliche Branches und der Benutzer sieht relativ die Auswirkungen bzgl. der Security der nachgezogenen Änderungen.

Empfehlung

Durch die frühzeitige Erkennung von Sicherheitslücken in Projekten über Automatisierungen mithilfe von Trivy können Unternehmen potenzielle Bedrohungen vermeiden und so die Integrität ihrer IT-Infrastruktur schützen. Es ist anzuraten den Prozess weitgehend zu automatisieren, da die manuellen Aufwände zu hoch sind bzw. die Überprüfungen in Vergessenheit geraten.