SBOM in der Softwareausschreibung: Cyber Resilience Act, Schwachstellenmanagement und Nachweise

Die Fachabteilung möchte eine neue Fachsoftware beschaffen. Im Angebot klingt alles überzeugend, doch auf die Frage nach enthaltenen Open-Source-Komponenten, bekannten Schwachstellen und garantierten Sicherheitsupdates bleibt der Anbieter vage. Genau hier muss die Vergabestelle ansetzen: Nicht erst nach dem Zuschlag, sondern bereits in Leistungsbeschreibung, Vertragsbedingungen und Wertung muss klar sein, welche Transparenz die Software-Lieferkette bieten soll.

Eine Software Bill of Materials, kurz SBOM, schafft diese Transparenz. Sie ist ein strukturiertes Verzeichnis der in einer Software verwendeten Komponenten. Das betrifft insbesondere Drittbibliotheken, Open-Source-Bausteine, Abhängigkeiten und deren Versionen. Für Vergabestellen ist die SBOM kein Selbstzweck. Sie ermöglicht es, Sicherheitsrisiken nach einer neu bekannt gewordenen Schwachstelle schneller einzuordnen und vertraglich geschuldete Reaktionen belastbar nachzuhalten.

Mit dem Cyber Resilience Act, kurz CRA, gewinnen diese Themen weiter an Gewicht. Die Verordnung gilt für Produkte mit digitalen Elementen und sieht gestaffelte Anwendungszeitpunkte vor. Die zentralen Herstellerpflichten gelten grundsätzlich ab dem 11. Dezember 2027. Bestimmte Meldepflichten zu aktiv ausgenutzten Schwachstellen und schweren Sicherheitsvorfällen greifen bereits ab dem 11. September 2026. Für öffentliche Auftraggeber folgt daraus nicht automatisch dieselbe Rolle wie für Hersteller. Du solltest aber Anforderungen so gestalten, dass angebotene Software über ihren Lebenszyklus sicher betrieben, geprüft und aktualisiert werden kann.

Infografik zu SBOM in der Softwareausschreibung: Cyber Resilience Act, Schwachstellenmanagement und Nachweise (KI-generiert).

SBOM: Was sie für die Beschaffung leisten muss

Eine SBOM beantwortet zunächst eine einfache Frage: Welche Komponenten stecken in der gelieferten Software? In der Praxis braucht die Vergabestelle jedoch mehr als eine einmalige Komponentenliste bei Vertragsbeginn.

Damit eine SBOM verwertbar ist, sollte sie mindestens enthalten:

• Name und eindeutige Kennzeichnung der Softwarekomponente
• Hersteller oder Herausgeber, soweit verfügbar
• genaue Versionsangabe
• Abhängigkeitsbeziehungen zwischen Komponenten, soweit technisch möglich
• Lizenzinformationen bei Komponenten mit relevanten Lizenzpflichten
• Erstellungsdatum und Bezug zur konkreten Produkt- oder Release-Version
• maschinenlesbares Format sowie lesbare Übersicht für die Fachseite

Gängige maschinenlesbare Formate sind SPDX und CycloneDX. Du musst jedoch nicht zwingend ein einzelnes Format vorgeben. Sachgerechter ist regelmäßig die Anforderung, dass die SBOM in einem verbreiteten, maschinenlesbaren und ohne proprietäre Werkzeuge auswertbaren Format bereitzustellen ist. Wenn deine IT-Sicherheitswerkzeuge bereits ein bestimmtes Format verarbeiten, darfst du dieses sachlich begründet festlegen.

Wichtig ist der Liefergegenstand. Fordere nicht nur eine SBOM für die Standardsoftware. Sie muss sich auf die tatsächlich bereitgestellte Instanz, Version oder Konfiguration beziehen. Bei Individualentwicklungen gehören auch die im Projekt eingebundenen Komponenten in den Umfang. Bei Cloud-Diensten kann eine vollständige Offenlegung aller Infrastrukturkomponenten unverhältnismäßig oder sicherheitskritisch sein. Dann sollte die Anforderung auf die für den Dienst relevanten Anwendungs- und Client-Komponenten sowie auf eine nachvollziehbare Risikobewertung zugeschnitten werden.

Den CRA richtig in Vergabeunterlagen einordnen

Der CRA richtet sich primär an Wirtschaftsakteure wie Hersteller, Bevollmächtigte, Importeure und Händler. Er ersetzt nicht die vergaberechtliche Prüfung. Du darfst deshalb nicht schlicht formulieren: „Der Bieter muss CRA-konform sein.“ Diese Aussage ist zu unbestimmt und kann je nach Leistungsmodell am falschen Unternehmen anknüpfen.

Besser ist eine leistungsbezogene Regelung. Beschreibe, welche Eigenschaften und Leistungen du für den sicheren Betrieb benötigst:

