SBOM-Anfragen von Kunden: so antworten Sie

Sie liefern Komponenten oder Embedded-Software an Hersteller? Siehe den SBOM-Leitfaden für Lieferanten, der Verträge, VEX und eine SBOM pro gelieferter Softwareversion behandelt.

Warum Kunden jetzt danach fragen

• Der Cyber Resilience Act. Hersteller, die in der EU verkaufen, brauchen eine SBOM ihres eigenen Produkts und müssen bei den Komponenten, die sie einbinden, Sorgfalt walten lassen. So wandert die Frage die Lieferkette hinunter.
• NIS2. Wesentliche und wichtige Einrichtungen müssen die Sicherheit ihrer Lieferkette adressieren. Die Richtlinie nennt SBOMs nicht, aber eine SBOM ist für Käufer ein Weg zu sehen, was ein Lieferant ausliefert. Siehe SBOMs als Nachweis für NIS2, ISO 27001 und SOC 2.
• Branchenregeln. FDA Section 524B verlangt eine SBOM für Cyber Devices, und andere Branchen haben eigene Regeln.
• Die eigene Schwachstellenarbeit des Kunden. Ein Kunde, der weiß, was in Ihrem Produkt steckt, kann selbst beurteilen, ob eine neue CVE ihn betrifft, ohne ein Support-Ticket zu öffnen.

Was Sie klären sollten, bevor Sie etwas senden

Frage	Warum sie wichtig ist
Welches Produkt und welche Version?	Eine SBOM beschreibt ein Release. Senden Sie die der Version, die der Kunde einsetzt, nicht die des neuesten Builds.
Welches Format?	Die meisten Anfragen akzeptieren CycloneDX oder SPDX. Fragen Sie nach, ob eine bestimmte Version nötig ist.
Wie tief?	Die obersten Abhängigkeiten reichen möglicherweise nicht aus. Rechnen Sie damit, dass nach transitiven gefragt wird.
Einmalig oder mit jedem Release?	Ein Vertrag kann für jedes Release eine neue SBOM vorsehen, und das schließt alles aus, was von Hand geschieht.
Zu welchen Bedingungen?	Eine SBOM zeigt, wie Ihr Produkt aufgebaut ist. Vereinbaren Sie die Vertraulichkeitsbedingungen und wie die Datei übermittelt wird.

Was zu einer guten Antwort gehört

• Eine SBOM im vereinbarten Format für genau das Release, das der Kunde einsetzt.
• Jede Komponente mit Name, Version, Lieferant, Lizenz und einer Paketkennung.
• Die Abhängigkeitsbeziehungen, damit sich ein transitives Paket zu dem zurückverfolgen lässt, was es nachgezogen hat.
• Das Datum, das erzeugende Tool und der Build, aus dem sie stammt.
• Ein ehrlicher Hinweis auf alles, was die SBOM nicht abdeckt (siehe SBOM-Vollständigkeit).

Wie die Dateien aussehen, zeigen die SBOM-Beispiele. Zu den beiden Formaten siehe CycloneDX vs SPDX. Was der Kunde beim Eingang voraussichtlich prüft, zeigt die SBOM-Qualitäts-Checkliste.

Fehler, die sich später rächen

• Den neuesten Build senden statt des ausgelieferten. Builds sind standardmäßig nicht reproduzierbar. Wer denselben Commit neu baut, hat also keine Garantie für dieselbe SBOM. Nur die SBOM aus dem Build, der das Release erzeugt hat, zeigt, was der Kunde erhalten hat.
• Sie für den Anlass von Hand zusammenstellen. Das erfüllt die Anfrage einmal, und für den nächsten Kunden und das nächste Release fangen Sie von vorn an. Siehe SBOM-Automatisierung.
• Mehr versprechen, als Sie wiederholen können. „Wir senden Ihnen mit jedem Release eine“ steht schnell im Vertrag und ist ohne Automatisierung schwer einzuhalten.
• Die SBOM als Schlusspunkt betrachten. Die Folgefrage lautet „Sind Sie von dieser CVE betroffen?“, und sie kommt mit der nächsten großen Schwachstelle.

