Workflow Integration

Sobald der BOMnipotent-Server läuft, können Sie mit dem Hochladen von Dokumenten beginnen. Ein typischer Workflow beginnt mit der Erstellung eines SBOM, einer Inventarliste der Komponenten, die Ihr Produkt enthält. Dieser Schritt sollte automatisch ausgelöst werden, sobald eine neue Version erstellt wird. Anschließend wird dieses Inventar auf bekannte Sicherheitslücken überprüft. Auch dieser Schritt sollte automatisch erfolgen, jedoch in regelmäßigen Abständen.

Falls eine Sicherheitslücke entdeckt wird, muss sie analysiert werden. Diese Aufgabe erfordert Fachwissen und kann daher nicht automatisiert werden. Das Ergebnis dieser Analyse ist ein CSAF-Dokument, das Ihren Nutzern mitteilt, ob und wie sie auf diese neue Entwicklung reagieren müssen.

Dieser Abschnitt enthält Anleitungen für einen beispielhaften Workflow zur Erstellung einer SBOM mit Syft , Überprüfung auf Sicherheitslücken mit Grype , und Erstellung von CSAF Dokumenten mit Secvisogram . Es gibt auch andere Programme für diese Aufgaben. Solange sie gültige CycloneDX- und CSAF-JSON-Dokumente erzeugen, sind sie mit BOMnipotent kompatibel.

Unterabschnitte von Workflow Integration

SBOM-Generierung mit Syft

Eine Software Bill of Materials (SBOM) ist eine Liste aller Softwarekomponenten, die in deinem Produkt verwendet werden. Im Kontext der Lieferkettensicherheit dient sie als maschinenlesbare Liste von Elementen, mit der neue Schwachstellen abgeglichen werden können, sobald sie bekannt werden.

Es gibt mehrere Tools zur automatischen Erstellung einer solchen SBOM. Dieses Tutorial konzentriert sich auf Syft von Anchore, einem Open-Source-Kommandozeilentool.

Einrichtung

Das offizielle Syft GitHub Repository enthält Installationsanweisungen. Die Installation ist über ein Shell-Skript oder verschiedene Paketmanager möglich.

Auf manchen Linux-Systemen sollten Sie den Installationspfad (das letzte Argument des Shell-Befehls) auf “~/.local/bin” ändern, da für Änderungen an “/usr/local/bin” Root-Rechte erforderlich sind.

Verwendung

Die grundlegende Verwendung von Syft lautet:

syft <Ziel> [Optionen]

Zusätzlich lassen sich einige Konfigurationen über Umgebungsvariablen vornehmen.

Syft unterstützt Lockfiles, Verzeichnisse, Container-Images und weitere Zieltypen.

Lockfile

Ein Beispielaufruf sieht folgendermaßen aus:

​
SYFT_FORMAT_PRETTY=1 syft Cargo.lock --output cyclonedx-json=./sbom.cdx.json --source-name="BOMnipotent" --source-version="1.0.0"
SYFT_FORMAT_PRETTY=1 syft Cargo.lock -o cyclonedx-json=./sbom.cdx.json --source-name="BOMnipotent" --source-version="1.0.0"

Erklärung:

  • ‘SYFT_FORMAT_PRETTY=1’ setzt eine Umgebungsvariable, die Syft anweist, durch Menschen besser lesbare Ausgabe zu produzieren. Eine vollständige Liste der Konfigurationen befindet sich hier .
  • ‘syft’ ruft das Syft-Programm auf.
  • ‘Cargo.lock’ gibt an, dass Syft die Lockfile-Datei des Rust-Ökosystems analysieren soll.
  • ‘–output cyclonedx-json=./sbom.cdx.json’ legt fest, dass die Ausgabe im CycloneDx JSON-Format in der Datei ‘./sbom.cdx.json’ gespeichert wird.
  • ‘–source-name=“BOMnipotent”’ gibt an, dass diese Quellen zu der Komponente BOMnipotent gehören, was Syft nicht in allen Fällen automatisch erkennen kann.
    • Das CycloneDX-Schema erfordert möglicherweise keinen Komponentennamen, aber BOMnipotent benötigt ihn.
  • ‘–source-version=“1.0.0”’ gibt Syft die aktuelle Version des Projekts an.
    • Falls keine Version angegeben wird, versucht BOMnipotent, stattdessen den Zeitstempel als Versionszeichenkette zu verwenden.

Syft unterstützt eine Vielzahl von Ökosystemen, welche in Ihrem GitHub repo aufgelistet sind.

Verzeichnis

Syft kann auf ein ganzes Verzeichnis angewendet werden, allerdings ist das oft übertrieben. Es durchsucht alle Unterverzeichnisse und erfasst alles, was entfernt wie eine Lockfile aussieht, einschließlich aller Testabhängigkeiten, Entwicklungsskripte und GitHub Actions.

