SBOM im Softwarevertrag: Komponentenliste, Aktualisierung und Schwachstelleninformationen verbindlich regeln

Am Montag meldet dein Security Team eine kritische Schwachstelle in einer weit verbreiteten Open Source Komponente. Der Hersteller deiner Fachanwendung teilt mit, man prüfe derzeit die Betroffenheit. Wann du eine belastbare Auskunft erhältst, ob die Komponente eingesetzt wird, welche Version betroffen ist und wann ein Patch kommt, bleibt offen. Genau in dieser Situation entscheidet sich, ob eine Software Bill of Materials, kurz SBOM, im Vertrag nur ein Dokument oder ein wirksames Steuerungsinstrument ist.

Eine SBOM ist eine strukturierte Komponentenliste einer Software. Sie benennt insbesondere verwendete Bibliotheken, Frameworks, Pakete und deren Versionen. Damit schafft sie Transparenz über die Softwarelieferkette. Für Einkauf, IT, Informationssicherheit und Recht ist sie zunehmend relevant: Der Cyber Resilience Act verschärft die Erwartungen an Hersteller von Produkten mit digitalen Elementen. Seit September 2026 gelten bereits Vorgaben zur Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle, weitere Pflichten folgen schrittweise.

Für dich als Kunde genügt es aber nicht, dass ein Anbieter grundsätzlich mit einer SBOM wirbt. Entscheidend ist, was genau geliefert wird, wann die Liste aktuell sein muss und welche Folgen eine unvollständige oder verspätete Information hat.

Infografik zu SBOM im Softwarevertrag: Komponentenliste, Aktualisierung und Schwachstelleninformationen verbindlich regeln (KI-generiert).

Warum die SBOM in den Vertrag gehört

Ohne vertragliche Regelung bleibt die SBOM häufig unverbindlich. Der Anbieter kann ein Format wählen, das sich kaum auswerten lässt, nur eine Momentaufnahme übergeben oder Aktualisierungen auf die nächste Hauptversion verschieben. Im Schwachstellenfall kostet das wertvolle Zeit.

Eine belastbare Vertragsregelung verbindet die Komponentenliste mit klaren Leistungs- und Mitwirkungspflichten. Sie beantwortet mindestens diese Fragen:

• Für welche Produkte, Module, Versionen und Bereitstellungsformen wird eine SBOM geliefert?
• Welche Komponenten und Metadaten muss sie enthalten?
• In welchem maschinenlesbaren Format erhältst du sie?
• Zu welchen Zeitpunkten wird sie bereitgestellt und aktualisiert?
• Wie informiert der Anbieter über neue kritische Schwachstellen?
• Welche Abhilfe schuldet er und innerhalb welcher Frist?
• Welche Rechte hast du bei Pflichtverletzungen?

Die SBOM ersetzt dabei weder Schwachstellenmanagement noch sichere Entwicklung. Sie ist die Datengrundlage, um Betroffenheiten schneller zu prüfen, Risiken einzuordnen und Maßnahmen nachzuverfolgen. Anforderungen an Updates und Sicherheitskorrekturen solltest du daher zusätzlich konkretisieren. Dazu passt unser Beitrag Updates, Patches und Pflege vertraglich regeln.

Geltungsbereich präzise definieren

Die Klausel sollte nicht pauschal von „der Software“ sprechen. Gerade bei komplexen Lösungen besteht sonst Streit darüber, ob Zusatzmodule, Agenten, Container Images, mobile Apps oder mitgelieferte Werkzeuge erfasst sind.

Beschreibe den Geltungsbereich anhand der beschafften Leistung. Erfasst sein sollten regelmäßig:

• die produktive Software einschließlich aller lizenzierten Module
• Client Software, mobile Anwendungen und lokale Agenten
• Container Images, virtuelle Appliances und Installationspakete
• mitgelieferte Bibliotheken, Laufzeitumgebungen und Drittkomponenten
• Komponenten, die der Anbieter im Rahmen von Wartung, Support oder Updates nachliefert

Bei SaaS Leistungen ist die Abgrenzung anspruchsvoller. Du hast keinen Anspruch auf Transparenz über jede interne Infrastrukturkomponente des Anbieters. Für deine Risikobewertung sind aber die Komponenten relevant, die die Sicherheit, Verfügbarkeit oder Verarbeitung deiner Daten wesentlich beeinflussen. Der Vertrag kann deshalb eine SBOM für kundennah eingesetzte Software, bereitgestellte Agenten, Schnittstellenkomponenten und sicherheitsrelevante Plattformbestandteile verlangen.

