Image Scanning in der Praxis: Software-Lieferkette absichern

Hinweis: Dieser Beitrag wurde aus dem Englischen übersetzt. Fachbegriffe, Code und Befehle wurden bewusst im Original belassen.

Einführung

„Setzen wir Log4j ein?”

Das war die dringende Frage, vor der viele IT-Security-Teams standen, als die Log4Shell-Schwachstelle (CVE-2021-44228) bekannt wurde. Eine Software Bill of Materials (SBOM) hätte die Antwort erheblich erleichtert.

Angesichts zunehmend komplexer Software-Lieferketten verlangen Unternehmen und Behörden inzwischen SBOMs zur Risikosteuerung. Softwareanbieter, die mit der US-Bundesverwaltung zusammenarbeiten, müssen sie beispielsweise zur Transparenz und Sicherheit bereitstellen.

Der Einsatz externer Komponenten beschleunigt zwar die Entwicklung und senkt die Kosten, setzt Software aber auch Risiken durch bekannte Schwachstellen (CVEs) aus. Diese sich stetig verändernden Lieferketten ohne Automatisierung zu beherrschen, ist angesichts häufiger Updates, Deployments und neuer Werkzeuge nahezu unmöglich.

Was ist eine SBOM?

Die offizielle Definition laut SBOM-FAQ der NTIA lautet (hier übersetzt):

Eine Software Bill of Materials (SBOM) ist eine vollständige, formal strukturierte Liste der Komponenten, Bibliotheken und Module, die erforderlich sind, um eine bestimmte Software zu bauen (d. h. zu kompilieren und zu linken), einschließlich der Lieferkettenbeziehungen zwischen ihnen. Diese Komponenten können Open Source oder proprietär, kostenlos oder kostenpflichtig, frei verfügbar oder zugangsbeschränkt sein.

• Quelle: NTIA SBOM FAQ
• Weitere Informationen: NTIA Framing SBOM

Kurzfassung:
Eine SBOM ist eine detaillierte Aufstellung aller Bestandteile, Bibliotheken und Module einer Software samt ihrer Lieferkettenbeziehungen – ob quelloffen, kostenpflichtig, kostenlos oder zugriffsbeschränkt.

Warum SBOM-Scanning in der modernen Softwareentwicklung wichtig ist

Es ist deutlich schneller und einfacher, eine Sammlung von SBOMs zu scannen, als die gesamte Infrastruktur von Grund auf zu durchsuchen. Werkzeuge wie Trivy unterstützen das bereits. Bei einem Zero-Day – wie bei Log4Shell erlebt (und künftig weiter erleben werden) – zählt jede Minute.

SBOMs helfen Security-Teams zudem, Probleme für die Behebung zu priorisieren – anhand von Vorkommen und Ort – und Richtlinien zu erstellen, die auf Komponenteneigenschaften wie Hersteller, Version oder Pakettyp abstellen.

