Si vous développez des logiciels pour le marché européen, quelqu'un vous a probablement déjà demandé une nomenclature logicielle. Le règlement sur la cyberrésilience impose aux fabricants d'en établir une et de la conserver dans leur documentation technique, et vos clients la réclament de plus en plus tôt, bien avant qu'un régulateur ne le fasse. Lorsque votre produit intègre une bibliothèque de composants, cette question nous revient.
À partir de cette version, chaque installation de sgcWebSockets y répond. L'installeur écrit une nomenclature CycloneDX dans le dossier d'installation sous le nom sbom.cdx.json, qui liste les composants de premier niveau dont la bibliothèque est constituée, avec leurs versions et leurs licences.
Générée par l'installeur, pas maintenue à la main
Ce qui est intéressant, ce n'est pas le fichier, c'est son origine. Une nomenclature que quelqu'un met à jour à la main devient obsolète, silencieusement, et un document de conformité qui indique une version que vous ne livrez plus est pire que pas de document du tout.
Elle n'est donc pas maintenue à la main. Le script de l'installeur exécute un générateur au moment de la construction, et ce générateur lit chaque version dans le fichier qui la détient réellement : la version du produit dans history.txt, Indy dans IdVers.inc, zlib dans zlib.h, OpenSSL dans les unités de liaison statique. Si l'une de ces valeurs ne peut pas être lue, le générateur s'arrête avec une erreur et la construction de l'installeur échoue. Il ne devine jamais, et il ne se rabat jamais sur une valeur que quelqu'un a saisie une fois pour toutes.
Concrètement, le SBOM ne peut pas dériver. Mettez zlib à jour et le prochain installeur que vous construisez le dira, sans que personne n'ait besoin de s'en souvenir.
Il décrit votre édition, pas un produit générique
C'est la partie qui a le plus de chances de compter pour vous. La nomenclature n'est pas la même pour chaque édition, parce que les éditions ne contiennent pas le même code tiers.
Enterprise et All-Access compilent l'Indy personnalisé livré avec sgcWebSockets, et ce fork apporte son propre zlib. Core, Standard et Professional se construisent avec l'Indy fourni par votre installation Delphi ou C++ Builder, que nous ne forkons ni ne redistribuons. Pour ces éditions, nous ne pouvons honnêtement indiquer aucune version d'Indy, car la version est celle que votre IDE fournit.
Un SBOM générique unique serait donc erroné pour la plupart des installations. À la place, l'installeur génère le document pour l'édition qu'il empaquette, de sorte que le fichier que vous recevez décrit ce que vous avez réellement.
| Édition | Indy | zlib |
|---|---|---|
| Core, Standard, Professional | fourni par votre IDE, non redistribué par nous | parvient au produit par ce même Indy |
| Enterprise, All-Access | le fork Indy personnalisé, version indiquée | la copie intégrée, version indiquée |
Ce qu'il contient
Le document est au format CycloneDX 1.6 JSON, un format lisible par machine courant que les outils d'inventaire et d'analyse comprennent déjà. En plus des composants, il enregistre la licence de chacun, s'il est redistribué par nous ou fourni par votre IDE, et l'emplacement qu'il occupe dans l'arborescence des sources.
Il porte également des déclarations VEX lorsqu'elles sont utiles. Si une CVE connue affecte la version d'un composant mais n'est pas atteignable depuis notre code, le document l'indique explicitement, avec la raison, plutôt que de vous laisser le déduire. Ces entrées apparaissent et disparaissent automatiquement à mesure que les versions des composants changent, car le générateur décide à partir de la version qu'il a lue, et non d'une note laissée par quelqu'un.
Où le trouver
Regardez dans le dossier où vous avez installé, à côté de history.txt et de la licence.
C:\Program Files (x86)\sgcWebSockets\sbom.cdx.jsonDonnez-le à l'outil que vous utilisez pour l'inventaire, joignez-le à un questionnaire fournisseur, ou intégrez ses entrées à la nomenclature que vous produisez pour votre propre produit. Si votre équipe conformité en a besoin dans un autre format, ou souhaite qu'un formulaire d'évaluation fournisseur soit rempli pour une build précise, demandez-le-nous via le formulaire de contact en précisant le produit, l'édition et la version que vous utilisez.
Une chose que nous n'avons délibérément pas faite
Nous ne publions pas le SBOM sur ce site. Le règlement sur la cyberrésilience impose aux fabricants d'en établir un et de le conserver dans la documentation technique, il n'en impose pas la publication, et il y a peu à gagner à remettre un inventaire de composants à quiconque le demande. En le livrant à l'intérieur du produit, nous le mettons entre les mains de ceux qui y ont droit, à savoir les licenciés et, sur demande, les autorités de surveillance du marché.
Vous pouvez en savoir plus sur notre approche du règlement sur notre page Cyber Resilience Act.