• Dokumentation der eingesetzten Komponenten und bekannten Abhängigkeiten
• geregelte Überwachung von Schwachstellen
• fristgerechte Sicherheitsupdates
• definierte Kontaktwege und Informationspflichten
• nachvollziehbare Nachweise über Sicherheitsprozesse
• Unterstützung bei der Bewertung und Behebung kritischer Sicherheitslücken

Für die rechtliche und technische Einordnung des CRA empfiehlt sich die Beobachtung der Informationen der Europäischen Kommission. Im Verfahren selbst bleibt aber entscheidend, dass jede Anforderung einen Bezug zum Auftragsgegenstand hat, verhältnismäßig ist und in den Unterlagen eindeutig beschrieben wird.

Wenn die Leistung KI-Komponenten enthält, sollte die Lieferkettentransparenz zudem mit Datenschutz, Kontrollrechten und Betriebsverantwortung verbunden werden. Dazu passt unser Beitrag KI-Systeme ausschreiben: AI Act, Datenschutz und Kontrollrechte in den Vergabeunterlagen.

Schwachstellenmanagement konkret beschreiben

Eine SBOM zeigt, ob eine betroffene Komponente vorhanden sein könnte. Sie beantwortet noch nicht, ob die konkrete Software tatsächlich verwundbar ist, wie hoch das Risiko ausfällt und wann Abhilfe erfolgt. Diese Lücke schließt ein vertraglich geregeltes Vulnerability-Management.

Lege dafür zunächst Begriffe und Abläufe fest. Der Auftragnehmer sollte Sicherheitsmeldungen aus geeigneten Quellen überwachen, die Relevanz für den Vertragsgegenstand bewerten und die Vergabestelle über bestätigte Betroffenheiten informieren. Die Meldung braucht einen festen Mindestinhalt:

• betroffene Leistung, Versionen und Mandanten
• Art der Schwachstelle und erste Risikoeinschätzung
• bekannte oder vermutete Ausnutzbarkeit
• vorhandene Gegenmaßnahmen
• geplanter Zeitpunkt für Patch, Konfigurationsänderung oder Workaround
• Auswirkungen auf Verfügbarkeit, Datenverarbeitung und Betriebsabläufe

Starre Fristen für jede denkbare Sicherheitslücke sind häufig unpraktisch. Sinnvoller ist ein abgestuftes Modell, das sich an Kritikalität, Ausnutzbarkeit und Auswirkungen orientiert. Für aktiv ausgenutzte oder besonders kritische Schwachstellen kannst du kurze Informations- und Reaktionsfristen verlangen. Für weniger kritische Befunde reichen regelmäßige Sammelberichte oder die Behebung im nächsten Wartungsrelease.

Die Kriterien müssen dabei prüfbar sein. Verweise etwa auf eine vereinbarte Risikoklassifizierung und beschreibe, wer sie im Streitfall bewertet. Eine einseitige Einstufung allein durch den Auftragnehmer ist für kritische Systeme meist nicht ausreichend. Die Vergabestelle sollte eine Begründung, Nachfragen und gegebenenfalls eine Neubewertung verlangen können.

Update-Zeiträume und Support nicht vermischen

Viele Unterlagen enthalten den Satz: „Updates werden während der Vertragslaufzeit bereitgestellt.“ Das reicht nicht. Erstens kann ein Vertrag länger laufen als der reguläre Produkt-Support. Zweitens sind Sicherheitsupdates, Funktionsupdates und allgemeine Fehlerbehebungen unterschiedliche Leistungen.

Regle daher getrennt:

Regelungsbereich	Was du festlegen solltest
Sicherheitsupdates	Bereitstellung, Priorisierung und Einspielung abhängig von der Kritikalität
Funktionsupdates	Ob sie geschuldet sind, wie sie angekündigt und getestet werden
Supportzeitraum	Mindestdauer für Sicherheitskorrekturen je eingesetzter Hauptversion
End of Life	Vorankündigungsfrist, Migrationspfad und Folgen für den Betrieb
Mitwirkung	Zugänge, Wartungsfenster, Freigaben und Testumgebungen der Vergabestelle
Kosten	Welche Updates von der Vergütung umfasst sind und wann Zusatzleistungen entstehen können

Bei Standardsoftware solltest du insbesondere vermeiden, dass der Auftragnehmer einseitig eine Version abkündigt, während deine Behörde weiterhin auf diese Version angewiesen ist. Fordere rechtzeitige Informationen über das Ende des Sicherheits- oder Herstellersupports. Vereinbare außerdem, welche Alternativen der Auftragnehmer anbieten muss, etwa ein Upgrade, einen verlängerten Support oder eine Migration.

