SBOM und CRA: Was muss ein Softwarehersteller praktisch vorbereiten?

Zuerst braucht es eine Übersicht der Produkte, für die das Unternehmen Verantwortung trägt. Der CRA erfasst unter seinen Voraussetzungen Software- und Hardwareprodukte, deren vorgesehene oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netzwerk umfasst. Hersteller ist insbesondere, wer ein Produkt unter eigenem Namen oder eigener Marke auf den Markt bringt. Ausnahmen und besondere Konstellationen müssen gesondert geprüft werden. Eine verständliche Einordnung bietet die Zusammenfassung des CRA durch die EU-Kommission.

Für die praktische Vorbereitung empfehlen wir eine Produktliste mit:

• Produktname, Funktion und Vertriebsmodell;
• Hersteller beziehungsweise verantwortlichem Unternehmen;
• ausgelieferten und weiterhin unterstützten Versionen;
• zugehörigen Modulen, Erweiterungen und erforderlichen Diensten;
• verantwortlichen Personen für Entwicklung, Sicherheit und Kundenkommunikation.

Dabei muss klar sein, was erfasst wird: Eine Liste aller Bibliotheken auf einem Entwicklerrechner beschreibt noch nicht die tatsächlich ausgelieferte Anwendung. Umgekehrt können nachgeladene Module oder mitgelieferte Laufzeitbibliotheken zusätzliche Aufmerksamkeit benötigen.

Gerade in gewachsenen Delphi-Projekten lohnt sich deshalb ein Abgleich zwischen automatischer Erkennung, Build-Konfiguration und Auslieferungspaket. Unbekannte Versionen oder unklar zugeordnete Komponenten sollten sichtbar bleiben und geprüft werden.

Für Delphi-Projekte bietet der Msys SBOM Generator Möglichkeiten, automatisch erkannte Komponenteninformationen zu ergänzen. Pakete können über eigene oder virtuelle SBOMs beschrieben werden. Mitgelieferte Fremdbibliotheken lassen sich als externe Module hinterlegen und dem Projekt zuordnen. Das ist insbesondere für dynamisch geladene DLLs hilfreich, die nicht über die normalen DLL-Importe erkannt werden.

Über die Kommandozeile lassen sich vorhandene SBOMs außerdem auf definierte CycloneDX-Regeln und zusätzlich gegen das Profil der BSI TR-03183-2 prüfen. Dabei werden beispielsweise fehlende Pflichtangaben oder nicht auflösbare Abhängigkeitsverweise gemeldet. Solche Prüfungen unterstützen die Qualitätssicherung; ob sämtliche tatsächlich ausgelieferten Komponenten erfasst sind, muss zusätzlich geprüft werden.

Ein Build ist die konkret aus Quellcode und Komponenten erstellte Anwendung. Werden eine Bibliothek, eine Plattformkonfiguration oder ein Zusatzmodul geändert, kann sich auch die Zusammensetzung des ausgelieferten Programms ändern.

Deshalb empfehlen wir, die SBOM gemeinsam mit dem passenden Release zu archivieren. Praktisch lässt sich das durch eine eindeutige Zuordnung von Produktversion, Build-Kennung, Konfiguration und SBOM-Datei organisieren. Eine neu erzeugte SBOM sollte die historische Übersicht eines früheren Releases nicht überschreiben.

Eine SBOM beantwortet, welche Komponenten dokumentiert sind. Eine neue Schwachstellenmeldung muss anschließend technisch bewertet werden: Betrifft sie die verwendete Version? Ist die verwundbare Funktion vorhanden und erreichbar? Welche Folgen hätte eine Ausnutzung?

Der CRA verlangt einen geregelten Umgang mit Schwachstellen und Sicherheitsupdates. Dazu gehören unter anderem eine Kontaktadresse für Schwachstellenmeldungen, ein Konzept für die koordinierte Offenlegung und die sichere Verteilung von Updates.

• Eingang: Sicherheitsinformationen von Komponentenherstellern, Schwachstellendatenbanken und Forschenden erfassen; eine erreichbare Kontaktstelle für eigene Produkte anbieten.
• Zuordnung: Hinweise gegen die Komponenten der unterstützten Produktversionen prüfen.
• Bewertung: Tatsächliche Betroffenheit, Auswirkungen und Dringlichkeit dokumentieren.

