SBOM im IT-Einkauf: CRA 2026 mit EVB-IT sicher umsetzen

Warum CRA und SBOM 2026 auf Deine Beschaffungsagenda gehören

Der Cyber Resilience Act ist am 10. Dezember 2024 in Kraft getreten und gilt überwiegend ab dem 11. Dezember 2027. Für die IT-Beschaffung ist aber bereits 2026 relevant: Regeln für Konformitätsbewertungsstellen greifen ab dem 11. Juni 2026, Meldepflichten nach Artikel 14 ab dem 11. September 2026. Diese Meldepflichten können auch Produkte mit digitalen Elementen betreffen, die vor dem allgemeinen Anwendungsbeginn in Verkehr gebracht wurden.

Das trifft die Realität vieler IT-Beschaffungen: Rahmenvereinbarungen laufen über mehrere Jahre, Software-Abonnements werden verlängert, EVB-IT-Verträge enthalten Pflege- und Supportzeiträume, und integrierte Systeme bleiben lange im Betrieb. Wenn Du 2026 ausschreibst, kann der Vertrag direkt in die CRA-Übergangsphase hineinlaufen.

Dafür müssen Einkauf, Informationssicherheit, Vertragsmanagement, Software Asset Management und Lizenzmanagement gemeinsam arbeiten. Die Beschaffung strukturiert die Unterlagen, die Informationssicherheit definiert prüfbare Sicherheitsanforderungen, das Lizenzmanagement bewertet Open-Source- und Nutzungsrechte, und Legal achtet auf Widerspruchsfreiheit im Vertrag.

Welche IT-Beschaffungen betroffen sein können

Der CRA verwendet einen breiten Begriff der Produkte mit digitalen Elementen. Erfasst sein können Produkte, deren Zweck oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk umfasst.

Für Vergabestellen bedeutet das: Nicht nur klassische Softwareentwicklung ist relevant. Typische Fälle sind Standardsoftware, Security-Tools, Netzwerkkomponenten, Betriebssysteme, eingebettete Systeme, cloudnahe Komponenten, Appliances, integrierte IT-Systeme und Produkte mit produktbezogener Firmware. Je nach Ausgestaltung können nach den Produktklassen des CRA unter anderem Identity-Management-Systeme, Privileged-Access-Systeme, Browser, Passwortmanager, Anti-Malware-Software, VPN-Komponenten, Netzwerkmanagement, SIEM, PKI-Software, Betriebssysteme, Router, Modems und Switches eine Rolle spielen.

Risikobasierte Triage vor der Ausschreibung

• Kritikalität: Unterstützt die Software wesentliche Geschäftsprozesse, Sicherheit oder Verfügbarkeit?
• Externe Konnektivität: Gibt es Internetzugang, Cloud-Anbindung, Remote-Zugriff oder Lieferantenportale?
• Privilegierte Rechte: Verarbeitet das Produkt Admin-Konten, Secrets, Zertifikate oder Zugriffstoken?
• Datenvertraulichkeit: Werden personenbezogene, vertrauliche oder regulierte Daten verarbeitet?
• Support-Laufzeit: Reicht die Nutzung in den Zeitraum ab September 2026 oder Dezember 2027 hinein?

Bei Embedded Linux, Images und produktnaher Software ist Komponententransparenz besonders wichtig, weil Build-Rezepte, Open-Source-Komponenten und Firmware-Stände später schwer rekonstruierbar sein können. Fachlich anschlussfähig ist hier der Themenbereich Embedded Systems.

Was eine SBOM ist und was sie nicht leistet

Eine Software Bill of Materials ist ein strukturierter Datensatz über Softwarekomponenten und deren Lieferkettenbeziehungen. NIST beschreibt die SBOM als formalen Nachweis mit Details und Beziehungen der Komponenten, die zum Bau einer Software verwendet werden. Typische maschinenlesbare Formate sind SPDX, CycloneDX und SWID.

Der CRA verknüpft die SBOM mit Anhang I Teil II. Die Europäische Kommission kann Format und Elemente durch Durchführungsrechtsakte konkretisieren. Marktüberwachungsbehörden können relevante SBOMs anfordern, unter anderem zur Analyse von Abhängigkeiten.