So sind Sie für die nächste Anfrage bereit

Anfragen werden einfach, wenn die SBOM schon existiert. Erzeugen Sie für jedes Release eine in der Pipeline, die es baut, bewahren Sie sie beim Release auf und überwachen Sie sie auf neue Schwachstellen. Dann braucht eine Anfrage nur noch einen Download und eine kurze Notiz, und Sie können die Folgefrage aus denselben Aufzeichnungen beantworten.

Wie CRACI das umsetzt

CRACI zeichnet für jeden GitHub-Actions-Build, der auf seinen Runnern läuft, eine SBOM auf. Jedes Release hat also bereits eine, wenn jemand danach fragt.

• Export als CycloneDX oder SPDX, einschließlich transitiver Abhängigkeiten und der in den Komponenten gefundenen Schwachstellen.
• Nachweise aus dem Build selbst. Jede Komponente in der SBOM war im Build, und versteckte Abhängigkeiten, die Lockfile-basierte Tools übersehen, werden aufgezeichnet.
• Ein Vollständigkeitsstatus für jeden Job, sodass Sie wissen, was Sie senden, bevor Sie es senden.
• Build-Historie. Sie sehen frühere Builds und deren SBOMs sowie die Builds, die eine verwundbare Abhängigkeit enthielten, innerhalb Ihrer Aufbewahrungsfrist.
• Antworten auf die Folgefrage. CRACI bewertet überwachte SBOMs laufend neu, unterstützt VEX und zeigt in der Inventaransicht, welche Produkte welche Versionen einsetzen.

SBOM-Anfragen von Kunden: häufig gestellte Fragen

Sind wir verpflichtet, Kunden unsere SBOM zu geben?

Das hängt von Ihrem Markt und Ihren Verträgen ab. Der Cyber Resilience Act macht die SBOM zum Teil der technischen Dokumentation, die auf Verlangen an eine Marktüberwachungsbehörde geht, und er verlangt nicht, sie zu veröffentlichen. Ein Anspruch des Kunden ergibt sich meist aus dem Vertrag, prüfen Sie also, was Sie vereinbart haben.

Welches SBOM-Format sollten wir senden?

CycloneDX oder SPDX, je nachdem, was der Kunde verlangt. Hat er keine Präferenz, passt beides. Fragen Sie nach, ob seine Tools eine bestimmte Version brauchen.

Müssen wir transitive Abhängigkeiten aufnehmen?

Der Cyber Resilience Act verlangt mindestens die obersten Abhängigkeiten, aber viele Käufer erwarten den gesamten Baum, und Schwachstellen sitzen oft in transitiven Paketen. Eine vollständige SBOM ist die sicherere Antwort.

Sollte die SBOM unter einem NDA an den Kunden gehen?

Das entscheiden Sie und Ihr Kunde. Eine SBOM zeigt, woraus Ihr Produkt besteht. Deshalb teilen viele Anbieter sie unter dem bestehenden Vertrag oder einem NDA, statt sie zu veröffentlichen.

Wie oft sollten wir eine aktualisierte SBOM senden?

So oft, wie Sie es vereinbaren. Abhängigkeiten ändern sich mit jedem Release, daher ist eine neue SBOM pro Release die ehrliche Standardlösung, und praktikabel ist das nur, wenn die SBOM aus dem Build kommt.

Was, wenn der Kunde nach einem älteren Release fragt?

Dann brauchen Sie die SBOM aus dem Build, der dieses Release erzeugt hat. CRACI bewahrt die Build-Historie innerhalb Ihrer Aufbewahrungsfrist auf, standardmäßig 180 Tage, mit individueller Aufbewahrung bei Enterprise. Exportieren Sie also alles, was Sie länger behalten müssen.

Wir haben noch nie eine SBOM erstellt. Wo fangen wir an?

Beginnen Sie mit dem Release, das Ihr Kunde einsetzt, und einem Tool, das mit Ihrem echten Build arbeitet. Wenn Sie GitHub Actions nutzen, liefert der Umzug des Builds auf CRACI-Runner ab dem ersten Lauf eine aufgezeichnete SBOM.