Lieferkette: Nachweise und Pflichten — Cheat Sheet

Das Blatt für den Moment, in dem jemand einen Nachweis verlangt: Was steckt im Artefakt, woher stammt es, wer steht dafür gerade, und welche Frist läuft gerade. Maßgeblich sind die Originalquellen — SLSA 1.2, SPDX, CycloneDX, Sigstore Cosign und der Cyber Resilience Act.

Die erste Hälfte des Seminars — Angriffspfade, Repository-Schutz, Paketquellen, Scanverfahren und Pipeline-Rechte — liegt auf dem Blatt Lieferkette: Risiken und Härtung. Für Dockerfile, Cache und rootless-Betrieb siehe Container, Images und Lieferkette.

Was zu einem ausgelieferten Artefakt gehört

Ohne Quellrevision am Artefakt beginnt jede Untersuchung mit der Frage, welcher Stand überhaupt läuft. Die Aufbewahrungsfrist richtet sich nach dem Supportzeitraum des Produkts, nicht nach dem Platz auf der Ablage — und Build- Protokolle verfallen oft nach Wochen, während Untersuchungen länger dauern.

Modul: Reproduzierbare und nachvollziehbare Builds

SBOM: Angaben je Komponente

Externe Bezeichner wie Package URL und CPE verbinden die Komponente mit den Schwachstellendatenbanken. Was nicht ermittelbar war, gehört ausdrücklich als unbekannt markiert — eine Lücke, die als Lücke dasteht, ist etwas anderes als eine verschwiegene.

Modul: Grundlagen der Software Bill of Materials

Drei Erzeugungspunkte, drei Wahrheiten

Für den Betreiber zählt das Image, für die Ursachensuche der Quellstand — deshalb lohnen beide. Die Differenzen sind kein Fehler, sondern die Information.

Modul: Grundlagen der Software Bill of Materials

SPDX und CycloneDX nebeneinander

Die Wahl fällt selten frei — meist gibt der Empfänger das Format vor, und dann werden beide gebraucht.

mvn org.cyclonedx:cyclonedx-maven-plugin:makeBom   # aus dem Projekt
syft <image>:<tag> -o spdx-json=sbom.spdx.json     # aus dem Image
cyclonedx validate --input-file target/bom.json    # gegen das Schema

Erzeugen und Validieren gehören in denselben Schritt: Eine ungeprüfte Stückliste fällt sonst erst beim Empfänger auf. Beim Vergleich zweier Releases ist die ernsteste Beobachtung gleiche Version, andere Prüfsumme — sie steht in keinem Änderungsprotokoll.

Modul: SPDX und CycloneDX praktisch einsetzen

Vier Fragen an einen Schwachstellentreffer

Die dritte Frage kann nur das eigene Team beantworten — sie ist die teuerste und die wertvollste. Erster Schnitt vor jeder Bewertung: Treffer in Testabhängigkeiten von denen in Produktionscode trennen.

Modul: Schwachstellenmanagement mit SBOM und VEX

VEX: drei Aussagen und ihre Voraussetzung

Tragfähige Begründungen für „nicht betroffen”: Der verwundbare Code ist gar nicht enthalten · er wird von keinem Pfad erreicht · die Ausnutzung setzt eine Konfiguration voraus, die hier nicht vorliegt · eine vorgelagerte Maßnahme verhindert sie. Ohne Termin wird „in Prüfung” ein Dauerzustand, der die Liste unbrauchbar macht.

Modul: Schwachstellenmanagement mit SBOM und VEX

Prüfsumme, Signatur, Attestierung

Deshalb hängt alles daran, wer die Attestierung erzeugt — nicht daran, dass es eine gibt. Beim schlüssellosen Signieren stellt Fulcio nach Prüfung des OIDC-Tokens ein kurzlebiges Zertifikat aus, der private Schlüssel wird nach Gebrauch vernichtet, und Rekor bezeugt den Vorgang mit Zeitstempel.

cosign sign --yes <registry>/<image>@sha256:<digest>

cosign verify \
  --certificate-identity=<erwartete-identitaet> \
  --certificate-oidc-issuer=<erwarteter-aussteller> \
  <registry>/<image>@sha256:<digest>

Ohne die beiden Erwartungsangaben bestätigt die Prüfung nur, dass überhaupt jemand signiert hat. Signiert wird immer der Digest, nie ein Tag.

Modul: Signaturen, Attestierungen und Provenance

Was in einer Provenance steht

Erst wenn alle vier Zeilen eine Erwartung haben, ist die Verifikation mehr als eine Formsache.