Bei Open Source Software reicht der Name einer Bibliothek nicht aus. Du benötigst auch die Lizenzinformationen, um Nutzungsrisiken einschätzen zu können. Welche Prüfungen hierfür im Unternehmen sinnvoll sind, erläutern wir in Open Source Lizenzen im Unternehmen.

Inhalt und Format der Komponentenliste festlegen

Eine brauchbare SBOM muss auswertbar und eindeutig sein. Das gelingt nicht mit einem PDF, einer bloßen Liste von Produktnamen oder einem Screenshot aus einem Scan Werkzeug. Vereinbare ein offenes, maschinenlesbares Format, etwa SPDX oder CycloneDX. Welches der beiden Formate besser passt, hängt von deinen vorhandenen Prozessen und Werkzeugen ab. Wichtig ist vor allem, dass der Anbieter eine konsistente Struktur liefert.

Folgende Angaben gehören mindestens in die Vertragsanlage:

Angabe	Zweck
Hersteller oder Lieferant der Komponente	Herkunft nachvollziehen
Komponentenname und genaue Version	Betroffenheiten sicher prüfen
Eindeutige Kennung, etwa Paket URL oder CPE, soweit verfügbar	Automatisierte Zuordnung unterstützen
Lizenzinformationen	Lizenzrisiken erkennen
Abhängigkeiten zwischen Komponenten	Reichweite einer Schwachstelle bewerten
Herkunft und Integritätsinformation, soweit technisch verfügbar	Manipulationen und unklare Quellen erkennen
Erstellungsdatum und Bezug zur Produktversion	Aktualität nachweisen

Verlange keine Metadaten, die dein Anbieter technisch nicht zuverlässig erzeugen kann. Eine überladene Klausel führt leicht zu unvollständigen Listen. Besser ist ein abgestufter Ansatz: Pflichtfelder für jede Komponente, zusätzliche Angaben für sicherheitskritische Bestandteile und eine Pflicht zur begründeten Kennzeichnung fehlender Daten.

Wenn du die SBOM automatisiert mit eigenen Sicherheitswerkzeugen verarbeiten willst, sollten Zeichenkodierung, Übertragungsweg und Versionierung ebenfalls geregelt sein. Ein geschütztes Kundenportal oder eine dokumentierte Schnittstelle kann sinnvoller sein als der Versand per E Mail.

Lieferzeitpunkt und Aktualisierungspflichten verbinden

Die wichtigste Frage lautet: Wann ist die SBOM geschuldet? Eine Liste bei Vertragsabschluss hilft kaum, wenn sie bis zur Produktivsetzung veraltet ist.

Für Standardsoftware bietet sich folgende Logik an:

• Eine erste SBOM erhältst du vor der Abnahme oder vor dem Beginn der produktiven Nutzung.
• Für jedes Release, Update und sicherheitsrelevante Patch stellt der Anbieter eine aktualisierte SBOM bereit.
• Änderungen an Komponenten werden nachvollziehbar versioniert.
• Die SBOM steht spätestens mit der Softwarelieferung oder Freigabe des Updates bereit.
• Der Anbieter korrigiert festgestellte Fehler in der SBOM innerhalb einer vereinbarten Frist.

Bei Individualsoftware sollte die Komponentenliste Teil der Lieferdokumentation und damit abnahmefähig sein. Fehlt sie oder ist sie wesentlich unvollständig, kann das ein Dokumentationsmangel sein. Ob dies auch die Abnahme hindert, hängt von der Bedeutung der fehlenden Information für dein Projekt ab. Verknüpfe die Pflicht daher ausdrücklich mit den Abnahmekriterien, wenn die Transparenz für deinen Einsatz wesentlich ist.

Für Cloudleistungen ist eine ereignisbezogene Aktualisierung oft passender als eine Übergabe für jedes interne Deployment. Vereinbare beispielsweise Aktualisierungen bei Änderungen, die sicherheitsrelevante Komponenten, Datenverarbeitungsfunktionen oder kundenbezogene Schnittstellen betreffen. Ergänzend kann eine regelmäßige aktuelle Fassung geschuldet sein.

Kritische Komponenten und Schwachstelleninformationen regeln

Die SBOM beantwortet zunächst nur, was enthalten ist. Sie sagt nicht automatisch, ob eine Komponente verwundbar, erreichbar oder in deinem Nutzungsszenario ausnutzbar ist. Deshalb braucht der Vertrag einen separaten Prozess für Schwachstelleninformationen.