Bei Cloud-Diensten gehört das Patchen typischerweise zur Betreiberleistung. Trotzdem benötigst du Transparenz darüber, wie Sicherheitsupdates getestet, ausgerollt und bei Störungen zurückgenommen werden. Ergänze diese Fragen um Datenresidenz, Exit-Szenarien und Verantwortlichkeiten. Praktische Hinweise findest du in unserem Beitrag Cloud-Dienste ausschreiben: Datenresidenz, Datenschutz und Exit-Strategie.

Nachweise fordern, ohne Bieter unnötig auszuschließen

Nicht jeder Bieter kann bereits bei Angebotsabgabe eine vollständige SBOM für jede spätere Konfiguration vorlegen. Gerade bei komplexen Einführungsprojekten entsteht der konkrete Lieferstand erst im Projekt. Teile Nachweise deshalb sinnvoll nach Zeitpunkten auf.

Bei Angebotsabgabe kommen beispielsweise in Betracht:

• Beschreibung des Schwachstellenmanagements
• Muster einer anonymisierten oder beispielhaften SBOM
• Erklärung zum verwendeten SBOM-Format und Aktualisierungsprozess
• Beschreibung der Update- und Supportpolitik
• Benennung einer Sicherheitskontaktstelle

Vor Abnahme oder Inbetriebnahme verlangst du dann die vollständige, leistungsbezogene SBOM sowie die konkreten Betriebs- und Sicherheitsinformationen. Während der Vertragslaufzeit sollte der Auftragnehmer aktualisierte SBOMs bei Releases, sicherheitsrelevanten Änderungen und auf begründete Anforderung bereitstellen.

Achte darauf, Eignungsanforderungen, Mindestanforderungen und Zuschlagskriterien sauber zu trennen. Ein belastbarer Prozess für Schwachstellenmanagement kann als Eignungsaspekt relevant sein, wenn er die Leistungsfähigkeit des Unternehmens belegt. Die Bereitstellung einer SBOM für die konkret zu liefernde Software ist dagegen regelmäßig eine Leistungsanforderung. Eine über das Minimum hinausgehende Qualität, etwa automatisierte Aktualisierung oder besonders nachvollziehbare Risikoberichte, kann ein Zuschlagskriterium sein, wenn du sie transparent bewertest. Wie du diese Trennung in einer Wertung abbildest, erläutern wir in Zuschlagskriterien und Wertungsmatrix aufbauen.

Produktneutral formulieren und dokumentieren

Verlange Ergebnisse, keine bestimmten Produkte oder Herstellerprozesse. Formulierungen wie „Der Auftragnehmer nutzt Tool X zur Schwachstellenanalyse“ sind regelmäßig zu eng. Zielführender ist: „Der Auftragnehmer weist ein dokumentiertes Verfahren zur Identifikation, Bewertung, Priorisierung und Behebung sicherheitsrelevanter Schwachstellen nach.“

Auch bei technischen Standards gilt: Benenne das benötigte Interoperabilitätsziel. Wenn du ein Format vorgibst, begründe es in der Vergabedokumentation mit vorhandenen Prozessen oder Schnittstellen. Bei der Leistungsbeschreibung helfen dir außerdem die Grundsätze aus unserem Ratgeber Leistungsbeschreibung: produktneutral und präzise.

Dokumentiere insbesondere:

• warum die SBOM für den konkreten Beschaffungsgegenstand erforderlich ist
• welche Teile der Lösung von der Anforderung erfasst sind
• wie du bei vertraulichen Informationen und Sicherheitsdetails vorgehst
• welche Nachweise zu welchem Zeitpunkt erforderlich sind
• wie du gleichwertige Formate oder Verfahren bewertest
• wie die Anforderungen in Wertung, Vertrag und Abnahme zusammenwirken

Checkliste vor Veröffentlichung der Unterlagen

Prüfe vor der Bekanntmachung, ob du diese Fragen mit Ja beantworten kannst:

• Ist klar definiert, für welche Softwarebestandteile eine SBOM vorzulegen ist?
• Sind Format, Mindestinhalte und Aktualisierungsanlässe beschrieben?
• Gibt es konkrete Regeln für Meldung, Bewertung und Behebung von Schwachstellen?
• Sind Sicherheitsupdates, Supportdauer und End-of-Life-Szenarien getrennt geregelt?
• Sind Nachweise zeitlich realistisch gestaffelt?
• Sind Mindestanforderungen und bewertbare Mehrleistungen eindeutig getrennt?
• Enthält der Vertrag Prüf-, Informations- und Durchsetzungsrechte?
• Sind die Anforderungen für Bieter verständlich und produktneutral begründet?

SBOM, Schwachstellenmanagement und Updatepflichten gehören zusammen. Erst ihre Verbindung macht aus einer Komponentenliste ein wirksames Instrument für sichere Softwarebeschaffung. Passende Seminare und Termine findest du bei uns auf cmt.de.