Woher kommt Ihre Software? SBOM, SLSA und Unterzeichnung

Wenn wir über Software-Sicherheit sprechen, denken wir meist an unseren eigenen Code. Ist es verwundbar? Haben wir den Eingang überprüft? Aber das meiste, was wir versenden, ist nicht unser Code. Es sind Open-Source-Bibliotheken, Basisbilder, Build-Tools, CI-Aktionen und ihre Abhängigkeiten und Abhängigkeits-Abhängigkeiten.

Die Angreifer haben es bemerkt. Statt in eine Firma einzubrechen, zielen sie auf etwas ab, das Tausende von Unternehmen benutzen. Die XZ Utils Backdoor, die im Jahr 2024 gefunden wurde, die gehackte GitHub Action im Jahr 2025 und der sich selbst verbreitende npm-Wurm Shai-Hulud: alle Beispiele für Angriffe auf die Lieferkette.

Drei Ideen sind zur Grundlage der Abwehr geworden: SBOMs, Signatur und SLSA.

Warum das plötzlich wichtig ist

Es gibt drei Gründe:

1. Die Angriffe nehmen zu., und sie werden immer anspruchsvoller.
2. Die Regulierung kommt. Das EU-Cyber-Resilience Act, die US-Bundesvorschriften und die Industriestandards verlangen zunehmend, dass Sie wissen, was in Ihrer Software steckt und nachweisen, woher sie stammt.
3. Die Kunden fragen nach. "Können Sie ein SBOM bereitstellen?" ist heute eine Standardfrage in Sicherheitsfragebögen.

SBOM: eine Zutatenliste für Software

A Software-Materialbuch (SBOM) ist eine Liste aller Komponenten in Ihrer Software: Bibliotheken, Versionen, Lizenzen und woher sie kamen. Wie die Zutatenliste auf Lebensmittelverpackungen.

Warum hilft es: Wenn eine neue Sicherheitsanfälligkeit wie Log4Shell angekündigt wird, können Sie in Minuten statt Tagen "Sind wir betroffen?" beantworten, indem Sie Ihre SBOMs durchsuchen.

Die beiden wichtigsten Formate sind CycloneDX und SPDX- Ich weiß . Eine zu erzeugen ist einfach:

syft registry.example.com/shop-api:1.4.2 -o cyclonedx-json > sbom.json
trivy image --format spdx-json -o sbom.spdx.json registry.example.com/shop-api:1.4.2

Erstellen Sie SBOMs in CI für jede Version, speichern Sie sie neben dem Artefakt (oder fügen Sie sie dem Bild in der Registrierung an) und scannen Sie sie regelmäßig auf neue Schwachstellen.

Eine SBOM macht Ihre Software nicht sicher. Es macht deine Unwissenheit sichtbar, und da beginnt die Sicherheit.

Unterzeichnung mit Sigstore und Cosign

Ein SBOM sagt dir, was drin ist. Unterschrift Sie sagt, wer es gebaut hat und dass es danach niemand geändert hat.

Sigstore ist ein Open-Source-Projekt (unter dem OpenSSF), das die Signatur praktisch gemacht hat. Sein Werkzeug Mitunterzeichnung Schilder, Bilder und andere Artefakte. Das Klüge ist: Schlüssellose Unterschrift: anstelle der Verwaltung langlebiger privater Schlüssel wird die Identität Ihres CI (wie ein GitHub Actions OIDC-Token) verwendet, um ein kurzlebiges Zertifikat zu erhalten, und die Signatur wird in einem öffentlichen Transparenzprotokoll aufgezeichnet.

# In CI, with OIDC available
cosign sign registry.example.com/shop-api@sha256:abc123...

# Anywhere, to verify
cosign verify registry.example.com/shop-api@sha256:abc123... \
  --certificate-identity-regexp "https://github.com/acme/shop-api/.*" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

Die Überprüfung besagt: dieses genaue Bild wurde von einem Workflow im acme/shop-api - Das ist ein Repository. Wenn jemand ein anderes Bild unter demselben Tag schiebt, scheitert die Verifizierung.

Überprüfung zum Zeitpunkt der Bereitstellung ist, wo sich das Unterzeichnen wirklich auszahlt. Eintrittskontrolleure wie Kürbis, Sigstore-Verantwortlicher für die Politik oder - Ich weiß. Sie können unsignierte oder falsch signierte Bilder im Kubernetes-Cluster blockieren.

SLSA-Werte, einfach

SLSA (Supply-Chain Levels for Software Artifacts, ausgesprochen "Salsa") ist ein Framework, das beschreibt, wie vertrauenswürdig Ihr Bauprozess ist. Es konzentriert sich auf HerkunftEine unterschriebene Aufzeichnung, wie ein Artefakt gebaut wurde, aus welcher Quelle, von welchem Baumeister.

Vereinfacht sind die Bausteine:

• Stufe 1: Herkunft besteht. Sie dokumentieren, wie das Artefakt gebaut wurde.
• Stufe 2: die Herkunft wird nicht von Hand, sondern von einer gehosteten Build-Plattform generiert und signiert.
• Stufe 3: die Bauplattform ist gehärtet, so dass Bauten isoliert sind und die Herkunft nicht einmal von den eigenen Instandhaltungsarbeitern des Projekts gefälscht werden kann.

Mit GitHub-Aktionen kann SLSA-Ausgang generiert werden Bescheinigungen über Artefakte (actions/attest-build-provenance) und der Die Datenbank ist nicht mehr verfügbar. Das Projekt bietet Bauherren der Stufe 3. Docker BuildKit kann auch die Herkunft von Bildern angeben.

Ich habe es zusammengestellt .

Eine praktische Pipeline:

1. Das Bild in CI (hosted, ephemeral runners) erstellen.
2. Erstellen Sie eine Die SBOM und es an das Bild anbringen.
3. Erstellen Herkunft (SLSA-Bestätigung).
4. Zeichen Das Bild mit Cosign, schlüssellos.
5. Scannen die SBOM für Schwachstellen kontinuierlich.
6. Überprüfen Unterschriften und Herkunft im Cluster, bevor irgendetwas läuft.

Jeder Schritt ist ein paar Zeilen der heutigen KI-Konfiguration. Vor ein paar Jahren war das ein Forschungsprojekt.

Also, wo fange ich an?

Erstellen Sie SBOMs für Ihre Hauptbilder in dieser Woche. Dann schlüssellose Signatur. Dann prüfen Sie die Signaturüberprüfung in einem nichtproduktiven Cluster. Sobald das funktioniert, bringen Sie es in die Produktion. Sie werden den meisten Unternehmen voraus sein und bereit für die Regulierungen, die auf Sie zukommen.

Meine Meinung: Man kann nicht sichern, was man nicht sehen kann, und man kann nicht trauen, was man sich nicht überprüfen kann. SBOMs geben dir Augenlicht, Unterschriften geben dir Vertrauen.

Desly