Do SBOM ao portão de vulnerabilidades: Syft e Grype na CI dos MSP

Os prestadores de serviços geridos que operam pipelines de CI para clientes podem combinar duas ferramentas open source da Anchore, Syft e Grype, num único portão para a cadeia de fornecimento de software: o Syft cataloga cada pacote de um build numa lista de materiais de software (SBOM), e o Grype confronta esse inventário com vulnerabilidades conhecidas antes de deixar o build passar. Este guia explica o que cada ferramenta faz, como se encaixam e onde a combinação, por si só, não basta.

Gere primeiro o inventário, com o Syft

O Syft, mantido pela Anchore sob licença Apache-2.0, gera um SBOM em SPDX ou CycloneDX a partir de imagens de contentores, sistemas de ficheiros e pacotes. A Anchore lançou o syft v1.52.0 a 17 de setembro, corrigindo dois erros de cataloger que produziam inventários imprecisos: o cataloger da base de dados RPM reportava uma versão de biblioteca desatualizada numa imagem Rocky Linux 10 de camada única, e o cataloger de arquivos Java devolvia uma versão desconhecida para uber-jars. O lançamento traz também manutenção de dependências: 52 alterações que corrigem seis vulnerabilidades conhecidas, incluindo uma atualização da biblioteca grpc-go que fechou vários avisos publicados. As correções do cataloger contam sobretudo para equipas que dependem de imagens baseadas em RPM ou uber-jars Java, onde uma versão desatualizada ou desconhecida no SBOM acabaria por mascarar o que um scanner posterior está realmente a verificar.

O Grype transforma o inventário num portão

O Grype, também mantido pela Anchore, analisa imagens de contentores, sistemas de ficheiros e SBOM em busca de vulnerabilidades conhecidas. A 23 de setembro de 2026, o seu repositório no GitHub mostrava cerca de 12.900 estrelas e um commit de dois dias antes, sinal de manutenção ativa. Integrado numa pipeline de CI logo após a geração do SBOM, o Grype permite falhar um build automaticamente quando surge uma CVE conhecida, em vez de depender de alguém se lembrar de verificar mais tarde. O fluxo habitual gera o SBOM durante o build, normalmente com o Syft, e depois executa o Grype contra esse SBOM e, opcionalmente, diretamente contra a imagem construída, verificando cada componente listado face aos dados de vulnerabilidades conhecidas. Um limiar de gravidade decide se o job falha: tudo o que o ultrapasse bloqueia o merge, salvo exceção registada, com responsável e prazo.

Torne as exceções visíveis, não silenciosas

Um portão fail-closed só é útil se as exceções forem visíveis e tiverem um responsável. Sem um processo escrito, as equipas acabam por desligar o portão na primeira vez que bloqueia algo urgente, ou acumulam contornos silenciosos que anulam o próprio sentido da análise. Uma exceção deve indicar um responsável, um motivo e uma data de expiração após a qual o achado é reavaliado, em vez de ficar isento indefinidamente.

O que o portão não faz

O Grype indica o que é conhecido como vulnerável naquilo que está prestes a ser lançado; não aplica patches, não impõe o princípio do privilégio mínimo nem substitui a monitorização em runtime depois de a carga de trabalho ser implementada. Depende ainda da atualização da sua base de dados de vulnerabilidades, pelo que fixar o scanner a um feed desatualizado anula o propósito. Ao padronizar esta abordagem entre pipelines de clientes, a prática recomendada é testar primeiro os limiares de gravidade numa pipeline que não seja de produção, porque um limiar demasiado agressivo só vai ensinar as equipas a contornar o portão. Arquivar cada SBOM junto do respetivo artefacto de build também transforma esse mesmo inventário num pacote de evidências para clientes ou seguradoras, sem custo adicional de análise. Os prestadores que precisem de apoio externo em testes de penetração, avaliação de vulnerabilidades, resposta a incidentes ou conformidade com o NIS2/DORA/RGPD podem recorrer aos serviços de cibersegurança da Altovar.

O que fazer

• Adicione o Syft como etapa de build que emite um SBOM SPDX ou CycloneDX para cada imagem ou artefacto, e faça o build falhar se a geração der erro.
• Execute o Grype contra esse SBOM, e opcionalmente contra a imagem construída, logo a seguir, com um limiar de gravidade testado antes numa pipeline que não seja de produção.
• Escreva o processo de exceção antes de o portão entrar em produção: quem pode concedê-la, o que deve registar e quando expira.
• Arquive cada SBOM junto do respetivo artefacto de build, para que possa servir depois como pacote de evidências para clientes ou seguradoras.
• Mantenha atualizada a base de dados de vulnerabilidades do Grype; um feed desatualizado deixa passar builds que o portão devia ter bloqueado.
• Combine o portão com patching e monitorização em runtime, porque nenhuma das duas ferramentas cobre o que acontece depois da implementação.

Fontes: Grype no GitHub, lançamentos do anchore/syft.