​
syft . --output cyclonedx-json=./dev_env_sbom.cdx.json --source-name="BOMnipotent Entwicklungsumgebung" --source-version=1.2.3
syft . -o cyclonedx-json=./dev_env_sbom.cdx.json --source-name="BOMnipotent Entwicklungsumgebung" --source-version=1.2.3

Container

Falls Sie einen Docker-Container als ‘.tar’-Datei exportiert haben, können Sie diesen ebenfalls als Ziel angeben:

​
syft container.tar --output cyclonedx-json=./container_sbom.cdx.json --source-name="BOMnipotent Container" --source-version=1.2.3
syft container.tar -o cyclonedx-json=./container_sbom.cdx.json --source-name="BOMnipotent Container" --source-version=1.2.3

Bei kompilierten Sprachen können die Ergebnisse stark abweichen, da die meisten Informationen über die Komponenten, die in die Kompilierung eingeflossen sind, verloren gehen. Andererseits enthält diese SBOM Informationen über die Umgebung, in der das Produkt später möglicherweise ausgeführt wird.

Abschließende Bemerkungen

Bei der Auswahl eines Ziels ist es wichtig, den Umfang der Anwendung zu berücksichtigen: Was wird an den Kunden ausgeliefert? In welchem Umfang sind Sie für die Lieferkette des Produkts verantwortlich? Bei Unentschlossenheit spricht nichts dagegen, mehrere Varianten einer SBOM hochzuladen – solange der Produktname oder die Version unterschiedlich ist.

Sobald die SBOM generiert ist, kann sie mit dem BOMnipotent Client auf dem BOMnipotent Server hochgeladen werden.

Danach können Sie Grype nutzen, um regelmäßig nach Sicherheitslücken zu scannen .

Sicherheitslücken entdecken mit Grype

Sobald Ihre SBOM (Software Bill of Materials) erstellt wurde, ist es an der Zeit, sie kontinuierlich auf Schwachstellen zu scannen. Beachten Sie, dass einige Gesetze, wie beispielsweise der Cyber Resilience Act der EU, vorschreiben, dass Produkte ohne bekannte Schwachstellen veröffentlicht werden. Der erste Scan sollte daher vor einer Veröffentlichung erfolgen.

Es gibt verschiedene Tools zur Überprüfung eines Produkts auf Schwachstellen in der Lieferkette. Dieses Tutorial verwendet Grype von Anchore, da es sich gut mit Syft von Anchore aus dem SBOM tutorial integriert. Genau wie Syft ist Grype ein Open-Source-Befehlszeilenprogramm.

Einrichtung

Das offizielle Grype GitHub Repository enthält Installationsanweisungen. Ähnlich wie bei Syft können Sie den Installationspfad (das letzte Argument des Shell-Befehls) auf ‘~/.local/bin’ ändern, da ‘/usr/local/bin’ Root-Berechtigungen zum Ändern erfordert.

Verwendung

Sobald eine SBOM vorliegt, ist das Scannen auf Schwachstellen sehr einfach:

​
grype sbom:./sbom.cdx.json --fail-on low
grype sbom:./sbom.cdx.json -f low
​
 ✔ Scanned for vulnerabilities     [2 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 2 medium, 0 low, 0 negligible
   └── by status:   2 fixed, 0 not-fixed, 0 ignored 
NAME    INSTALLED  FIXED-IN  TYPE        VULNERABILITY        SEVERITY 
ring    0.17.8     0.17.12   rust-crate  GHSA-4p46-pwfr-66x6  Medium    
rustls  0.23.15    0.23.18   rust-crate  GHSA-qg5g-gv98-5ffh  Medium
[0000] ERROR discovered vulnerabilities at or above the severity threshold

Beim Ausführen dieses Befehls überprüft Grype mehrere Schwachstellendatenbanken auf Übereinstimmungen mit den im SBOM angegebenen Komponenten. Die Option ‘fail-on’ sorgt dafür, dass das Programm mit einem Fehlercode ungleich null beendet wird, falls eine Schwachstelle mit mindestens der angegebenen Schwere ’low’ gefunden wird.

Die Syntax zum Exportieren eines Schwachstellenberichts, der von BOMnipotent verarbeitet werden kann, ist ähnlich wie bei Syft:

​
grype sbom:./sbom.cdx.json --output cyclonedx-json=./vuln.cdx.json
grype sbom:./sbom.cdx.json -o cyclonedx-json=./vuln.cdx.json

Grype lässt sich leicht mit BOMnipotent kombinieren. Sie können das “bom get” Kommando von BOMnipotent Client verwenden, um den Inhalt einer BOM direkt in die Konsole ausgeben zu lassen, und diesen dann an Grype weitergeben:

​
bomnipotent_client bom get <BOM-NAME> <BOM-VERSION> | grype --output cyclonedx-json=./vuln.cdx.json
bomnipotent_client bom get <BOM-NAME> <BOM-VERSION> | grype -o cyclonedx-json=./vuln.cdx.json