SBOM e Trivy: Segurança da Cadeia de Abastecimento para PME

1. Introdução — o que é SBOM

Um SBOM (Software Bill of Materials, ou Lista de Materiais de Software) é um inventário completo e detalhado de todos os componentes que constituem uma aplicação: bibliotecas directas, dependências transitivas, ferramentas de build e respectivas versões. Funciona como a “lista de ingredientes” do software — tal como os rótulos alimentares indicam o conteúdo de um produto, o SBOM revela tudo o que está dentro de uma aplicação.

A CISA (Cybersecurity and Infrastructure Security Agency) define SBOM como um registo formal e legível por máquina que descreve os componentes de software e as relações entre eles. Cada componente inclui nome, versão, fornecedor, hashes criptográficos e licença.

Para uma PME, o SBOM responde a três perguntas críticas:

• O que temos? — inventário exacto de todas as dependências, visíveis e transitivas.
• De onde vem? — origem, fornecedor e licença de cada componente.
• Tem vulnerabilidades? — correlação imediata com bases de dados como a NVD quando surge uma nova CVE.

Sem SBOM, quando é divulgada uma vulnerabilidade crítica (como Log4Shell em 2021), as equipas perdem dias a tentar descobrir onde estão os componentes afectados. Com SBOM, basta filtrar pelo nome e versão do componente vulnerável.

2. NIS2 e CRA — requisitos legais

Em 2026, o SBOM deixou de ser opcional. Duas directivas europeias tornam obrigatória a gestão da cadeia de abastecimento de software para um vasto conjunto de organizações, incluindo PME que desenvolvem ou integram produtos digitais.

Directiva NIS2 (Network and Information Security 2)

A NIS2 (Directiva (UE) 2022/2555) entrou em vigor em Outubro de 2024 e exige que entidades essenciais e importantes implementem medidas de gestão de riscos na cadeia de fornecimento digital. Embora não mencione “SBOM” explicitamente, o Artigo 21º exige que as organizações:

• Identifiquem e avaliem os riscos associados a fornecedores de TIC e prestadores de serviços.
• Garantam a segurança dos componentes directos ao longo de todo o ciclo de vida.
• Mantenham um inventário actualizado das dependências de software.

O SBOM é a ferramenta prática que permite cumprir estes requisitos. Sem ele, não é possível demonstrar auditoria da cadeia de fornecimento.

Cyber Resilience Act (CRA)

O CRA (Regulamento (UE) 2024/2847) é mais directo: exige explicitamente que os fabricantes de produtos com elementos digitais forneçam um SBOM. O Anexo I do regulamento estabelece que o SBOM deve ser:

• Gerado e mantido actualizado durante todo o ciclo de vida do produto.
• Fornecido às autoridades competentes mediante pedido.
• Legível por máquina, num formato normalizado (SPDX ou CycloneDX).

O calendário de aplicação do CRA é faseado: a partir de Dezembro de 2027, todos os produtos com elementos digitais colocados no mercado UE devem cumprir os requisitos, incluindo o SBOM. As PME precisam de começar a preparar-se já em 2026.

3. Formatos SBOM (CycloneDX vs SPDX)

Existem dois formatos principais de SBOM, ambos aceites pelo CRA e pela CISA:

Para a maioria das PME que se focam em segurança, o CycloneDX é a escolha recomendada: foi desenhado desde o início para análise de vulnerabilidades, suporta VEX (Vulnerability Exploitability eXchange) nativamente e integra-se bem com ferramentas de scan como Trivy. O SPDX é mais adequado quando o foco é conformidade de licenciamento open source.

Ambos os formatos são legíveis por máquina e incluem os campos mínimos exigidos pelo NTIA (National Telecommunications and Information Administration): nome do fornecedor, nome do componente, versão, dependências, hash criptográfico e identificador único.

4. Instalar Trivy

O Trivy é um scanner de segurança open source desenvolvido pela Aqua Security, escrito em Go, que combina geração de SBOM, detecção de vulnerabilidades e análise de configuração numa única ferramenta. É a opção mais completa e acessível para PME.

Instalação em Linux (Debian/Ubuntu)

# Descarregar e instalar o binário
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

# Verificar instalação
trivy --version

Instalação em macOS (Homebrew)

brew install trivy
trivy --version

Instalação via Docker (sem instalar nada)

# Executar Trivy sem instalar — útil para CI/CD
docker run --rm -v $(pwd):/work aquasec/trivy:latest fs --scanners vuln /work

O Trivy não requer configuração inicial: na primeira execução descarrega automaticamente a base de dados de vulnerabilidades da NVD e dos advisories de GitHub. O processo demora 2-3 minutos e é repetido periodicamente.

5. Gerar SBOM com Trivy

O Trivy gera SBOMs em CycloneDX e SPDX a partir de imagens Docker, sistemas de ficheiros, repositórios Git ou ficheiros de lock (package-lock.json, requirements.txt, go.mod, pom.xml, etc.).

SBOM CycloneDX a partir de uma imagem Docker

# Gerar SBOM CycloneDX (JSON) de uma imagem
trivy image --format cyclonedx --output sbom.json nginx:latest

# Verificar o conteúdo
cat sbom.json | python3 -m json.tool | head -30

SBOM SPDX a partir de um directório de projecto

# Gerar SBOM SPDX (JSON) de um directório
trivy fs --format spdx-json --output sbom-spdx.json ./meu-projecto

# Para um repositório Git
trivy repo --format cyclonedx --output sbom.json https://github.com/utilizador/repo

Analisar um SBOM existente

Uma das vantagens do Trivy é a capacidade de analisar um SBOM já gerado, sem necessidade de aceder ao código-fonte ou à imagem original:

# Scan de vulnerabilidades a partir de um SBOM
trivy sbom --scanners vuln sbom.json

Este fluxo é especialmente útil quando a equipa de desenvolvimento gera o SBOM e a equipa de segurança executa o scan separadamente, permitindo separação de responsabilidades.

6. Scan de Vulnerabilidades

Para além de gerar SBOMs, o Trivy funciona como scanner completo de vulnerabilidades. Identifica CVEs (Common Vulnerabilities and Exposures) em imagens Docker, sistemas de ficheiros, repositórios e até em ficheiros de configuração.

Scan de uma imagem Docker

# Scan completo de vulnerabilidades
trivy image nginx:latest

# Filtrar apenas vulnerabilidades CRÍTICAS e ALTAS
trivy image --severity CRITICAL,HIGH nginx:latest

# Formato JSON para integração com outras ferramentas
trivy image --format json --output resultado.json nginx:latest

Scan de sistema de ficheiros (projecto local)

# Scan de dependências num directório
trivy fs --scanners vuln ./meu-projecto

# Incluir análise de configuração (IaC)
trivy fs --scanners vuln,config ./meu-projecto

Interpretar os resultados

O Trivy apresenta os resultados organizados por severidade (CRITICAL, HIGH, MEDIUM, LOW, UNKNOWN). Cada vulnerabilidade inclui:

• CVE ID — identificador único na base de dados NVD.
• Severidade — classificação CVSS.
• Componente afectado — nome e versão do pacote.
• Versão corrigida — versão onde a vulnerabilidade foi resolvida.
• Fonte — advisory de origem (NVD, GitHub Advisory, etc.).

7. Automação em CI/CD

A geração de SBOM e o scan de vulnerabilidades só são eficazes se forem automatizados no pipeline de CI/CD. Isto garante que cada build é analisado e que novas vulnerabilidades são detectadas assim que são divulgadas.

GitHub Actions

name: SBOM e Scan de Vulnerabilidades

on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Instalar Trivy
        run: curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

      - name: Gerar SBOM CycloneDX
        run: trivy fs --format cyclonedx --output sbom.json .

      - name: Guardar SBOM como artefacto
        uses: actions/upload-artifact@v4
        with:
          name: sbom-cyclonedx
          path: sbom.json

      - name: Scan de vulnerabilidades
        run: trivy fs --scanners vuln --severity CRITICAL,HIGH --exit-code 1 .

O parâmetro --exit-code 1 faz o pipeline falhar se existirem vulnerabilidades CRITICAL ou HIGH, impedindo que código vulnerável chegue a produção.

GitLab CI

stages:
  - security

trivy-sbom:
  stage: security
  image: aquasec/trivy:latest
  script:
    - trivy fs --format cyclonedx --output sbom.json .
    - trivy fs --scanners vuln --severity CRITICAL,HIGH --exit-code 1 .
  artifacts:
    paths:
      - sbom.json
    expire_in: 30 days

Verificação periódica (cron)

Novas vulnerabilidades são divulgadas diariamente. Mesmo sem alterar o código, um componente pode tornar-se vulnerável. A verificação periódica via cron garante detecção contínua:

# Correr diariamente às 06:00 — scan de SBOM existente
0 6 * * * trivy sbom --scanners vuln --severity CRITICAL,HIGH \
  --format json --output /var/log/trivy/scan-$(date +\%F).json \
  /caminho/para/sbom.json

8. Boas Práticas

Para que o SBOM e o Trivy sejam efectivamente úteis, convém seguir um conjunto de boas práticas que vão além da mera execução da ferramenta:

Geração e armazenamento

• Gerar SBOM em cada build — não apenas em releases. As dependências mudam frequentemente entre commits.
• Armazenar SBOMs como artefactos — guardar cada versão do SBOM junto com o artefacto correspondente (imagem Docker, binário) durante todo o ciclo de vida do produto.
• Versionar SBOMs no Git — para projectos pequenos, guardar o SBOM no repositório permite histórico e auditoria.

Gestão de vulnerabilidades

• Estabelecer SLAs por severidade — CRITICAL: 48h; HIGH: 7 dias; MEDIUM: 30 dias; LOW: avaliar caso a caso.
• Corrigir, não ignorar — actualizar o componente para a versão corrigida sempre que possível. Usar .trivyignore apenas para falsos positivos documentados.
• Monitorizar continuamente — executar scans diários sobre SBOMs existentes, porque novas CVEs surgem todos os dias.
• Correlacionar com VEX — usar CycloneDX VEX para indicar que uma vulnerabilidade não é explorável no contexto específico, reduzindo alarmes falsos.

Conformidade e auditoria

• Manter registo de scans — guardar resultados de scans com data e versão do SBOM para demonstrar conformidade com NIS2 e CRA.
• Separar responsabilidades — desenvolvimento gera o SBOM; segurança executa o scan. Isto garante independência na auditoria.
• Revisão trimestral — auditar SBOMs antigos para identificar componentes desactualizados ou obsoletos.
• Documentar aceitação de risco — cada vulnerabilidade não corrigida deve ter justificação documentada e aprovada.

A segurança da cadeia de abastecimento de software deixou de ser uma preocupação apenas das grandes empresas. Com Trivy, uma PME pode implementar um programa robusto de SBOM e gestão de vulnerabilidades em horas, sem custos de licenciamento e com automação total via CI/CD. A janela de adaptação ao CRA fecha-se em Dezembro de 2027 — começar agora é a forma mais económica de garantir conformidade.

Para aprofundar, consultar as directrizes da CISA sobre SBOM, a documentação do CycloneDX e o repositório oficial do Trivy no GitHub.