• Abhilfe: Schutzmaßnahmen, Komponentenupdates oder Änderungen am eigenen Code entwickeln und testen.
• Kommunikation: Betroffene Nutzer informieren und verständliche Handlungsempfehlungen bereitstellen.
• Abschluss: Korrektur, Veröffentlichungsstand und gegebenenfalls erforderliche Meldungen dokumentieren.

Der Unterstützungszeitraum muss die erwartete Nutzungsdauer berücksichtigen. Grundsätzlich beträgt er mindestens fünf Jahre; bei einer erwarteten Nutzung von weniger als fünf Jahren gilt deren Dauer. Bei länger erwarteter Nutzung kann entsprechend längere Unterstützung erforderlich sein.

Für die Planung heißt das: Prüfen Sie, wie lange eigene Releases und ihre Abhängigkeiten gepflegt werden können. Eine Bibliothek, deren Betreuung bald endet, kann spätere Sicherheitsupdates erschweren.

Vor dem Inverkehrbringen nach den anwendbaren CRA-Anforderungen sind die passende Konformitätsbewertung, EU-Konformitätserklärung und CE-Kennzeichnung erforderlich. Welches Verfahren möglich ist, hängt insbesondere von der Produktkategorie ab; bestimmte Kategorien erfordern die Beteiligung einer externen Stelle. Die Zusammenfassung der EU-Kommission erläutert die Unterschiede.

Als praktische Organisationshilfe empfehlen wir eine Release-Akte, die SBOM, Testergebnisse, Risikobewertung, bekannte Einschränkungen und Freigaben zusammenführt. Sie hilft beim Nachweisen der Arbeit, ersetzt aber keine Prüfung, ob alle erforderlichen Unterlagen vorliegen.

Zunächst benennt sie Verantwortliche für Produktsicherheit, Entwicklung und Kundenkommunikation. Danach erstellt sie eine Übersicht der unterstützten Versionen und ergänzt ihren Build-Prozess um die SBOM-Erzeugung.

Bei einem Testrelease stellt das Team fest: Eine mitgelieferte DLL ist zwar aufgeführt, ihre Version fehlt jedoch. Die Entwicklung ermittelt die tatsächlich ausgelieferte Version und korrigiert die Komponenteninformationen, bevor sie den Release freigibt.

Anschließend testet das Unternehmen den Sicherheitsprozess mit einer simulierten Schwachstellenwarnung. Die zuständige Person ordnet die betroffene Bibliothek den Releases zu, die Entwicklung bewertet ihre Verwendung und die Kundenbetreuung bereitet eine Updateinformation vor. Auch der Weg zur Entscheidung über eine Behördenmeldung wird durchgespielt.

Das Ergebnis ist eine vollständig vorbereitete Auslieferung: Die Firma kann Komponenten zuordnen, Zuständigkeiten nachweisen und auf neue Hinweise reagieren. Die Risikobewertung und die erforderliche Konformitätsbewertung bleiben eigenständige Aufgaben.

Der Msys SBOM Generator erzeugt für Delphi-Projekte SBOMs im maschinenlesbaren CycloneDX-Format. Ist die Erzeugung im Projekt aktiviert, entsteht die Komponentenübersicht automatisch beim erfolgreichen Kompilieren. Die Projektübersicht zeigt erkannte Pakete, Units und DLL-Importe; zusätzliche Komponenteninformationen können über eigene SBOMs und externe Module ergänzt werden.

Für automatisierte Build-Prozesse stehen Kommandozeilenwerkzeuge bereit. Sie analysieren einen bereits erstellten Build für die ausgewählte Plattform und Konfiguration. Die erzeugte SBOM kann anschließend geprüft und zusammen mit der Anwendung als Release-Artefakt archiviert werden. Ein PDF-Report ergänzt die maschinenlesbare Datei um eine lesbare Übersicht.

Eine nutzbare SBOM verbindet Komponenteninformationen mit einer konkreten Produktversion. Für Softwarehersteller entsteht ihr Wert im Zusammenspiel mit einem geregelten Sicherheitsprozess: Hinweise erkennen, Betroffenheit bewerten, Maßnahmen umsetzen und Nutzer sowie gegebenenfalls Behörden informieren.

Beginnen Sie deshalb mit der Produktübersicht, eindeutigen Verantwortlichkeiten und einem Testlauf vom Build bis zur Schwachstellenbearbeitung. Parallel gehören Risikobewertung, Unterstützungszeitraum, Dokumentation und Konformitätsbewertung auf die Planung für Dezember 2027.