Du brauchst daher Prozesse für Empfang, sichere Ablage, Aktualisierung, Normalisierung und Auswertung der SBOM-Daten. Ohne diese Prozesskette verbessert eine angeforderte SBOM die Sicherheit kaum.

SBOM-Anforderungen in Vergabeunterlagen formulieren

SBOM-Anforderungen können in der Leistungsbeschreibung, den technischen Spezifikationen, der Nachweisliste, einer Vertragsanlage, einer EVB-IT-Anlage oder im Sicherheitskonzept stehen. Wichtig ist die Trennung von Mindestanforderungen, Zuschlagskriterien und Vertragserfüllungspflichten. Für die Strukturierung von Leistungsbeschreibung, Vertrag, Anlagen und Preisblatt ist der Beitrag zu Vergabeunterlagen in der Praxis fachlich passend.

Vermeide Formulierungen wie „Der Auftragnehmer muss CRA-compliant sein“. Das ist zu unbestimmt, schwer prüfbar und vermischt Produktanforderungen mit regulatorischer Selbstbewertung. Besser sind messbare Anforderungen.

Der Begriff Software Bill of Materials tender sollte nicht nur in einer Anlage auftauchen. Die Anforderung muss mit Abnahme, Updatepflichten, Support, Incident-Kommunikation und Vertragsbeendigung zusammenspielen.

Lieferantennachweise: Was Du abfragen solltest

Fordere nur Nachweise, die Du wirklich prüfen und später nutzen kannst. Sinnvoll sind Angaben zu SBOM-Format, Generierungsmethode, Abdeckungsumfang, Updateprozess und verantwortlicher Kontaktstelle. Ergänzend gehören Schwachstellenbenachrichtigungen, Patch- und Updateprozesse, Supportzeitraum und End-of-Life-Handling in die Nachweisliste.

Verknüpfe SBOM-Nachweise mit Open-Source-Lizenzinformationen, Drittkomponenten und Security Advisories. Open source evidence procurement bedeutet nicht, den Lieferanten mit unbegrenzten Fragen zu überziehen. Frage nach den Artefakten, die für Deine Risikobewertung erforderlich sind: Komponentenliste, Lizenzhinweise, bekannte Einschränkungen, Sicherheitskontakt, Patchkanal und Verfahren für kritische Schwachstellen.

Achte darauf, keine Informationen zu verlangen, die bei Standardsoftware oder Cloud-Services praktisch nicht sinnvoll offengelegt werden können. Wenn ein Hersteller nur eingeschränkte SBOM-Daten bereitstellt, können eine gesicherte Einsichtnahme, ein Portalzugang oder eine abgestufte Offenlegung für besonders kritische Komponenten angemessen sein.

Eine nutzbare Bewertungsmatrix aufbauen

Eine belastbare Bewertungsmatrix trennt Ausschlusskriterien, Mindestanforderungen, bewertete Qualitätskriterien und Bedingungen für die Vertragsausführung. Unklare Selbstauskünfte führen zu schwachen Bewertungen und können Vergaberisiken auslösen. Für die Abgrenzung von Mindestanforderungen, Nachweisen und Zuschlagskriterien ist Leistungen richtig beschreiben und Angebote rechtssicher bewerten ein naheliegender Vertiefungspunkt.

Für IT-spezifische Bewertungslogik, transparente Gewichtung und Dokumentation der Zuschlagsentscheidung ist eine UfAB-orientierte Vorgehensweise hilfreich, etwa im Kontext von Vergaberecht und IT-Recht.

SBOM, Open Source, Lizenzmanagement und Schwachstellenmanagement verbinden

SBOM-Daten ergänzen Software Asset Management und Lizenzinventare. Sie zeigen, welche Komponenten in einem Produkt stecken, welche Versionen eingesetzt werden und wo Open-Source-Lizenzen, Copyleft-Pflichten oder Drittanbieterbedingungen relevant werden können. Gleichzeitig sind dieselben Komponenten Grundlage für Vulnerability Matching und Risikobewertung.