Definiere nachvollziehbar, wann der Anbieter informieren muss. Praktikabel sind Anknüpfungspunkte wie:

• eine bekannte Schwachstelle betrifft eine in der SBOM enthaltene Komponente
• die Schwachstelle wird aktiv ausgenutzt oder ist nach Bewertung des Anbieters kritisch
• die Schwachstelle kann Vertraulichkeit, Integrität oder Verfügbarkeit deiner Systeme oder Daten erheblich beeinträchtigen
• es gibt einen verfügbaren Patch, Workaround oder eine Konfigurationsmaßnahme

Die Information sollte nicht bei einer allgemeinen Sicherheitsmeldung stehen bleiben. Fordere mindestens die betroffene Produktversion, die betroffene Komponente, eine Risikoeinschätzung, mögliche Auswirkungen, empfohlene Sofortmaßnahmen und den Zeitplan für Abhilfe. Ist die Betroffenheit noch unklar, sollte der Anbieter dies offen mitteilen und die Prüfung mit einem konkreten nächsten Statuszeitpunkt fortsetzen.

Reaktions- und Behebungszeiten müssen zu deinem Schutzbedarf passen. Ein pauschales Versprechen, Sicherheitslücken „zeitnah“ zu schließen, ist nicht steuerbar. Nutze Störungsklassen und klare Fristen, aber unterscheide zwischen Erstinformation, Bewertung, Workaround und dauerhafter Fehlerbehebung. Wie du solche Klassen sauber voneinander abgrenzt, zeigen wir in Support Level und Störungsklassen abgrenzen.

Haftung und Rechtsfolgen ausgewogen gestalten

Eine SBOM Klausel darf nicht folgenlos bleiben. Andernfalls ist sie nur eine Bitte um Transparenz. Zugleich solltest du keine unrealistischen Erfolgspflichten formulieren. Kein Anbieter kann garantieren, dass jede Drittkomponente dauerhaft frei von Schwachstellen bleibt oder jede öffentliche Meldung sofort vollständig bewertet ist.

Angemessen sind konkrete Rechtsfolgen bei steuerbaren Pflichtverletzungen, etwa wenn der Anbieter eine zugesagte SBOM nicht liefert, sie wiederholt unvollständig ist oder eine bestätigte kritische Betroffenheit nicht gemäß Prozess meldet. In Betracht kommen:

• ein Recht, die Dokumentation innerhalb einer angemessenen Frist nachzufordern
• Zurückbehaltungsrechte bei noch nicht abgenommenen Projektleistungen
• Servicegutschriften für verfehlte Informations- oder Reaktionszeiten, soweit dies zum Vertragsmodell passt
• Sonderkündigungsrechte bei erheblichen oder wiederholten Pflichtverletzungen
• Schadensersatz nach den vereinbarten Haftungsregeln

Achte darauf, dass Haftungsbegrenzungen Sicherheits- und Informationspflichten nicht ungewollt vollständig entwerten. Besonders bei Vorsatz, grober Fahrlässigkeit, Verletzung von Leben, Körper oder Gesundheit sowie zwingender gesetzlicher Haftung gelten ohnehin besondere Maßstäbe. Die Grundlogik einer ausgewogenen Haftung behandeln wir in Haftung im IT Vertrag sinnvoll begrenzen.

Checkliste für deine Vertragsprüfung

Prüfe vor der Unterschrift diese Punkte:

• Ist der genaue Geltungsbereich der SBOM beschrieben?
• Sind Format und Pflichtfelder verbindlich festgelegt?
• Erhältst du eine maschinenlesbare und versionierte Datei?
• Ist die Übergabe vor Produktivsetzung oder Abnahme vorgesehen?
• Werden Updates, Patches und neue Komponenten zeitnah abgebildet?
• Gibt es einen Prozess für kritische Schwachstellen inklusive Erstinformation und Abhilfe?
• Sind Ansprechpartner, Kommunikationskanäle und Eskalationen benannt?
• Ist geregelt, wie Fehler oder Lücken in der SBOM korrigiert werden?
• Passen die Haftungsfolgen, Kündigungsrechte und Service Levels zu deinem Risiko?

Eine gute SBOM Klausel ist kein Selbstzweck. Sie verbindet Beschaffung, Lizenzmanagement, Informationssicherheit und Betrieb. Wenn du Anforderungen früh mit IT Security, Einkauf und Recht abstimmst, vermeidest du nachträgliche Verhandlungen in einer kritischen Schwachstellenlage. Passende Seminare und Termine findest du bei uns auf cmt.de.