Erst der zweite Prüfpunkt macht aus der Signatur eine Bedingung statt eines Hinweises. Ablehnungsfall und Notfallweg gehören vorher festgelegt — sonst wird die Regel beim ersten Störfall dauerhaft abgeschaltet.

Modul: Signaturen, Attestierungen und Provenance · Container, Registry und Deployment absichern

SLSA: zwei Spuren, zwei Skalen

Der Source Track hat vier Stufen, der Build Track drei. Technische Kontrollen wirken erst ab ihrer Aktivierung — eine Lücke setzt die bezeugte Historie zurück. Stufen gelten je Artefakt und Repository, nicht je Unternehmen.

Gefordert ist Isolation: kein geteilter Zustand, kein vergifteter Cache, keine Nachwirkung auf den Folgelauf.

Modul: SLSA 1.2 in der Praxis · Reproduzierbare und nachvollziehbare Builds

Meldung: Rollen und Fristen

Die rechte Spalte lässt sich nur vorher herstellen. Im Ernstfall merkt man lediglich, dass sie fehlt.

Gemeldet wird über die zentrale Meldeplattform an das zuständige CSIRT, zugleich geht die Information an ENISA. Die Uhr läuft ab Kenntnis, nicht ab Klarheit — die Frühwarnung verlangt keine fertige Analyse. Meldepflichtig sind aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, nicht jeder Befund.

Modul: Schwachstellenmeldungen und Security Incident Response

Cyber Resilience Act: die Daten

Betroffen sind Produkte mit digitalen Elementen — Software oder Hardware samt Fernverarbeitungslösungen, deren Nutzung eine direkte oder mittelbare Datenverbindung zu einem Gerät oder Netz umfasst. Vier Pflichten betreffen den Entwicklungsprozess unmittelbar: Risikobewertung über den Lebenszyklus, Sicherheit durch Gestaltung, ein festgelegter Supportzeitraum und eine technische Dokumentation, die Bewertung und umgesetzte Maßnahmen festhält. Die Einordnung dient der technischen Orientierung und ersetzt keine Rechtsberatung.

Modul: Cyber Resilience Act und dauerhaftes Betriebsmodell

Kennzahlen, die etwas steuern

Eine Kennzahl ohne benannte Reaktion ist Dekoration — die rechte Spalte ist der eigentliche Zweck. Drei Kennzahlen genügen; mehr werden erhoben, aber nicht mehr gelesen.

Modul: Cyber Resilience Act und dauerhaftes Betriebsmodell

Typische Fallen

• Die SBOM gilt als dauerhaft gültig. Sie beschreibt den Stand, aus dem sie erzeugt wurde — ohne Erzeugungszeitpunkt lässt sie sich keinem Release zuordnen.
• Unbekanntes wird weggelassen statt markiert. Eine scheinbar lückenlose Liste ist weniger wert als eine mit sichtbaren Lücken.
• Nur eine SBOM, und niemand weiß, welche Sicht sie zeigt. Quellstand, Artefakt und Image beantworten verschiedene Fragen.
• Der Schweregrad wird als Priorität verwendet, weil er als Zahl vorliegt — die Erreichbarkeit im eigenen Produkt entscheidet aber stärker.
• „Nicht betroffen” wird gesetzt, weil ein Patch aufwendig wäre. Das ist keine Bewertung, sondern eine Umgehung mit unangenehmer Aktenlage.
• Die Verifikation prüft die Gültigkeit, nicht die erwartete Identität. Ein grüner Haken ohne Inhalt.
• Signiert wird ein Tag statt eines Digests. Der Tag wandert später, die Signatur bleibt gültig und meint etwas anderes.
• Die Provenance entsteht im Build-Skript statt durch die Plattform. Dann sagt sie nur, was das Skript behauptet.
• Beim Umkopieren zwischen Registries bleiben Signatur und Attestierungen zurück. Die Verifikation schlägt dann im Deployment fehl.
• Die Prüfung läuft nur in der Pipeline. Ein Notfall-Deployment geht daran vorbei.
• Die Frühwarnung wird verschoben, bis die Analyse fertig ist. Die Frist läuft ab Kenntnis.
• Der Zeitpunkt der Kenntniserlangung steht nirgends. Dann lässt sich die Einhaltung nicht belegen.
• Der Supportzeitraum ist nicht festgelegt und beim Kauf nicht erkennbar — dabei ist er eine Entscheidung und eine Zeile in der Produktbeschreibung.

Zum Seminar DevSecOps und sichere Software-Lieferketten