Software-Lieferkette im Griff: SBOMs unter Debian 13 mit debsbom und sbom-auditor analysieren

  Pierre   Lesezeit: 3 Minuten Auf Mastodon ansehen

Wie wir die neuen ENISA-Empfehlungen zur Software Bill of Materials (SBOM) auf unserem Linux-System konkret in die Praxis umsetzen.

software-lieferkette im griff: sboms unter debian 13 mit debsbom und sbom-auditor analysieren

Die Transparenz von Software-Lieferketten ist längst von einer Nischendiskussion zu einem zentralen IT-Sicherheitsstandard geworden. Mit dem bevorstehenden Inkrafttreten europäischer Regularien wie dem Cyber Resilience Act (CRA) und DORA stehen Organisationen und Entwicklerteams vor der Aufgabe, nachvollziehbar offenzulegen, welche Komponenten in ihrer Software und ihren Systemen verbaut sind.

Die EU-Cybersicherheitsbehörde ENISA hat hierfür im Technical Advisory v1.10 ein umfassendes Framework vorgelegt. Welchen praktischen Mehrwert das bietet und wie wir mit quelloffenen Werkzeugen unter Debian 13 (Trixie) in wenigen Minuten eine eigene System-SBOM erstellen und analysieren, schauen wir uns in diesem Artikel an.

ENISA-Leitfaden: Was bedeuten die Vorgaben für die Praxis?

ENISA teilt die Einführung eines SBOM-Programms in strukturierte Phasen ein — von der Initiierung über die Planung bis zur Ausführung und Überwachung. Ein Auswertungsschwerpunkt (unter anderem beleuchtet durch Sicherheitsexperten von FOSSA) hebt dabei folgende Kernpunkte hervor:

  • Sichtbarkeit schlägt Geheimhaltung: Ein häufig geäußertes Bedenken ist die Befürchtung, durch die Veröffentlichung von SBOMs geistiges Eigentum oder Angriffsflächen preiszugeben. ENISA stellt klar: Angreifer können Abhängigkeiten ohnehin mittels automatisierter Scanner analysieren. Ohne eigene SBOM bleiben jedoch vor allem wir selbst gegenüber den Risiken in unseren eigenen Systemen blind.

  • Standardisierung: Die beiden dominierenden Formate sind CycloneDX (stark im Bereich Security/Vulnerability-Management) und SPDX (traditionell stark bei Lizenzkonformität). ENISA empfiehlt, Werkzeuge einzusetzen, die flexibel mit beiden Formaten umgehen können.

  • Automation im Build-Prozess: Eine SBOM ist kein statisches Dokument für die Schublade, sondern muss kontinuierlich bei Systemänderungen oder Software-Builds (z. B. via CI/CD) aktualisiert werden.

SBOM-Erstellung und -Audit unter Debian 13

Schauen wir uns an, wie wir diese Empfehlungen direkt auf einem Debian 13 (Trixie)-System umsetzen. Wir nutzen dabei zwei Werkzeuge aus dem Open-Source-Ökosystem:

  1. debsbom zur Generierung der SBOM aus der Debian-Paketdatenbank.
  2. sbom-auditor (ein in Rust geschriebenes Werkzeug) zur visuellen Aufbereitung und Sicherheitsanalyse.

Schritt 1:

Systemvorbereitung und debsbom installieren Zunächst stellen wir sicher, dass unser Debian 13-System auf dem aktuellen Stand ist und die benötigten Werkzeuge installiert sind.

sudo apt update && sudo apt upgrade -y sudo apt install -y debsbom cargo git

Hinweis: debsbom liest die installierten Debian-Pakete (dpkg-Datenbank) aus und generiert daraus eine standardkonforme SBOM im CycloneDX-Format.

Schritt 2:

SBOM unseres Debian-Systems generieren Nun erstellen wir eine SBOM für das gesamte System oder für ein bestimmtes Paket-Set. Wir speichern das Ergebnis als JSON-Datei im CycloneDX-Format ab:

debsbom > debian13-system-sbom.json

Wir können die generierte Datei kurz überprüfen, um zu sehen, wie die strukturierten Metadaten (Paketnamen, Versionen, Lizenzen, Maintainer) abgebildet sind:

head -n 20 debian13-system-sbom.json

Schritt 3:

Installation von sbom-auditor und Sicherheitsaudit Um die generierte SBOM nicht nur als unleserlichen JSON-Baum vorliegen zu haben, sondern auditieren und visualisieren zu können, nutzen wir das Tool sbom-auditor (crates.io/crates/sbom-auditor). Da wir cargo im ersten Schritt installiert haben, installieren wir sbom-auditor direkt aus der Crates.io-Registrierstelle:

cargo install sbom-auditor

Nachdem die Kompilierung abgeschlossen ist, führen wir das Audit für unsere eben erstellte debian13-system-sbom.json aus:

sbom-auditor audit --file debian13-system-sbom.json

Möchten wir eine interaktive Weboberfläche zur Analyse der Abhängigkeiten und Schwachstellen starten, führen wir folgenden Befehl aus:

sbom-auditor serve --file debian13-system-sbom.json --port 8080

Nun öffnen wir unseren Browser unter http://localhost:8080 und können die gesamte Komponentenlandschaft unseres Debian 13-Systems durchsuchen, Lizenzen filtern und Schwachstellen identifizieren.

Fazit & Ausblick

Die Vorgaben der ENISA zeigen deutlich, wohin die Reise im Bereich IT-Sicherheit und Software-Supply-Chain geht. Was auf den ersten Blick nach bürokratischem Mehraufwand aussieht, lässt sich mit den richtigen Open-Source-Tools nahtlos in den Linux-Alltag integrieren. Mit der Kombination aus debsbom und sbom-auditor steht uns unter Debian 13 ein mächtiges, lokales Gespann zur Verfügung, mit dem wir ohne Abhängigkeit von proprietären Cloud-Diensten volle Transparenz über unsere Systeme behalten.

Titelbild: https://www.enisa.europa.eu/sites/default/files/2026-10/ENISA%20Technical%20Advisory%20-%20Software%20Bill%20of%20Materials%20-%20v1.10.pdf

Quellen:
ENISA Technical Advisory - Software Bill of Materials (v1.10)
FOSSA Blog: Highlights ENISA SBOM Guide
debsbom Manpage & Repository
sbom-auditor auf crates.io

Tags

SBOM, Schwachstelle, Analyse

Es wurden noch keine Kommentare verfasst, sei der erste!