Sicherheitsscan-Infrastruktur für Ihre Docker-Images und Code-Abhängigkeiten

Anfang des Jahres wurde unser Team gebeten, unsere vorhandenen Sicherheitstools und Software-Entwicklungs- und Testverfahren für die Einhaltung von PCI-DSS und SOC-2 zu erweitern. Einer der wichtigsten Bereiche, die wir erweitern mussten, war das Scannen nach Schwachstellen für unsere K8s-basierten Microservices und einige monolithische Dienste. Daher musste unser DevOps-Team zwischen einigen kommerziellen Tools und Open-Source-Lösungen wählen, um Schwachstellenscans für unsere Software zu implementieren. Alle diese Tools machen sehr ähnliche Dinge: Sie scannen Abhängigkeiten (entweder Projektbibliotheken oder Betriebssystempakete) und vergleichen sie mit Schwachstellendatenbanken (wie NVD des NIST und anderen).

Bauen vs. Kaufen?

Es gibt einige Open-Source-Tools, mit denen Sie Ihre eigene Lösung zum Scannen von Schwachstellen erstellen können. Alternativ können Sie auch ein kommerzielles Produkt verwenden, das über die Basisscans hinaus zusätzliche Funktionen bietet und Ihnen das Leben leichter macht. Beispiele hierfür sind: 

• Schöne Dashboards für einen schnellen Überblick über Schwachstellen in Ihren Projekten 
• Benachrichtigungen (E-Mail, Slack usw.) 
• Integration mit Git-Repositorys (GitHub, GitLab) 
• Integration mit anderen Diensten (Docker-Registry, Kubernetes) 
• Integration mit Projektmanagement (z. B. Jira) 
• Automatische Erstellung von Merge-Requests zum Beheben anfälliger Abhängigkeiten 
• Unterstützung für Teams, Projekte und RBAC

Die meisten kommerziellen Lösungen erweitern öffentliche Schwachstellendatenbanken um eigene Schwachstellendatenbanken, um falsch-positive/falsch-negative Ergebnisse auszuschließen und Ihnen relevantere Ergebnisse zu liefern. Allerdings werden all diese kommerziellen Tools sehr teuer, wenn die Zahl der Entwickler steigt. Sie müssen also abwägen, ob es für Sie „besser“ ist, eine Lösung zu kaufen oder mithilfe vorhandener Open-Source-Tools eine eigene Lösung zu entwickeln.

Zunächst entschieden wir, dass ein kommerzielles Tool unseren Anforderungen angesichts der zeitlichen Beschränkung am besten gerecht würde. Nachdem wir jedoch drei Monate damit verbracht hatten, ein branchenführendes kommerzielles Produkt bereitzustellen und zu testen, standen wir vor zahlreichen Herausforderungen – eingeschränkte Unterstützung für Golang, Auswahl falscher Abhängigkeiten und Nichtbeenden ohne ordnungsgemäße Beendigung, Probleme mit von Grund auf neu erstellten Containern im Vergleich zu solchen, die mit einem Basis-Image erstellt wurden, usw. Aus diesem Grund haben wir beschlossen, es aufzugeben und mit verfügbaren Open-Source-Technologien unser eigenes Tool zu entwickeln.

In diesem Beitrag werde ich Ihnen eine solide Grundlage für den Einstieg bieten, wenn Sie sich für Open Source entscheiden. Darüber hinaus finden Sie am Ende des Beitrags den Link zu unserem Open-Source-Repo, um Ihnen den Einstieg zu erleichtern!

Was soll gescannt werden?

Grundsätzlich gibt es zwei Dinge, die Sie auf Schwachstellen prüfen möchten: 

1. Die Codeabhängigkeiten Ihres Projekts (yarn.lock, Gopkg.lock usw.)
2. Betriebssystemabhängigkeiten (Debian-Pakete, Alpine-Pakete usw.) in einem Docker-Image

In Zukunft ist es möglich, weitere Funktionen wie Lizenzprüfung oder statische Codeanalyse hinzuzufügen, dies liegt jedoch außerhalb des Rahmens dieses Beitrags.

Wann scannen?

Zunächst einmal möchten Sie sicherstellen, dass durch Ihren Code oder die Änderung des Docker-Images keine neue Sicherheitslücke entsteht. Daher empfiehlt es sich, jeden Merge Request vor dem Merge zu scannen.

Sie müssen jedoch auch regelmäßige Scans durchführen, da im Laufe der Zeit neue Schwachstellen auftreten können. Darüber hinaus können sich die Schweregrade ändern: Ein niedriger Schweregrad, den Sie zunächst ignoriert haben, kann mit der Zeit kritisch werden, wenn ein neuer Angriffsvektor oder Exploit gefunden wird. Während kommerzielle Tools sich den letzten Scan merken und Sie benachrichtigen, wenn eine neue Schwachstelle gefunden wird, wiederholen wir in unserer Open-Source-Lösung den Scan einfach über dem Master-Zweig des Projekts.

Werkzeuge auswählen

