Se você desenvolve software para o mercado europeu, provavelmente alguém já lhe pediu uma lista de materiais de software. O Regulamento de Ciberresiliência exige que os fabricantes elaborem uma e a mantenham em sua documentação técnica, e seus clientes a pedem cada vez mais, muito antes de qualquer órgão regulador. Quando o seu produto incorpora uma biblioteca de componentes, essa pergunta chega até nós.
A partir desta versão, toda instalação do sgcWebSockets responde a ela. O instalador grava uma lista de materiais CycloneDX na pasta de instalação como sbom.cdx.json, relacionando os componentes de nível superior a partir dos quais a biblioteca é construída, com suas versões e licenças.
Gerado pelo instalador, não mantido à mão
A parte interessante não é o arquivo, é de onde ele vem. Uma lista de materiais que alguém atualiza à mão fica desatualizada, silenciosamente, e um documento de conformidade que informa uma versão que você já não distribui é pior do que não ter documento algum.
Por isso ela não é mantida à mão. O script do instalador executa um gerador no momento da compilação, e esse gerador lê cada versão a partir do arquivo que realmente a define: a versão do produto em history.txt, o Indy em IdVers.inc, o zlib em zlib.h, o OpenSSL nas unidades de vinculação estática. Se algum desses valores não puder ser lido, o gerador para com um erro e a compilação do instalador falha. Ele nunca adivinha e nunca recorre a um valor que alguém digitou uma vez.
O efeito prático é que o SBOM não pode divergir. Atualize o zlib e o próximo instalador que você compilar já dirá isso, sem que ninguém precise se lembrar.
Ele descreve a sua edição, não um produto genérico
Esta é a parte que mais provavelmente importa para você. A lista de materiais não é a mesma para todas as edições, porque as edições não contêm o mesmo código de terceiros.
Enterprise e All-Access compilam o Indy personalizado que acompanha o sgcWebSockets, e esse fork traz o seu próprio zlib. Core, Standard e Professional compilam com o Indy que vem com a sua instalação do Delphi ou do C++ Builder, do qual não fazemos fork nem redistribuímos. Para essas edições não podemos, honestamente, indicar uma versão do Indy, porque a versão é a que o seu IDE fornece.
Um único SBOM genérico seria, portanto, incorreto para a maioria das instalações. Em vez disso, o instalador gera o documento para a edição que está empacotando, de modo que o arquivo que você recebe descreve o que você realmente tem.
| Edição | Indy | zlib |
|---|---|---|
| Core, Standard, Professional | fornecido pelo seu IDE, não redistribuído por nós | chega ao produto por meio desse mesmo Indy |
| Enterprise, All-Access | o fork personalizado do Indy, com versão indicada | a cópia incorporada, com versão indicada |
O que há dentro
O documento é CycloneDX 1.6 em JSON, um formato legível por máquina bastante comum que as ferramentas de inventário e de varredura já compreendem. Além dos componentes, ele registra a licença de cada um, se somos nós que o redistribuímos ou se o seu IDE o fornece, e onde ele fica na árvore de código-fonte.
Ele também traz declarações VEX quando são úteis. Se uma CVE conhecida afeta a versão de um componente mas não é alcançável a partir do nosso código, o documento diz isso explicitamente, com o motivo, em vez de deixar você descobrir sozinho. Essas entradas aparecem e desaparecem automaticamente conforme as versões dos componentes mudam, porque o gerador decide a partir da versão que leu, e não de uma anotação que alguém deixou.
Onde encontrá-lo
Procure na pasta em que você instalou, ao lado do history.txt e da licença.
C:\Program Files (x86)\sgcWebSockets\sbom.cdx.jsonEntregue-o ao que você usar para inventário, anexe-o a um questionário de fornecedores ou incorpore suas entradas à lista de materiais que você produz para o seu próprio produto. Se a sua equipe de conformidade precisar dele em outro formato, ou quiser um formulário de avaliação de fornecedor preenchido para uma compilação específica, fale conosco pelo formulário de contato informando o produto, a edição e a versão que você usa.
Uma coisa que deliberadamente não fizemos
Não publicamos o SBOM neste site. O Regulamento de Ciberresiliência exige que os fabricantes elaborem uma lista e a mantenham na documentação técnica, não exige a publicação, e há pouco a ganhar em entregar um inventário de componentes a qualquer um que o peça. Distribuí-lo dentro do produto o coloca nas mãos de quem tem direito a ele, ou seja, os licenciados e, mediante solicitação, as autoridades de fiscalização do mercado.
Você pode ler mais sobre como abordamos o Regulamento em nossa página do Cyber Resilience Act.