Die operative Kette ist klar: SBOM entgegennehmen, Komponenten normalisieren, mit Schwachstelleninformationen abgleichen, Risiko bewerten, Maßnahmen verfolgen und dokumentieren. Aktuelle Lagebilder von ENISA und anderen Sicherheitsbehörden zeigen regelmäßig, dass Lieferkettentransparenz und Schwachstellenmanagement praktisch relevant sind.

Dabei arbeiten Einkauf, IT-Betrieb, Informationssicherheit, Legal und Lizenzmanagement zusammen. Für die Verbindung aus Nutzungsrechten, Open-Source-Pflichten und Lieferantenbedingungen passt das Thema Softwarelizenzvertrag in der Vergabe. Für operative Sicherheitsprozesse sind außerdem IT-Security-Inhalte anschlussfähig.

EVB-IT und Vertragsanlagen: Wo die SBOM hingehört

Bei EVB-IT Systemlieferung und EVB-IT Systemverträgen gehören SBOM-Pflichten nicht isoliert in eine technische Fußnote. Sie müssen mit Dokumentation, Standardsoftware, Open-Source-Komponenten, Nutzungsrechtematrix, Systemservice, Updates und Störungsmanagement harmonieren. Für solche Beschaffungen ist der Themenbereich IT-Verträge mit EVB-IT ein sinnvoller Kontext.

Prüfe die Rangfolge der Vertragsdokumente. Eine SBOM-Anlage darf nicht der Leistungsbeschreibung, den EVB-IT-Bedingungen oder zugelassenen Lieferantenbedingungen widersprechen. Bei komplexen Projekten empfiehlt sich eine eigene Anlage „Security und Software Supply Chain“. Dort regelst Du Format, Übergabe, Aktualisierung, Vertraulichkeit, Sicherheitskontakt, Schwachstellenmeldungen, Open-Source-Offenlegung und Mitwirkungspflichten.

Typische Fehler, die Du vermeiden solltest

• Eine SBOM verlangen, ohne Format, Umfang, Zeitpunkt und Aktualisierungspflichten zu definieren.
• Kriterien bewerten, die während der Angebotsprüfung nicht verifizierbar sind.
• Eignung des Lieferanten, Produktanforderungen und Vertragspflichten ungeordnet vermischen.
• Die SBOM als einmaligen PDF-Anhang behandeln, den nach Zuschlag niemand auswertet.
• Vertraulichkeit, Geschäftsgeheimnisse und sicheren Austausch von SBOM-Daten vernachlässigen.

Praxischeckliste für Deine nächste IT-Ausschreibung

1. Markterkundung: Kläre, welche SBOM-Formate, Portale und Offenlegungsmodelle im Markt üblich sind.
2. Risikoklasse: Bewerte Kritikalität, Konnektivität, privilegierten Zugriff, Datenarten und Supportlaufzeit.
3. Vergabestruktur: Ordne Anforderungen Mindestkriterien, Nachweisen, Zuschlagskriterien oder Vertragspflichten zu.
4. SBOM-Lieferung: Definiere Format, Tiefe, Zeitpunkt, Aktualisierungsanlässe und sicheren Austauschkanal.
5. Open Source: Verlange Lizenzinformationen, Third-Party-Hinweise und bekannte Nutzungseinschränkungen nur im erforderlichen Umfang.
6. Vulnerability Management: Vereinbare Sicherheitskontakt, Meldewege, Patchkommunikation und Dokumentation.
7. EVB-IT-Abgleich: Prüfe Rangfolge, Anlagen, Dokumentation, Nutzungsrechte, Systemservice und Updatepflichten.
8. Betrieb: Lege fest, wer SBOM-Daten speichert, normalisiert, auswertet und Maßnahmen nachverfolgt.

Gehe risikobasiert vor. Du musst nicht jede Beschaffung mit maximalen SBOM-Pflichten überfrachten. Für kritische, vernetzte und langlebige Produkte solltest Du aber bereits 2026 klare Anforderungen in Ausschreibung, Bewertung und Vertrag verankern. Je konkreter EU-Durchführungsrechtsakte und technische Standards werden, desto leichter kannst Du Deine Textbausteine nachschärfen.