Wenn Sie Software für den europäischen Markt entwickeln, hat Sie vermutlich schon jemand nach einer Software-Stückliste gefragt. Der Cyber Resilience Act verpflichtet Hersteller, eine solche zu erstellen und in ihrer technischen Dokumentation zu führen, und Ihre Kunden fragen zunehmend danach, lange bevor es eine Aufsichtsbehörde tut. Wenn Ihr Produkt eine Komponentenbibliothek einbettet, landet diese Frage bei uns.
Mit diesem Release beantwortet jedes sgcWebSockets-Setup sie. Der Installer schreibt eine CycloneDX-Stückliste als sbom.cdx.json in den Installationsordner und listet darin die Komponenten der obersten Ebene auf, aus denen die Bibliothek gebaut wird, mit ihren Versionen und Lizenzen.
Vom Installer erzeugt, nicht von Hand gepflegt
Das Interessante ist nicht die Datei, sondern ihre Herkunft. Eine Stückliste, die jemand von Hand aktualisiert, veraltet still und leise, und ein Compliance-Dokument, das eine Version nennt, die Sie gar nicht mehr ausliefern, ist schlimmer als gar kein Dokument.
Sie wird also nicht von Hand gepflegt. Das Installer-Skript führt zur Build-Zeit einen Generator aus, und dieser Generator liest jede Version aus der Datei, die sie tatsächlich verwaltet: die Produktversion aus history.txt, Indy aus IdVers.inc, zlib aus zlib.h, OpenSSL aus den Units für das statische Linken. Lässt sich einer dieser Werte nicht lesen, bricht der Generator mit einem Fehler ab und der Installer-Build schlägt fehl. Er rät nie, und er greift nie auf einen Wert zurück, den jemand einmal eingetippt hat.
Praktisch bedeutet das, dass die SBOM nicht abweichen kann. Aktualisieren Sie zlib, dann sagt der nächste Installer, den Sie bauen, genau das, ohne dass jemand daran denken müsste.
Sie beschreibt Ihre Edition, nicht ein generisches Produkt
Das ist der Teil, der für Sie am ehesten von Bedeutung ist. Die Stückliste ist nicht für jede Edition gleich, denn die Editionen enthalten nicht denselben Code von Drittanbietern.
Enterprise und All-Access kompilieren das angepasste Indy, das mit sgcWebSockets ausgeliefert wird, und dieser Fork bringt sein eigenes zlib mit. Core, Standard und Professional werden gegen das Indy gebaut, das Ihrer Delphi- oder C++ Builder-Installation beiliegt und das wir weder forken noch weitergeben. Für diese Editionen können wir ehrlicherweise überhaupt keine Indy-Version angeben, denn die Version ist diejenige, die Ihre IDE bereitstellt.
Eine einzige generische SBOM wäre daher für die meisten Installationen falsch. Stattdessen erzeugt der Installer das Dokument für die Edition, die er gerade paketiert, sodass die Datei, die Sie erhalten, beschreibt, was Sie tatsächlich haben.
| Edition | Indy | zlib |
|---|---|---|
| Core, Standard, Professional | von Ihrer IDE bereitgestellt, nicht von uns weitergegeben | gelangt über eben dieses Indy in das Produkt |
| Enterprise, All-Access | der angepasste Indy-Fork, Version angegeben | die mitgelieferte Kopie, Version angegeben |
Was darin enthalten ist
Das Dokument ist CycloneDX 1.6 JSON, ein verbreitetes maschinenlesbares Format, das Inventar- und Scan-Werkzeuge bereits verstehen. Neben den Komponenten hält es die Lizenz jeder einzelnen fest, ob wir sie weitergeben oder Ihre IDE sie bereitstellt, und wo sie im Quellbaum liegt.
Es enthält außerdem VEX-Angaben, wo diese nützlich sind. Betrifft ein bekannter CVE eine Komponentenversion, ist aber aus unserem Code nicht erreichbar, sagt das Dokument dies ausdrücklich samt Begründung, statt es Ihnen zu überlassen, das herauszufinden. Solche Einträge erscheinen und verschwinden automatisch, wenn sich Komponentenversionen ändern, denn der Generator entscheidet anhand der Version, die er gelesen hat, nicht anhand einer Notiz, die jemand hinterlassen hat.
Wo Sie sie finden
Schauen Sie in den Ordner, in den Sie installiert haben, neben history.txt und die Lizenz.
C:\Program Files (x86)\sgcWebSockets\sbom.cdx.jsonÜbergeben Sie sie dem Werkzeug, das Sie zur Inventarisierung einsetzen, hängen Sie sie an einen Lieferantenfragebogen an, oder übernehmen Sie ihre Einträge in die Stückliste, die Sie für Ihr eigenes Produkt erstellen. Wenn Ihr Compliance-Team sie in einem anderen Format benötigt oder einen ausgefüllten Lieferantenbewertungsbogen für einen bestimmten Build wünscht, fragen Sie uns über das Kontaktformular und nennen Sie dabei Produkt, Edition und Version, die Sie verwenden.
Eines haben wir bewusst nicht getan
Wir veröffentlichen die SBOM nicht auf dieser Website. Der Cyber Resilience Act verlangt von Herstellern, eine solche zu erstellen und in der technischen Dokumentation zu führen, er verlangt keine Veröffentlichung, und es ist wenig damit gewonnen, ein Komponenteninventar an jeden herauszugeben, der danach fragt. Indem wir sie im Produkt ausliefern, gelangt sie in die Hände derjenigen, denen sie zusteht, also der Lizenznehmer und, auf Anfrage, der Marktüberwachungsbehörden.
Mehr dazu, wie wir mit der Verordnung umgehen, lesen Sie auf unserer Seite zum Cyber Resilience Act.