Es stehen zahlreiche Open-Source-Tools zur Verfügung, wir haben uns jedoch für Trivy entschieden, da es einfach zu verwenden ist, aktiv weiterentwickelt wird und mehrere Projekte und Betriebssystemtypen scannen kann.

Trivy ist ein einfacher und umfassender Schwachstellenscanner für Container und andere Artefakte. Eine Software-Sicherheitslücke ist ein Fehler, eine Schwachstelle oder eine Schwäche in der Software oder einem Betriebssystem. Trivy erkennt Schwachstellen von Betriebssystempaketen (Alpine, RHEL, CentOS usw.) und Anwendungsabhängigkeiten (Bundler, Composer, npm, yarn usw.). Trivy ist einfach zu verwenden – installieren Sie einfach die Binärdatei und schon können Sie mit dem Scannen beginnen! Zum Scannen müssen Sie lediglich ein Ziel angeben, beispielsweise einen Image-Namen des Containers.

Es kann einfach installiert und lokal über das erstellte Docker-Image oder das Stammverzeichnis des Projekts ausgeführt werden. Es unterstützt auch mehrere Ausgaben, einschließlich JSON und Tabellenausgabe:

Leider gibt es Projekte, die Trivy nicht scannen kann (z. B. Golang), sodass wir uns auf den OWASP Dependency-Check verlassen mussten, da ein Großteil unseres Codes in Golang ist.

Dependency-Check ist ein Tool zur Software Composition Analysis (SCA), das versucht, öffentlich bekannt gewordene Schwachstellen in den Abhängigkeiten eines Projekts zu erkennen. Dies geschieht, indem ermittelt wird, ob für eine bestimmte Abhängigkeit eine Common Platform Enumeration (CPE)-Kennung vorhanden ist. Wenn ein Eintrag gefunden wird, wird ein Bericht mit einem Link zu den zugehörigen CVE-Einträgen erstellt.

Es kann HTML-Seiten mit Berichten, JUnit- und JSON-Ausgaben (und einigen anderen) generieren.

Berichte und Dashboards

Jetzt kommen wir zu interessanteren Sachen 😊

Da wir in unseren DevOps- und SRE-Teams bereits Elasticsearch + Kibana + Fluentd verwenden, war es eine naheliegende Entscheidung, die vorhandene Infrastruktur zur Analyse der JSON-Ausgabe unserer Sicherheitsscans zu nutzen.

Wir mussten nur einen Weg finden, Daten von nicht vertrauenswürdiger Infrastruktur (CI-Runner) an unsere sichere Elasticsearch zu senden. Zu diesem Zweck haben wir uns für eine Nachrichtenwarteschlange in der Mitte entschieden. Fluentd verfügt über ein in_sqs-Plugin zum Lesen von Nachrichten von Amazon SQS und ist außerdem einfach zu verwenden, sodass die endgültige Architektur folgendermaßen aussieht:

Sobald die Daten Elasticsearch erreichen, können Sie ganz einfach mit Kibana einige Dashboards erstellen oder mit Discover bei Bedarf Schwachstellen mit allen Details abfragen.

Beheben von Schwachstellen

Wir haben jetzt also Scans und ein paar nette Dashboards. Was kommt als Nächstes? Wir können nicht erwarten, dass Entwickler diese Dashboards regelmäßig beobachten. Stattdessen haben wir uns entschieden, CI scheitern zu lassen, wenn ein Problem mit hoher oder höherer Schwere gefunden wird und eine Lösung verfügbar ist. Auf diese Weise wird die Verantwortung auf die Entwickler und Projektbesitzer übertragen.

Natürlich brauchten wir eine Option, um einige CVEs auf die Whitelist zu setzen oder dieses Standardverhalten projektbezogen zu überschreiben. Daher haben wir ein Repository mit Sicherheitsscanprofilen erstellt, die von unserem Scantool verwendet werden, das die Trivy-Ausführung umschließt und dessen Verhalten und Ausgabe verwaltet.

Jetzt kann jeder Entwickler eine Merge-Anfrage an dieses Repository senden und eine Ausnahme anfordern. Beispielprofil für Kibana -Projekt:

Zukünftige Verbesserungen

Diese Implementierung der Sicherheitsüberprüfung ist eine solide Grundlage, die über unsere anfänglichen Anwendungsfälle hinaus erweitert werden kann. Zum Beispiel: 

• Fügen Sie Slack-Benachrichtigungen hinzu und nutzen Sie Sicherheitsprofile, um Kanäle und Optionen pro Projekt anzugeben. 
• Fügen Sie die Integration mit Gitlab Issues, Jira oder jedem anderen Ticketsystem hinzu
• Erstellen Sie einen einfachen Dienst oder Sidecar, um einen Scan der im Kubernetes-Cluster bereitgestellten Bilder auszuführen.

Forken Sie es und verwenden Sie es

Dockerfile und Tools finden Sie in unserem öffentlichen Gitlab-Repository: https://gitlab.com/volterra.io/security-scanning

Danke an Jakub Pavlík .