devops-kung-fu/bomberEscaneia Listas de Materiais de Software (SBOMs) em busca de vulnerabilidades de segurança
bomber é uma aplicação que analisa SBOMs em busca de vulnerabilidades de segurança.
Então você pediu a um fornecedor uma Lista de Materiais de Software (SBOM) para um de seus produtos de código fechado, e eles forneceram uma em um arquivo JSON... e agora?
A primeira coisa que você vai querer fazer é verificar se algum dos componentes listados na SBOM possui vulnerabilidades de segurança, e que tipo de licenças esses componentes têm. Isso ajudará você a identificar o tipo de risco que estará assumindo ao usar o produto.
Encontrar vulnerabilidades de segurança e informações de licença para componentes identificados em uma SBOM é exatamente para o que bomber foi criado. bomber pode ler qualquer formato JSON ou XML baseado em CycloneDX, ou uma SBOM formatada em JSON SPDX ou Syft, e informar rapidamente se existem vulnerabilidades.
O software pode ser de código aberto ou fechado. Você pode considerar componentes de terceiros encontrados no GitHub ou em qualquer repositório público de código fonte como código aberto. Tecnicamente, o software que você cria internamente em sua própria empresa também é código aberto – não é público, mas suas equipes internas podem vê-lo. O software de código fechado também pode ser interno, mas geralmente é aquele que você compra de fornecedores externos.
As empresas podem usar ferramentas SCA fornecidas por fornecedores como GitHub, Sonatype, Snyk, etc., para analisar qualquer tipo de código aberto e fornecer dados de vulnerabilidade – e até gerar SBOMs em alguns casos. O que eles não podem fazer (ainda...) é analisar software de código fechado ao qual você não tem visibilidade. É aqui que as SBOMs e o bomber entram em ação. As SBOMs fornecem a composição do software ao qual você não pode acessar, e o bomber determina se algo na SBOM possui vulnerabilidades.
Criamos o bomber para analisar as SBOMs de código fechado fornecidas quando você as recebe de fornecedores. Ele também pode analisar SBOMs de código aberto e, tecnicamente, você poderia usar o bomber como uma ferramenta SCA de código aberto, se desejar.
Existem vários formatos de SBOM disponíveis atualmente. bomber suporta os seguintes:
bomber suporta múltiplas fontes de informações sobre vulnerabilidades. Chamamos essas fontes de provedores. Atualmente, bomber usa OSV como provedor padrão, mas você também pode usar o Banco de Dados de Avisos do GitHub, o Índice OSS da Sonatype ou Snyk.
Neste momento, observe que OSV é gratuito e não requer credenciais para uso; Índice OSS da Sonatype é gratuito, mas exige registro e obtenção de um token; e o suporte a Snyk requer uma licença Snyk.
Além dos dados que o bomber coleta dos Provedores, ele também enriquece os dados de vulnerabilidade com informações extras, como probabilidades de exploração.
Observe que cada provedor suporta ecossistemas diferentes, então, se você não estiver vendo vulnerabilidades em um, tente outro. Um ecossistema é simplesmente o gerenciador de pacotes ou o tipo de pacote. Exemplos incluem rpm, npm, gems, etc. É importante entender que cada provedor pode relatar vulnerabilidades diferentes. Em caso de dúvida, consulte alguns deles.
Se o bomber não encontrar vulnerabilidades, isso não significa que não existam. Significa apenas que o provedor usado não detectou nenhuma ou não suporta o ecossistema. Alguns provedores têm vulnerabilidades que retornam sem informações de Gravidade. Nesse caso, a Gravidade será listada como "UNDEFINED".
A documentação dos provedores para o bomber pode ser encontrada:
Você pode usar o Homebrew para instalar o bomber usando o seguinte:
brew tap devops-kung-fu/homebrew-tap
brew install devops-kung-fu/homebrew-tap/bomber
Se você não tiver o Homebrew, ainda pode baixar a versão mais recente (ex: bomber_0.4.1_darwin_all.tar.gz), extrair os arquivos do arquivo e usar o binário bomber.
Se desejar, você pode mover o binário bomber para o diretório /usr/local/bin ou para qualquer lugar em seu PATH.
Para instalar o bomber, baixe a versão mais recente para sua plataforma e instale localmente. Por exemplo, instale o bomber no Ubuntu:
dpkg -i bomber_0.5.0_linux_arm64.deb
Você pode analisar uma pasta inteira de SBOMs ou uma SBOM individual com o bomber. O bomber não se importa se você tiver múltiplos formatos em uma única pasta. Ele organizará tudo para você.
Observe que a saída padrão do bomber é para STDOUT. Opções para saída em HTML ou JSON são descritas posteriormente neste documento.
# Usando OSV (o provedor padrão) que não requer credenciais
bomber scan cyclonedx.sbom.json
# Usando um provedor que requer credenciais (ossindex)
bomber scan --provider=xxx --username=xxx --token=xxx [sbom.json]
Se o provedor encontrar vulnerabilidades, você verá uma saída semelhante à seguinte:
Se o provedor não retornar vulnerabilidades, você verá uma mensagem informando que nenhuma vulnerabilidade foi encontrada.
NOTA: O fato de não ter encontrado vulnerabilidades usando um provedor específico não significa que não existam vulnerabilidades. Por favor, tente os outros provedores que o bomber suporta.
Isso é útil quando você recebe múltiplas SBOMs de um fornecedor para o mesmo produto. Ou, talvez, você queira descobrir quais vulnerabilidades existem em toda a sua organização. Uma análise de pasta encontrará todos os componentes, os desduplicará e os analisará em busca de vulnerabilidades.
# analisar uma pasta de SBOMs (o comando a seguir analisará uma pasta em seu diretório atual chamada "sboms")
bomber scan --provider=xxx --username=xxx --token=xxx ./sboms
Você verá um resultado semelhante ao fornecido por uma análise de SBOM única.
bomber gera dados em três formatos úteis. Por padrão, a saída é renderizada na linha de comando. Para relatórios aprimorados, você pode gerar saída em HTML usando a flag --output=html. Para saída em JSON, utilize a flag --output=json. Use a especificação de saída separada por vírgulas para obter saída em múltiplos formatos --output=html,stdout,json.
Se você deseja um relatório legível com informações detalhadas de vulnerabilidade, pode utilizar a flag --output para salvar um relatório em um arquivo HTML.
Exemplo de comando:
bomber scan bad-bom.json --output=html
Isso salvará um arquivo em sua pasta atual no formato "YYYY-MM-DD-HH-MM-SS-bomber-results.html". Se você abrir este arquivo em um navegador web, verá uma saída como a seguinte:
bomber pode gerar dados de vulnerabilidade em formato JSON usando a flag --output. A saída padrão é para STDOUT. Há muito mais informações na saída JSON do que é exibido no terminal. Você poderá ver uma descrição do pacote e seu propósito, o nome da vulnerabilidade, um resumo da vulnerabilidade e mais.
Exemplo de comando:
bomber scan bad-bom.json --output=json > filename.json
bomber também suporta saída em formato Markdown. Isso é muito semelhante à saída HTML, mas transfere a estilização para o renderizador Markdown, como o GitHub. A saída é salva em um arquivo no formato "YYYY-MM-DD-HH-MM-SS-bomber-results.md".
Exemplo de comando:
bomber scan bad-bom.json --output=md
Se necessário, você pode usar a flag --ignore-file para carregar uma lista de CVEs a serem ignoradas na saída de vulnerabilidades. Essa lista precisa estar em um formato específico, onde cada CVE a ser ignorada é inserida em uma linha separada, semelhante ao seguinte:
CVE-2022-31163
CVE-2022-23520
Há um arquivo de exemplo bomber.ignore aqui
Para usar o arquivo bomber.ignore, use a sintaxe da seguinte forma:
bomber --ignore-file=bomber.ignore scan bom.json
Você pode definir o nível de gravidade com a flag --severity para retornar gravidades específicas de vulnerabilidades. Por exemplo, se você definir --severity=moderate, apenas vulnerabilidades com gravidade MODERATE ou superior serão retornadas.
Por exemplo, o seguinte comando retornará apenas vulnerabilidades altas e críticas.
bomber --severity=high scan bom.json
bomber tem a capacidade de enriquecer dados de vulnerabilidade obtidos dos Provedores. O primeiro "enriquecedor" que implementamos é para EPSS
NOTA: A pontuação EPSS não é mais padrão no bomber 0.5.0 e superior. Para mostrar pontuações EPSS, certifique-se de usar a flag --enrich=epss.
EPSS significa Sistema de Pontuação de Previsão de Exploração, e é um framework que prevê a probabilidade de uma vulnerabilidade ser explorada. EPSS é frequentemente usado para ajudar a identificar vulnerabilidades de alto risco a serem priorizadas para remediação.
EPSS usa uma porcentagem para probabilidade. Portanto, se você vir 94, a pontuação está tentando dizer que essa vulnerabilidade tem 94% de probabilidade de exploração. E é lógico que uma vulnerabilidade com uma pontuação como 94 merece atenção imediata, enquanto uma vulnerabilidade com uma pontuação como, digamos, 20 merece uma prioridade menor.
Se desejar, você pode definir duas variáveis de ambiente para armazenar suas credenciais e evitar digitá-las na linha de comando. Confira as informações sobre Variáveis de Ambiente mais adiante neste README.
Se você estiver usando bomber em seus pipelines de CI/CD, pode fazer um comando tudo-em-um com o Syft para gerar e analisar uma SBOM em busca de vulnerabilidades. Para fazer isso, você pode usar um comando como o seguinte:
# Certifique-se de incluir o caractere - no final do comando. Isso aciona o bomber para ler do STDIN
syft packages . -o cyclonedx-json | bomber scan --provider ossindex --output json -
Este comando cria uma SBOM, a canaliza para o bomber e gera resultados em formato JSON.
Se você não quiser inserir credenciais o tempo todo, pode adicionar o seguinte ao seu .bashrc ou .bash_profile
export BOMBER_PROVIDER_USERNAME={{seu nome de usuário do OSS Index}}
export BOMBER_PROVIDER_TOKEN={{seu token de API do OSS Index}}
Usar a flag --exitcode retornará um código de saída representando a maior gravidade de vulnerabilidade encontrada. Sem essa flag, você pode esperar um código de saída 0 para sucesso, ou 1 se um erro for encontrado.
Supondo que não haja erro, os seguintes valores serão retornados pelo bomber quando --exitcode for usado:
| Gravidade | Código de Retorno |
|---|---|
| UNSPECIFIED (Este é um status em que o provedor nos fornece algo estranho, ou nenhuma informação) | 10 |
| LOW | 11 |
| MODERATE |
bomber agora contém uma funcionalidade experimental que enriquece a descrição de vulnerabilidades em uma saída html. Essa funcionalidade pega uma vulnerabilidade e transforma a descrição em algo mais compreensível para um usuário não técnico.
NOTA: Esta funcionalidade está em um estado alpha neste momento. É extremamente lenta e a saída não está muito bem formatada.
Para usar esta funcionalidade, você precisará fornecer uma chave de API OpenAI. Você pode passar esta chave para a CLI usando a flag --openai-api-key={{sua chave de API OpenAI}} ou adicionar uma variável de ambiente:
export OPENAI_API_KEY={{sua chave de API OpenAI}}
Após definir sua chave de API OpenAI, você pode definir a flag de saída da seguinte forma:
bomber scan --output ai [sbom.json]
Se você quiser experimentar o bomber, encontrará uma seleção de SBOMs de teste na pasta teste.
--license. Se você precisar de informações de licença, certifique-se de solicitá-las junto com a SBOM.bomber precisa enviar um PURL de cada vez para obter vulnerabilidades, então em uma SBOM grande levará algum tempo. Ficaremos de olho nisso.Se você gostaria de contribuir para o desenvolvimento do bomber, consulte o arquivo CONTRIBUTING.md neste repositório. Por favor, leia o arquivo CODE_OF_CONDUCT.md antes de contribuir.
O bomber usa o Syft para gerar uma Lista de Materiais de Software toda vez que um desenvolvedor envia código para este repositório (desde que o Hookz esteja sendo usado e tenha sido inicializado no diretório de trabalho). Mais informações sobre o CycloneDX estão disponíveis aqui.
A SBOM CycloneDX atual para o bomber está disponível aqui.
Agradecemos aos patrocinadores e apoiadores do bomber
Um grande agradecimento aos nossos amigos da ZERO pelo logotipo do bomber.
Agradecimentos à Sonatype por fornecer uma ferramenta incrível como o Índice OSS da Sonatype.
Muitos agradecimentos aos nossos amigos e colegas contribuidores do bomber na Snyk por criarem um provedor e codificar o processamento de uma SBOM via STDIN. Vocês são demais.
A descrição do EPSS vem da equipe da Nucleus. Obrigado!
| 12 |
| HIGH | 13 |
| CRITICAL | 14 |