Uma lista de verificação de SBOM da CRA dá-lhe uma página de licenças?

As equipas de produto devem tratar 2026 a 2027 como a janela para implementar o inventário de componentes, a geração de SBOM, os processos de vulnerabilidades, e (separadamente) os fluxos de divulgação de licenças. Esperar até à avaliação de conformidade para descobrir que não tem um registo de licenças de terceiros revisto cria duas crises em simultâneo.

Os calendários variam consoante a classe de produto e os atos de execução, e a documentação tem de se manter atualizada durante todo o período de suporte. Confirme todas as datas com o seu advogado; esta página não é aconselhamento jurídico.

O âmbito depende da classificação do produto, não do tamanho da empresa: os produtos com elementos digitais colocados no mercado da UE estão abrangidos, enquanto os produtos já cobertos por regras específicas de setor da UE (dispositivos médicos, veículos automóveis, aviação civil) e os serviços de cloud puros sem vertente de produto ficam geralmente excluídos. O software instalável, o firmware, os dispositivos ligados, e muitos modelos comerciais de distribuição open source podem estar abrangidos quando vendidos na UE.

As exclusões de SaaS puro existem no entendimento geral do mercado, mas exigem uma revisão jurídica específica ao produto.

A CRA exige um SBOM, mas isso não cobre a divulgação de licenças. O Anexo I, Parte II, obriga os fabricantes a identificar e documentar componentes, incluindo um SBOM num formato comum e legível por máquina, que cubra pelo menos as dependências de topo, o que são dados de identidade de componentes, não texto de licença revisto.

Essa obrigação acelera a adoção de SBOM entre os fornecedores que vendem na UE. As equipas produzem CycloneDX ou SPDX a partir do CI, muitas vezes pela primeira vez, e entregam os ficheiros à segurança ou à conformidade. O SBOM satisfaz a documentação de componentes da CRA. Não produz automaticamente o aviso, a atribuição, ou o texto integral de licença de cada componente.

A documentação de cibersegurança da CRA cobre a avaliação de risco, vulnerabilidades, atualizações, e desenvolvimento seguro. A segurança de produto, o PSIRT, e o jurídico são responsáveis por esse trabalho. A conformidade de licenças cobre as obrigações de propriedade intelectual em software de terceiros: aviso, atribuição, condições de copyleft. Um fluxo de trabalho diferente, com portões de revisão humana.

Confundir os dois cria falsa confiança. Uma equipa pode passar numa revisão interna de preparação para a CRA, com SBOMs e SLAs de patches, e continuar a falhar num pedido de conformidade de licenças de um comprador, porque ninguém reviu o texto da licença.

• SBOM da CRA: identidade de componentes para documentação de segurança e regulamentar.
• Divulgação de licenças: texto integral e atribuição para o jurídico e as compras.
• CRA: comunicação de vulnerabilidades às autoridades, em condições definidas.
• Licença: condições de direitos de autor e distribuição nas licenças OSS.
• O mesmo input de lockfile, resultados diferentes e responsáveis diferentes.

A CRA espera documentação atualizada durante o período de suporte, à medida que as vulnerabilidades e os componentes mudam. A mesma deriva de dependências quebra as declarações de licenças, se ninguém voltar a rever o que foi lançado.

As equipas com várias pessoas integram atualizações de pacotes continuamente. Sem reimportação e republicação a cada lançamento, tanto o seu SBOM da CRA como a sua divulgação de licenças descrevem o produto de ontem. A documentação regulamentar e os registos voltados para o comprador têm de acompanhar a base de código.

Os grandes clientes mapeiam a postura de CRA dos fornecedores nos seus programas de cadeia de fornecimento, e continuam a colar secções de licenças de modelos de RFP escritos antes de a CRA existir. Pedem SBOM, mais página de licenças open source, mais atestação de que a lista é mantida.

As compras já familiarizadas com a CRA vão esperar acesso duradouro aos artefactos de conformidade. Isso não substitui o conteúdo da divulgação de licenças. Eleva a exigência sobre quão atualizados e acessíveis os seus registos têm de ser.

Organização de segurança: geração de SBOM, gestão de vulnerabilidades, comunicação de incidentes, inputs de conformidade da CRA, entrega segura de atualizações.

Conformidade / jurídico / operações de engenharia: inventário de licenças de terceiros, revisão, portões de publicação, exportações de divulgação, respostas a questionários de compradores.

Input partilhado: lockfiles e SBOMs do CI. Resultado divergente: a segurança usa o SBOM para CVEs; a conformidade usa a mesma importação para registos de licenças revistos.