If you build software for the European market, someone has probably already asked you for a software bill of materials. The Cyber Resilience Act requires manufacturers to draw one up and keep it in their technical documentation, and your customers increasingly ask for one long before any regulator does. When your product embeds a component library, that question lands on us.
From this release, every sgcWebSockets setup answers it. The installer writes a CycloneDX bill of materials into the installation folder as sbom.cdx.json, listing the top level components the library is built from, with their versions and licences.
Generated by the installer, not maintained by hand
The interesting part is not the file, it is where it comes from. A bill of materials that someone updates by hand goes stale, quietly, and a compliance document that reports a version you no longer ship is worse than having no document at all.
So it is not maintained by hand. The installer script runs a generator at build time, and that generator reads each version from the file that actually owns it: the product version from history.txt, Indy from IdVers.inc, zlib from zlib.h, OpenSSL from the static linking units. If any of those values cannot be read, the generator stops with an error and the installer build fails. It never guesses, and it never falls back to a value someone typed in once.
The practical effect is that the SBOM cannot drift. Bump zlib and the next installer you build says so, with no one needing to remember.
It describes your edition, not a generic product
This is the part most likely to matter to you. The bill of materials is not the same for every edition, because the editions do not contain the same third party code.
Enterprise and All-Access compile the customised Indy that ships with sgcWebSockets, and that fork brings its own zlib. Core, Standard and Professional build against the Indy that comes with your Delphi or C++ Builder installation, which we neither fork nor redistribute. For those editions we cannot honestly state an Indy version at all, because the version is whatever your IDE provides.
A single generic SBOM would therefore be wrong for most installations. Instead the installer generates the document for the edition it is packaging, so the file you receive describes what you actually have.
| Edition | Indy | zlib |
|---|---|---|
| Core, Standard, Professional | supplied by your IDE, not redistributed by us | reaches the product through that same Indy |
| Enterprise, All-Access | the customised Indy fork, version stated | the vendored copy, version stated |
What is inside
The document is CycloneDX 1.6 JSON, which is a common machine readable format that inventory and scanning tools already understand. Alongside the components it records the licence of each one, whether we redistribute it or your IDE supplies it, and where it lives in the source tree.
It also carries VEX statements where they are useful. If a known CVE affects a component version but is not reachable from our code, the document says so explicitly, with the reason, rather than leaving you to work it out. Those entries appear and disappear automatically as component versions change, because the generator decides from the version it read, not from a note someone left behind.
Where to find it
Look in the folder you installed into, next to history.txt and the licence.
C:\Program Files (x86)\sgcWebSockets\sbom.cdx.jsonFeed it to whatever you use for inventory, attach it to a supplier questionnaire, or fold its entries into the bill of materials you produce for your own product. If your compliance team needs it in another format, or wants a supplier assessment form filled in for a specific build, ask us through the contact form with the product, edition and version you use.
One thing we deliberately did not do
We do not publish the SBOM on this website. The Cyber Resilience Act requires manufacturers to draw one up and keep it in the technical documentation, it does not require publication, and there is little to gain from handing a component inventory to anyone who asks. Shipping it inside the product puts it in the hands of the people who are entitled to it, which is licensees and, on request, market surveillance authorities.
You can read more about how we approach the Regulation on our Cyber Resilience Act page.