Análise de vulnerabilidades e SBOM
O CRA transforma a sua lista de materiais de software numa obrigação contínua: saber o que existe no seu produto, monitorizar esses componentes em busca de novas vulnerabilidades e corrigi-las e notificá-las dentro dos prazos do artigo 14.º. Esta página percorre este ciclo e apresenta a ferramenta gratuita que o concretiza.
Gerar uma SBOM
Elabore uma lista de materiais de software (SBOM) em formato legível por máquina que abranja, pelo menos, as suas dependências de nível superior. Trata-se de um requisito obrigatório, não de uma boa prática.
Como gerá-la ↓Monitorizar vulnerabilidades
Cruze continuamente cada componente com dados de vulnerabilidades em tempo real (NVD, EUVD). Resumos de notificações agrupadas não cumprem o prazo de 24 horas.
Porque é que os resumos agregados são insuficientes ↓Avaliar, corrigir e notificar
Documentar a explorabilidade, disponibilizar uma correção e comunicar as vulnerabilidades ativamente exploradas à ENISA e ao CSIRT no prazo de 24h / 72h / 14 dias.
A ferramenta que faz isto ↓Analisador de Vulnerabilidades do CRA
Carregue a sua SBOM e a lista de vulnerabilidades ativas. O Analyzer cruza cada componente com a National Vulnerability Database (NVD) e a base de dados de vulnerabilidades da UE (EUVD), assinala os componentes em fim de vida e gera um relatório de conformidade que pode anexar à sua documentação técnica.
Guias práticos
Gerar uma SBOM conforme
A lista de materiais de software é uma exigência legal estrita nos termos do anexo I, parte II, ponto 1. Este guia abrange o âmbito e o formato obrigatórios, a forma de a gerar e o modo como alimenta o ciclo de monitorização.
1 · Base jurídica
O anexo I, parte II («Requisitos relativos ao tratamento de vulnerabilidades»), ponto 1, exige que os fabricantes «identificar e documentar as vulnerabilidades e os componentes … nomeadamente através da elaboração de uma lista de materiais de software num formato comummente utilizado e legível por máquina que abranja, pelo menos, as dependências de nível superior do produto.»
Ao contrário de algumas disposições do CRA que permitem flexibilidade interpretativa, a obrigação de produzir uma SBOM legível por máquina que abranja, pelo menos, as dependências de nível superior não admite abordagens alternativas.
2 · Âmbito de aplicação e formato obrigatórios
Cobertura dos componentes. A SBOM deve documentar todas as dependências de nível superior, o mínimo legal e não o objetivo recomendado. Mapeie as dependências transitivas (indiretas) sempre que tal seja exequível; uma SBOM superficial cumpre a letra da lei, mas é frequentemente insuficiente para uma gestão eficaz das vulnerabilidades.
Formato. O CRA exige um «formato de uso corrente, legível por máquina». Os formatos aceites incluem:
- SPDX (ISO/IEC 5962:2021): amplamente adotado, centrado nas licenças, adequado à documentação de conformidade.
- CycloneDX: centrado na segurança, adequado a fluxos de trabalho de gestão de vulnerabilidades.
- Outros formatos estruturados (JSON, XML) provenientes de ferramentas reconhecidas são geralmente aceitáveis ao abrigo do requisito de base.
Não armazene as SBOM em PDF. O PDF pode ser contestado pelas autoridades de fiscalização do mercado por não ser legível por máquina. Armazene o resultado nativo em JSON, XML ou tag-value gerado pela sua cadeia de ferramentas.
Campos de metadados obrigatórios
| Campo | Descrição |
|---|---|
| Nome do componente | Identificador único da biblioteca, do pacote ou do módulo |
| Versão | Cadeia de versão exata; os intervalos de versões são insuficientes |
| Fornecedor / origem | Nome do editor, do fornecedor ou do projeto de fonte aberta |
| Relações de dependência | Diretas vs. transitivas; grafo de dependências sempre que viável |
| Hash criptográfico | Verificação de integridade SHA-256 ou mais forte por componente |
| Identificador da licença | Expressão de licença SPDX (por exemplo, Apache-2.0, MIT) |
3 · Gerar o seu SBOM
A maioria das plataformas modernas consegue gerar SBOM automaticamente no momento da compilação, sem custos adicionais:
- GitHub / Actions: Dependency Graph → Export SBOM (Settings → Code security). Gera SPDX JSON.
- GitLab: Os relatórios CycloneDX são gerados nativamente pela tarefa de CI/CD de análise de dependências.
- Syft (Anchore): CLI de fonte aberta que produz SPDX e CycloneDX para imagens de contentor, sistemas de ficheiros e manifestos de pacotes.
- cdxgen: Listas de materiais de software CycloneDX para npm, Maven, pip, Go, Rust e outros.
Rastreio de vulnerabilidades. Antes de finalizar qualquer SBOM, verifique todos os componentes em bases de dados de vulnerabilidades conhecidas. Tanto o scanner do GitHub como o Syft integram-se com Grype para o efeito. Incluir um componente com uma vulnerabilidade conhecida e já corrigida constitui uma violação direta do anexo I e não admite qualquer flexibilidade interpretativa.
Se existir uma versão corrigida de um componente, tem de a utilizar. Não existe uma categoria de «risco aceite» ao abrigo do CRA para vulnerabilidades resolvidas. Atue sobre cada constatação antes de colocar o produto no mercado.
4 · Manutenção e conservação ao longo do ciclo de vida
Uma SBOM é um artefacto vivo, atualizado continuamente ao longo do ciclo de vida com apoio do produto para refletir componentes corrigidos, novas dependências, componentes em fim de vida removidos e alterações na cadeia de abastecimento. Todas as versões da documentação técnica, incluindo as SBOM, devem ser conservadas durante, pelo menos, 10 anos a contar da primeira colocação no mercado…
Secções 4–9: ciclo de vida, sanções, BSI TR-03183-2 e a lista de verificação de preparação
O restante guia aborda o dever de conservação durante 10 anos, a confidencialidade e a divulgação na cadeia de abastecimento, a integração com a comunicação de vulnerabilidades do artigo 14.º, a frequência de monitorização, as regras mais rigorosas da BSI na Alemanha, as coimas (até 15 milhões de € ou 2,5 % do volume de negócios) e uma lista de verificação de preparação pronta a utilizar.
Ferramentas e análises relacionadas
Matriz de conformidade
Todas as obrigações do ciclo de vida com a respetiva referência ao artigo; acompanhe o seu progresso e descarregue a lista de verificação completa.
Ponto da situação atual
Ponto de situação atual do CRA: atos de execução, normas harmonizadas e o percurso até dezembro de 2027.
Calculadora de custos
Uma estimativa indicativa do custo provável de alcançar e manter a conformidade.