(Quelle: https://blog.gitguardian.com/what_is_sbom/)

Zentrale Vorteile des SBOM-Scannings:

• Schwachstellenmanagement sicherstellen: Schwachstellen erkennen und mindern, um Risiken zu überwachen und zu steuern.

• Regulatorische Compliance: Erleichtert die Einhaltung von Branchenstandards und die Auditbereitschaft durch eine detaillierte Dokumentation der Softwarekomponenten.

• Operative Effizienz: Vereinfacht das Dependency-Management, verringert technische Schulden und erleichtert Updates und Patches.

• Transparenz in der Lieferkette: Mindert Risiken, indem Abhängigkeiten von Drittkomponenten und potenzielle Schwachstellen sichtbar werden.

Ziele dieses Blogbeitrags

Dieser Beitrag will SBOM-Scanning in der Praxis eingehend beleuchten und dessen konkrete Anwendungen, Herausforderungen und Best Practices in realen Szenarien darstellen. Konkret werden wir:

• SBOM-Scanning entmystifizieren: Ein klares Verständnis davon vermitteln, was SBOM-Scanning umfasst – einschließlich Abläufen und Nutzen.

• Typische Herausforderungen adressieren: Die üblichen Hürden bei der Einführung von SBOM-Scanning in unterschiedlichen Umgebungen benennen und Lösungen vorschlagen.

• Best Practices und Empfehlungen geben: Umsetzbare Erkenntnisse und Leitlinien teilen, um SBOM-Scanning wirksam im Software-Lebenszyklus zu verankern.

• Praxisbeispiel: Ein kleines Beispiel zeigen, wie sich SBOM-Scanning in eine Microservice-Architektur einbinden lässt.

Warum SBOM?

Schwierigkeiten beim Nachverfolgen von Schwachstellen
Moderne Anwendungen stützen sich auf zahlreiche Abhängigkeiten, darunter versteckte und transitive. Schwachstellen über all diese Komponenten hinweg manuell nachzuverfolgen, ist unpraktikabel und fehleranfällig. Eine SBOM liefert ein vollständiges Inventar aller Softwarekomponenten und erleichtert damit das Erkennen und Steuern von Schwachstellen.

Für ein wirksames Scannen auf bekannte Schwachstellen werden Komponenten innerhalb einer SBOM über standardisierte Kennungen identifiziert (etwa CPE, PURL oder SWID). Diese Kennungen werden anschließend gegen Schwachstellendatenbanken abgeglichen, um bekannte CVEs aufzuspüren.

Tiefer Einblick in versteckte Abhängigkeiten
Eine SBOM listet nicht nur direkte Abhängigkeiten auf, sondern legt auch versteckte oder indirekte offen, die Schwachstellen einbringen können. Dieser tiefe Einblick ist für eine gründliche Sicherheitsbewertung entscheidend, damit keine Komponente übersehen wird.

Automatisierung und Standardisierung
SBOMs ermöglichen die Automatisierung von Security-Scans. Durch standardisierte Formate und Kennungen können Werkzeuge SBOMs plattform- und ökosystemübergreifend einheitlich interpretieren und auswerten. Diese Automatisierung senkt den manuellen Aufwand und erhöht die Treffsicherheit bei der Schwachstellenerkennung.

Erstellen und Scannen von SBOMs
Wichtig ist die Unterscheidung zwischen dem Erstellen und dem Auswerten einer SBOM:

• Eine SBOM erstellen: Erfordert Zugriff auf das Hostsystem oder Kenntnis der Container-Layer. Sie können einem Container beispielsweise eine SBOM beifügen, indem Sie sie mit BuildKit erzeugen.
  (Siehe: Docker Blog – „Generate SBOMs with BuildKit“)

• Eine SBOM auswerten bzw. scannen: Nutzt die SBOM-Textdatei und eine fortlaufend aktualisierte Schwachstellendatenbank. Dabei werden die Kennungen der SBOM mit denen der Datenbank abgeglichen, um potenzielle Schwachstellen zu erkennen.

Schwachstellenmanagement verstehen

Ein zentraler Baustein jeder sicheren Software-Lieferkette ist klare Sichtbarkeit erkannter Schwachstellen. Ein wirksamer Schwachstellenmanagement-Prozess hilft Organisationen, ihre Sicherheitslage zu stärken und Risiken zu senken.

Ziele des Schwachstellenmanagements:

1. Frühzeitige Erkennung:
   Schwachstellen bereits während der Entwicklung erkennen, um Auswirkungen und Kosten zu verringern.

2. Kontinuierliches Monitoring:
   Code und Infrastruktur regelmäßig scannen, um neue Schwachstellen aufzuspüren.

3. Priorisierung:
   Risiken bewerten, um sich zuerst auf die kritischsten Schwachstellen zu konzentrieren.

4. Automatisierte Behebung:
   Schwachstellen automatisch beheben, um schneller zu reagieren und Konsistenz sicherzustellen.

5. Compliance und Reporting:
   Die Einhaltung von Standards sicherstellen und Transparenz über den Sicherheitsstatus schaffen.

Wie SBOM-Scanning im DevOps-Lebenszyklus funktioniert

SBOM-Scanning in jeder Entwicklungsphase zu verankern, stärkt die Sicherheit und sichert die Compliance. Hier ein Überblick über die wichtigsten Phasen:

Software Composition Analysis (SCA)

Software Composition Analysis automatisiert Anwendungssicherheit, indem sie Drittanbieter- und Open-Source-Komponenten in der Codebasis verwaltet. SCA erkennt Schwachstellen in diesen Komponenten, mindert Risiken wie Supply-Chain-Angriffe und liefert Lizenzinformationen. Eine frühe Einführung von SCA hilft, Sicherheitsrisiken zu senken.

Wird SBOM-Scanning in die integrierte Entwicklungsumgebung (IDE) eingebunden, können Entwickler Schwachstellen bereits beim Programmieren erkennen, indem die IDE mit dem Paketmanager der Sprache zusammenspielt. Praktiken wie Git Hooks, Code-Linting und Secrets-Management ergänzen diesen Prozess.

Container-Scanning

Container sind zur wichtigsten Methode geworden, Anwendungen zu paketieren und auszurollen. Container-Scanning konzentriert sich auf:

• Erkennen unsicherer Container (etwa veraltete Bibliotheken, Fehlkonfigurationen, überholte Betriebssysteme)

• Prüfen der Compliance

• Empfehlen von Best Practices

Hinweis: Die Tiefe der Scan-Ergebnisse unterscheidet sich je nach Werkzeug. Manche Organisationen setzen auf Distroless-Basis-Images oder kostenpflichtige Dienste, die schwachstellenfreie Container-Registries anbieten.

Hier eine kleine Grafik dazu, wann im Container-Lebenszyklus zu scannen ist und worauf zu achten:

Quelle

Image- und Artefakt-Repositories

Wenn Images während der CI in eine Registry gepusht werden, sind sie zunächst frei von bekannten Schwachstellen. Da sich die Bedrohungslage jedoch weiterentwickelt, ist fortlaufendes Scannen der Registry unerlässlich. Sobald neue Schwachstellen priorisiert wurden, lassen sich Images markieren oder Behebungsmaßnahmen auslösen.

Produktivbetrieb

Regelmäßiges Scannen in der Produktion ist entscheidend, da Schwachstellen auch nach dem Deployment entdeckt werden können. Wer sich allein auf Scans in der Build-Phase verlässt, lässt eine Lücke, die kontinuierliches Monitoring im Betrieb schließt.

Wichtige Überlegungen sind:

• Welche Maßnahmen ergreifen, wenn in einem Container oder auf einem Host eine Schwachstelle gefunden wird?

• Wie mit Laufzeit-Schwachstellen umgehen (etwa Container beenden oder isolieren)?

• Methoden, um einen verwundbaren Dienst zu isolieren.

Eine kritische Schwachstelle erfordert womöglich ein sofortiges Redeployment mit gepatchtem Image, während weniger schwerwiegende Fälle beobachtet und im nächsten Wartungsfenster behoben werden. In Kubernetes-Umgebungen können Strategien wie Pod Disruption Budgets, Canary Deployments oder Traffic Shifting die Ausfallzeit während der Behebung minimieren.

Compliance und Reporting

SBOM-Scanning erkennt nicht nur Schwachstellen, sondern unterstützt auch die Einhaltung regulatorischer und interner Vorgaben, indem es:

1. Ein zentrales SBOM-Inventar schafft:
   – SBOM-Erstellung bei jedem Build bzw. Deployment automatisieren und Artefakte zentral ablegen.
   – Audits durch klare Aufzeichnungen der Softwarekomponenten vereinfachen.

2. An Standards ausrichtet:
   – Fortlaufende Compliance mit Rahmenwerken wie NIST, ISO 27001 oder PCI DSS belegen, indem SBOM-Ergebnisse auf die geforderten Controls abgebildet werden.
   – Berichte für Security-Reviews oder Audits verschlanken.

3. Automatisierte Alerts und Dashboards bereitstellt:
   – SBOM-Scanning mit Projektmanagement- und Alerting-Systemen verbinden.
   – Übergeordnete Kennzahlen (etwa Schwachstellen im Zeitverlauf) samt detaillierter Aufschlüsselung für die Teams darstellen.

4. Echtzeitberichte und Audit-Trails liefert:
   – Berichte mit gefundenen Schwachstellen, Behebungsmaßnahmen und Zeitleisten erzeugen.
   – Nachweise für kontinuierliches Sicherheitsmonitoring gegenüber Aufsicht und Stakeholdern erbringen.

5. Nachweise für rechtliche und regulatorische Anforderungen sichert:
   – SBOMs, Scan-Logs und Vorfallberichte archivieren, um bei Audits oder der Untersuchung von Sicherheitsvorfällen die gebotene Sorgfalt zu belegen.

Wer SBOM-Scanning in seinen DevOps-Workflow einbettet, sichert sich durchgängige Sichtbarkeit, schnelle Behebung und klare Dokumentation – die tragenden Säulen einer robusten, konformen Software-Lieferkette.

Kurzer Überblick über SBOM-Werkzeuge im DevOps-Lebenszyklus

Eine Reihe von Werkzeugen kann SBOMs erzeugen und auswerten, Scans in CI/CD-Pipelines einbinden und Schwachstellen fortlaufend überwachen. Die Auswahl hängt von Ihrem Technologie-Stack, Ihrer Container-Strategie, Ihren Integrationsanforderungen und organisatorischen Rahmenbedingungen ab.

Ausgewählte Werkzeuge:

• Trivy: Open Source; einheitliches Scannen auf Schwachstellen, IaC-Fehlkonfigurationen und Secrets; einfache CLI; breite Abdeckung von Ressourcen.

• Syft: Open Source; spezialisiert auf das Erzeugen von SBOMs.

• Grype: Open Source; spezialisiert auf das Auswerten von SBOMs.

• DependencyTrack: Open Source; auf den CycloneDX-Standard ausgerichtet, mit konformem Reporting.

• Snyk: Kommerziell; entwicklerfreundlich mit umfangreichen Integrationen.

Quellen:
• Trivy GitHub Repository
• Syft GitHub Repository
• Grype GitHub Repository
• DependencyTrack GitHub Repository
• Snyk CLI GitHub

Trivy mit k3d in der Praxis

Voraussetzungen:

• Docker installiert

• k3d installiert

• kubectl installiert

• Helm installiert

1. Eine k3d-Cluster-Konfiguration anlegen

Erstellen Sie eine eigene Konfigurationsdatei namens k3d-config.yaml mit folgendem Inhalt:

Den Cluster erstellen

Der Trivy-Operator benötigt mindestens 500 MB RAM; um OOM-Fehler zu vermeiden, werden die Nodes mit 1 GB Speicher konfiguriert.

Prüfen Sie, ob der Cluster läuft:

2. Den Trivy-Operator installieren

Fügen Sie das Helm-Chart-Repository von Aqua Security hinzu und aktualisieren Sie es:

Installieren Sie den Trivy-Operator:

Prüfen Sie, ob der Operator läuft:

Sie sollten eine Ausgabe wie diese sehen:

3. Eine Testanwendung mit bekannten Schwachstellen ausrollen

Erstellen Sie eine Datei namens deployment.yaml mit folgendem Inhalt:

Wenden Sie das Deployment an:

Prüfen Sie die Pods (bei einem eigenen Namespace entsprechend anpassen):

4. Die Schwachstellenberichte prüfen

4.1 Die Berichte auflisten:

oder

Sie sollten einen Bericht wie diesen sehen:

4.2 Einen bestimmten Bericht ansehen:

Zum Beispiel:

Angezeigt werden Details wie das Image (etwa nginx:1.14.2), CVE-IDs, Schweregrad, Paketversionen und verfügbare Fixes.

5. SBOMs (Software Bill of Materials) ansehen

SBOM-Berichte auflisten:

Einen SBOM-Bericht ansehen:

6. Aufräumen

Zum Aufräumen der Umgebung führen Sie aus:

7. Repository-Struktur

Eine vorgeschlagene Struktur für das Demo-Projekt:

8. Zusammenfassung

In dieser Demo haben Sie:

1. einen lokalen Kubernetes-Cluster mit k3d erstellt.

2. den Trivy-Operator für Schwachstellen- und SBOM-Scans installiert.

3. einen verwundbaren nginx-Container ausgerollt.

4. die Schwachstellenberichte und SBOMs geprüft.

Dieses Setup zeigt SBOM- und Schwachstellen-Scanning in Echtzeit in einer produktionsnahen Umgebung.

Wie sieht die Zukunft von SBOMs aus?

(Quelle: https://scribesecurity.com/blog/insights-from-cisa-new-guide-the-future-of-sbom/)

SBOMs entwickeln sich mit dem modernen Computing weiter; mehrere Trends zeichnen sich ab:

• Automatisierung und Integration:
  Neue SBOM-Spielarten (etwa ML-BOM für Machine-Learning-Werkzeuge) werden stark auf Automatisierung setzen.

• Erweiterte BOM-Typen:
  Neue Formate wie KBOM (Kubernetes BOM), IBOM (Infrastructure BOM) und weitere entstehen, um komplexe Softwarestrukturen besser zu kategorisieren und zu priorisieren.
  (Siehe: KBOM)

• Standardisierung in der Branche:
  Laufende Bemühungen, SBOM-Formate zu standardisieren (etwa CycloneDX), werden den Datenaustausch und die Interpretation im gesamten Software-Ökosystem vereinfachen.

• Neuerungen bei CycloneDX:
  Projekte unter dem Dach von CycloneDX entwickeln spezialisierte BOMs (etwa HBOM, OBOM) und arbeiten an neuen Wegen, Schwachstelleninformationen auszuwerten und auszutauschen, darunter:

  • Vulnerability Exploitability eXchange (VEX)

  • Vulnerability Disclosure Report (VDR)

  • Bill of Vulnerabilities (BOV)

  • BOM-Link

• Cryptographic BOM (CBOM):
  Eine wichtige Entwicklung, um Sicherheit in einer Post-Quanten-Welt zu gewährleisten.