Si desarrollas software para el mercado europeo, es probable que alguien ya te haya pedido una lista de materiales de software. El Reglamento de Ciberresiliencia obliga a los fabricantes a elaborar una y conservarla en su documentación técnica, y tus clientes la piden cada vez más, mucho antes de que lo haga ningún regulador. Cuando tu producto integra una librería de componentes, esa pregunta acaba llegando hasta nosotros.
A partir de esta versión, cada instalación de sgcWebSockets la responde. El instalador escribe una lista de materiales CycloneDX en la carpeta de instalación con el nombre sbom.cdx.json, que enumera los componentes de primer nivel con los que está construida la librería, junto con sus versiones y licencias.
Generado por el instalador, no mantenido a mano
Lo interesante no es el archivo, sino de dónde procede. Una lista de materiales que alguien actualiza a mano queda obsoleta, sin hacer ruido, y un documento de conformidad que declara una versión que ya no distribuyes es peor que no tener documento alguno.
Por eso no se mantiene a mano. El script del instalador ejecuta un generador durante la compilación, y ese generador lee cada versión del archivo que realmente la define: la versión del producto desde history.txt, Indy desde IdVers.inc, zlib desde zlib.h, y OpenSSL desde las unidades de enlazado estático. Si alguno de esos valores no se puede leer, el generador se detiene con un error y la compilación del instalador falla. Nunca adivina, y nunca recurre a un valor que alguien escribió una vez.
El efecto práctico es que el SBOM no puede desviarse. Actualiza zlib y el siguiente instalador que compiles lo dirá, sin que nadie tenga que acordarse.
Describe tu edición, no un producto genérico
Esta es la parte que probablemente más te importe. La lista de materiales no es la misma para todas las ediciones, porque las ediciones no contienen el mismo código de terceros.
Enterprise y All-Access compilan el Indy personalizado que se distribuye con sgcWebSockets, y ese fork incorpora su propio zlib. Core, Standard y Professional se compilan contra el Indy que viene con tu instalación de Delphi o C++ Builder, que ni bifurcamos ni redistribuimos. Para esas ediciones no podemos indicar honestamente ninguna versión de Indy, porque la versión es la que proporcione tu IDE.
Por tanto, un único SBOM genérico sería incorrecto para la mayoría de las instalaciones. En su lugar, el instalador genera el documento para la edición que está empaquetando, de modo que el archivo que recibes describe lo que realmente tienes.
| Edición | Indy | zlib |
|---|---|---|
| Core, Standard, Professional | lo proporciona tu IDE, nosotros no lo redistribuimos | llega al producto a través de ese mismo Indy |
| Enterprise, All-Access | el fork personalizado de Indy, con la versión indicada | la copia incorporada, con la versión indicada |
Qué contiene
El documento es CycloneDX 1.6 en JSON, un formato legible por máquina muy extendido que las herramientas de inventario y de análisis ya entienden. Además de los componentes, registra la licencia de cada uno, si lo redistribuimos nosotros o lo proporciona tu IDE, y dónde reside dentro del árbol de código fuente.
También incluye declaraciones VEX allí donde resultan útiles. Si un CVE conocido afecta a la versión de un componente pero no es alcanzable desde nuestro código, el documento lo indica de forma explícita, con el motivo, en lugar de dejar que lo averigües tú. Esas entradas aparecen y desaparecen automáticamente a medida que cambian las versiones de los componentes, porque el generador lo decide a partir de la versión que ha leído, no de una nota que alguien dejó escrita.
Dónde encontrarlo
Búscalo en la carpeta donde has instalado, junto a history.txt y la licencia.
C:\Program Files (x86)\sgcWebSockets\sbom.cdx.jsonPásalo a la herramienta que uses para el inventario, adjúntalo a un cuestionario de proveedores, o incorpora sus entradas a la lista de materiales que elaboras para tu propio producto. Si tu equipo de conformidad lo necesita en otro formato, o quiere un formulario de evaluación de proveedores cumplimentado para una compilación concreta, escríbenos a través del formulario de contacto indicando el producto, la edición y la versión que utilizas.
Algo que deliberadamente no hemos hecho
No publicamos el SBOM en este sitio web. El Reglamento de Ciberresiliencia obliga a los fabricantes a elaborarlo y conservarlo en la documentación técnica, no exige su publicación, y poco se gana entregando un inventario de componentes a cualquiera que lo pida. Distribuirlo dentro del producto lo pone en manos de quienes tienen derecho a él, es decir, los licenciatarios y, previa solicitud, las autoridades de vigilancia del mercado.
Puedes leer más sobre cómo abordamos el Reglamento en nuestra página del Reglamento de Ciberresiliencia.