Anfang dieses Jahres wurde unser Team damit beauftragt, unsere bestehenden Sicherheitstools und Verfahren für Softwareentwicklung und -tests zu erweitern, um die Anforderungen von PCI-DSS und SOC 2 zu erfüllen. Einer der wichtigsten Bereiche, die wir ausbauen mussten, war das Schwachstellen-Scanning für unsere K8s-basierten Microservices und einige monolithische Dienste. Daher musste sich unser DevOps-Team zwischen mehreren kommerziellen Tools und Open-Source-Lösungen entscheiden, um das Schwachstellen-Scanning für unsere Software zu implementieren. All diese Tools funktionieren sehr ähnlich: Sie scannen Abhängigkeiten (entweder Projektbibliotheken oder Betriebssystempakete) und gleichen sie mit Schwachstellendatenbanken (wie der NVD des NIST und anderen) ab.
Selbst entwickeln oder kaufen?
Es gibt einige Open-Source-Tools, mit denen Sie Ihre eigene Lösung für Schwachstellen-Scans erstellen können. Alternativ können Sie ein kommerzielles Produkt verwenden, das über grundlegende Scans hinaus zusätzliche Funktionen bietet und Ihnen die Arbeit erleichtert. Beispiele hierfür sind:
- Übersichtliche 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-Tools (z. B. Jira)
- Automatische Erstellung von Merge Requests zur Behebung anfälliger Abhängigkeiten
- Unterstützung für Teams, Projekte und rollenbasierte Zugriffskontrolle (RBAC)
Die meisten kommerziellen Lösungen ergänzen öffentliche Schwachstellendatenbanken um eine eigene Datenbank, um falsch positive bzw. falsch negative Ergebnisse zu vermeiden und relevantere Resultate zu liefern. Allerdings werden all diese kommerziellen Tools mit zunehmender Anzahl an Entwicklern sehr teuer. Daher müssen Sie abwägen, ob es für Sie „besser“ ist, eine Lösung zu kaufen oder mithilfe vorhandener Open-Source-Tools eine eigene zu entwickeln.
Angesichts unseres engen Zeitrahmens entschieden wir zunächst, dass ein kommerzielles Tool unsere Anforderungen am besten erfüllen würde. Nachdem wir jedoch drei Monate lang ein marktführendes kommerzielles Produkt implementiert und getestet hatten, stießen wir auf zahlreiche Herausforderungen: eingeschränkte Unterstützung für Golang, die Auswahl falscher Abhängigkeiten und unsauberes Beenden, Probleme mit von Grund auf neu erstellten Containern im Vergleich zu solchen, die auf einem Basis-Image aufbauen, und vieles mehr. Daher beschlossen wir, das Produkt nicht weiterzuverwenden und stattdessen mithilfe verfügbarer Open-Source-Technologien ein eigenes Tool zu entwickeln.
In diesem Beitrag möchte ich Ihnen eine solide Grundlage für den Einstieg bieten, falls Sie sich für Open Source entscheiden. Außerdem finden Sie am Ende des Beitrags einen Link zu unserem Open-Source-Repository, damit Sie direkt loslegen können!
Was soll gescannt werden?
Grundsätzlich gibt es zwei Dinge, die Sie auf Schwachstellen überprüfen sollten:
- Die Code-Abhängigkeiten Ihres Projekts (yarn.lock, Gopkg.lock usw.)
- Betriebssystemabhängigkeiten (Debian-Pakete, Alpine-Pakete usw.) in einem Docker-Image
In Zukunft können weitere Funktionen wie Lizenzprüfungen oder statische Codeanalysen hinzugefügt werden, doch das würde den Rahmen dieses Beitrags sprengen.
Wann sollte gescannt werden?
Zunächst sollten Sie sicherstellen, dass durch Änderungen an Ihrem Code oder Docker-Image keine neuen Sicherheitslücken entstehen. Daher empfiehlt es sich, jeden Merge Request vor dem Zusammenführen zu scannen.
Sie müssen jedoch auch regelmäßig scannen, da im Laufe der Zeit neue Schwachstellen auftreten können. Auch die Schweregrade können sich ändern: Ein niedriger Schweregrad, den Sie zunächst ignoriert haben, kann mit der Zeit kritisch werden, wenn ein neuer Angriffsvektor oder Exploit entdeckt wird. Während kommerzielle Tools den letzten Scan speichern und Sie benachrichtigen, wenn eine neue Schwachstelle gefunden wird, wiederholen wir bei unserer Open-Source-Lösung den Scan einfach auf dem Master-Branch des Projekts.
Auswahl der Tools
Es gibt viele verfügbare Open-Source-Tools, aber wir haben uns für Trivy entschieden, weil es einfach zu bedienen ist, aktiv weiterentwickelt wird und verschiedene Projekte und Betriebssystemtypen scannen kann.
Trivy ist ein einfacher und umfassender Schwachstellenscanner für Container und andere Artefakte. Eine Softwareschwachstelle ist ein Fehler, Mangel oder eine Schwäche in einer Software oder einem Betriebssystem. Trivy erkennt Schwachstellen in Betriebssystempaketen (Alpine, RHEL, CentOS usw.) und Anwendungsabhängigkeiten (Bundler, Composer, npm, yarn usw.). Trivy ist einfach zu bedienen – installieren Sie einfach die Binärdatei, und schon können Sie mit dem Scannen beginnen! Für einen Scan müssen Sie lediglich ein Ziel angeben, beispielsweise den Image-Namen des Containers.
Es lässt sich einfach installieren und lokal für das erstellte Docker-Image oder im Stammverzeichnis des Projekts ausführen. Zudem unterstützt es mehrere Ausgabeformate, darunter JSON und Tabellen:
Leider gibt es Projekte, die Trivy nicht scannen kann (z. B. Golang), weshalb wir auf OWASP Dependency-Check zurückgreifen mussten, da ein Großteil unseres Codes in Golang geschrieben ist.
Dependency-Check ist ein Tool zur Software Composition Analysis (SCA), das versucht, öffentlich bekannt gegebene Schwachstellen in den Abhängigkeiten eines Projekts zu erkennen. Dazu ermittelt es, ob für eine bestimmte Abhängigkeit eine Common-Platform-Enumeration-Kennung (CPE) vorhanden ist. Wird eine solche gefunden, erstellt das Tool einen Bericht mit Links zu den zugehörigen CVE-Einträgen.
Es kann HTML-Seiten mit Berichten sowie Ausgaben im JUnit- und JSON-Format (und einigen weiteren Formaten) erzeugen.
Berichte und Dashboards
Jetzt kommen wir zu den interessanteren Dingen 😊
Da wir Elasticsearch + Kibana + Fluentd bereits in unseren DevOps- und SRE-Teams einsetzen, lag es nahe, die bestehende Infrastruktur zur Analyse der JSON-Ausgaben unserer Sicherheitsscans zu nutzen.
Wir mussten lediglich eine Möglichkeit finden, Daten aus einer nicht vertrauenswürdigen Infrastruktur (CI-Runnern) an unser abgesichertes Elasticsearch zu senden. Zu diesem Zweck entschieden wir uns für eine zwischengeschaltete Nachrichtenwarteschlange. Fluentd verfügt über das Plugin in_sqs, mit dem Nachrichten aus Amazon SQS gelesen werden können. Da es zudem einfach zu verwenden ist, sieht die endgültige Architektur wie folgt aus:
Sobald die Daten Elasticsearch erreichen, lassen sich mit Kibana ganz einfach einige Dashboards erstellen oder mit Discover Schwachstellen abfragen und bei Bedarf alle Details anzeigen.
Behebung von Schwachstellen
Jetzt haben wir also Scans und ein ansprechendes Dashboard – wie geht es weiter? Wir können nicht erwarten, dass die Entwickler diese Dashboards regelmäßig im Blick behalten. Daher haben wir beschlossen, die CI fehlschlagen zu lassen, wenn ein Problem mit hohem oder höherem Schweregrad gefunden wird, für das eine Fehlerbehebung verfügbar ist. Auf diese Weise wird die Verantwortung auf die Entwickler und Projektverantwortlichen übertragen.
Natürlich benötigten wir eine Möglichkeit, bestimmte CVEs auf eine Positivliste zu setzen oder dieses Standardverhalten für einzelne Projekte außer Kraft zu setzen. Daher erstellten wir ein Repository mit Profilen für Sicherheitsscans, die von unserem Scan-Tool verwendet werden. Dieses Tool kapselt die Ausführung von Trivy und steuert dessen Verhalten und Ausgabe.
Jetzt können alle Entwickler einen Merge Request für dieses Repository einreichen und eine Ausnahme beantragen. Beispielprofil für das Projekt kibana :
Zukünftige Verbesserungen
Diese Implementierung von Sicherheitsscans bildet eine solide Grundlage, die über unsere ursprünglichen Anwendungsfälle hinaus erweitert werden kann. Zum Beispiel:
- Slack-Benachrichtigungen hinzufügen und Sicherheitsprofile verwenden, um für jedes Projekt den Kanal und die Optionen festzulegen
- Integration mit GitLab Issues, Jira oder einem anderen Ticketsystem hinzufügen
- Einfachen Dienst oder Sidecar erstellen, um auf einem Kubernetes-Cluster bereitgestellte Images zu scannen
Forke es und nutze es
Das Dockerfile und die Tools finden Sie in unserem öffentlichen GitLab-Repository: https://gitlab.com/volterra.io/security-scanning
Vielen Dank an Jakub Pavlík.
Ähnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...