O que é o Syft

O Syft é uma ferramenta de linha de comando da Anchore para gerar um SBOM, sigla em inglês para lista de materiais de software. Ele identifica pacotes e componentes presentes em imagens de contêiner, diretórios e arquivos.

O projeto é open source e pode ser usado localmente ou em automações de CI. A ideia é transformar um artefato que antes era difícil de inspecionar em um inventário que pode ser salvo, comparado e entregue junto da versão publicada.

Esse inventário ajuda a responder uma pergunta prática: quais bibliotecas realmente estão dentro do artefato que vai para produção? A resposta é útil para auditorias, correções de vulnerabilidades e rastreabilidade da cadeia de software.

💡
Dica

Gere o SBOM do mesmo artefato que será implantado. O arquivo de dependências do projeto pode não representar tudo que entrou na imagem final.

Como funciona

O Syft examina a fonte informada, como uma imagem Docker, um diretório ou um arquivo local, e tenta reconhecer os pacotes instalados. O resultado é uma relação estruturada de componentes e metadados encontrados.

Depois da descoberta, a ferramenta serializa o inventário em formatos como SPDX, CycloneDX, JSON e uma tabela legível no terminal. Cada formato atende a um uso diferente, desde inspeção humana até integração com outras ferramentas.

O Syft não é um scanner de vulnerabilidades. Ele produz o inventário que pode ser usado por ferramentas de análise e de gestão de risco. Separar descoberta de análise deixa o pipeline mais modular.

Principais recursos

O recurso central é a geração de SBOM a partir de imagens e sistemas de arquivos. Isso inclui pacotes de sistemas operacionais e dependências de linguagens quando eles são detectáveis no artefato.

Outro ponto forte é a variedade de formatos de saída. A tabela ajuda durante a investigação, enquanto JSON, SPDX e CycloneDX são mais adequados para arquivamento e integração.

A ferramenta também pode ser usada em pipelines automatizados. Assim, cada build pode produzir um inventário versionado, associado ao digest ou ao identificador do artefato publicado.

  • Entrada por imagem de contêiner, diretório ou arquivo.
  • Saída em tabela, JSON, SPDX e CycloneDX.
  • Execução local e integração com CI.

Como começar: instalação e acesso

A maneira mais simples é instalar um dos binários disponibilizados pelo projeto ou usar o gerenciador de pacotes compatível com seu sistema. Em ambientes de CI, prefira fixar uma versão conhecida em vez de depender sempre da mais recente.

Depois da instalação, confirme que o comando está disponível no terminal. O primeiro teste pode ser feito contra uma imagem que já exista no ambiente local ou contra um diretório pequeno do projeto.

syft version
syft Docker:nginx:latest
syft dir:./meu-projeto -o cyclonedx-json=sbom.json

Se o ambiente usar um registro privado, configure o acesso da mesma forma que o cliente de contêiner já usa. Não coloque tokens diretamente no comando ou no arquivo que será versionado.

Exemplo prático

Imagine uma aplicação publicada como a imagem minha-api:1.4. O objetivo é gerar um arquivo CycloneDX antes do push para o registro, guardar o resultado como artefato do pipeline e relacioná-lo ao build.

O comando abaixo grava o inventário em JSON. O nome do formato pode variar conforme a versão instalada, por isso vale conferir as opções disponíveis com a ajuda do próprio binário.

syft minha-api:1.4 -o cyclonedx-json=sbom-minha-api-1.4.json
cat sbom-minha-api-1.4.json

Na revisão, procure os nomes e as versões dos componentes. O passo seguinte é enviar esse arquivo para a ferramenta de segurança adotada pela equipe e definir políticas para componentes críticos.

⚠️
Atenção

Um SBOM é um retrato do artefato analisado. Se a imagem mudar depois da geração, gere outro arquivo para evitar uma associação incorreta.

Comparação com alternativas

O Trivy também pode gerar SBOM e acrescenta recursos de varredura de vulnerabilidades. Ele é interessante quando a equipe quer combinar inventário e análise em uma única ferramenta.

O SPDX e o CycloneDX não são concorrentes do Syft. Eles são padrões e formatos de intercâmbio. O Syft pode produzir arquivos nesses padrões para que outras soluções consumam o resultado.

Para um time que já tem um scanner separado, o Syft funciona bem como uma etapa focada em descoberta. Para um fluxo mais integrado, vale comparar a cobertura, o formato esperado e os relatórios das ferramentas disponíveis.

Pontos positivos e limitações

Entre os pontos positivos estão a execução simples, o foco claro em SBOM e a possibilidade de trabalhar com artefatos que já fazem parte do fluxo de contêineres. Isso reduz o esforço para começar.

A saída estruturada facilita guardar evidências por versão e comparar mudanças entre builds. Também é mais fácil automatizar validações quando o resultado não depende de copiar texto do terminal.

Há limitações: a identificação depende do conteúdo e dos metadados disponíveis, e nenhum gerador garante reconhecer todos os componentes. O SBOM também não substitui revisão de código, gestão de dependências ou análise de vulnerabilidades.

Casos de uso reais

Em uma equipe de plataforma, o Syft pode gerar um SBOM para cada imagem aprovada e anexá-lo ao pipeline. Isso cria uma trilha de auditoria sem exigir que cada desenvolvedor faça o processo manualmente.

Em uma empresa que distribui software, o inventário pode acompanhar releases e ajudar a responder rapidamente quando uma biblioteca é afetada por um alerta de segurança.

Em projetos menores, a execução local sobre a imagem final já oferece visibilidade valiosa. O time pode começar salvando o arquivo junto dos artefatos e evoluir depois para políticas automáticas.

Dicas e boas práticas

💡
Dica

Associe cada SBOM ao digest da imagem ou ao identificador imutável do build, não apenas a uma tag como latest.

🚀
Pro tip

Produza o arquivo no mesmo job que cria a imagem. Assim, o inventário nasce no ponto em que o conteúdo ainda pode ser relacionado ao código-fonte e aos logs do build.

🔴
Cuidado

Não trate a presença de um SBOM como prova de que o software é seguro. Use o inventário para investigar e priorizar riscos, mas mantenha as demais verificações.

Também é importante escolher um formato padrão para a equipe e documentar onde os arquivos ficam. A consistência vale mais do que gerar muitos formatos sem uma finalidade definida.

Vale a pena?

O Syft vale a pena para quem pública contêineres, mantém pipelines de software ou precisa responder com rapidez quais componentes estão em um artefato. A instalação e o primeiro teste são simples.

Ele não resolve sozinho a segurança da cadeia de fornecimento. Seu papel é fornecer uma base confiável de inventário para scanners, auditorias e decisões de manutenção.

O próximo passo é escolher uma imagem real do seu projeto, gerar o SBOM em um formato aceito pela equipe e guardar o arquivo junto do build. Depois, conecte essa evidência ao processo de análise de vulnerabilidades.