Sobre SBOMs, BitBucket e OWASP Dependency Track

Tutoriais

O museu de arquiteturas antigas e novas com o qual estou envolvido me obrigou a procurar formas de protegê-las. Por exemplo, uma dependência antiga pode se tornar CVE ou um projeto sólido de código aberto pode se tornar comercial. Foi assim que surgiu o conceito de um Software Bill of Material (SBOM) para catalogar as licenças e o ecossistema de dependências dos sistemas. Este artefato de construção, por sua vez, é então analisado para determinar se os componentes que o constituem estão:

  1. Vulneráveis à exploração, ou
  2. Licenciados sob condições desagradáveis, como sendo muito comerciais ou muito predatórios.

Este artigo explicará como controlar essa vulnerabilidade usando:

  1. BitBucket pipes para geração de SBOM, e
  2. Como o Dependency Track da OWASP pode analisá-lo.

Conheça Seu Risco

Não saber o que se esconde em seu código e contêineres é uma bênção, mas perigoso. No entanto, passar todos os seus componentes por um analisador de dependências pode fornecer feedback esmagador. É melhor criar um painel de controle e incorporar na cultura da equipe que a quantidade de problemas de dependência deve ser sempre menor hoje do que era ontem.

A Wikipedia afirma que: “O Projeto de Segurança de Aplicações em Todo o Mundo Aberto (OWASP) é uma comunidade online que produz artigos, metodologias, documentação, ferramentas e tecnologias livremente disponíveis nos campos de IoT, software de sistema e segurança de aplicações web.” Portanto, não é surpreendente que eles forneçam uma plataforma para rastrear e analisar vulnerabilidades em sistemas. Sua característica mais marcante é seu painel principal:

O maior gráfico no meio exibe o número de vulnerabilidades de todos os projetos sendo rastreados. As métricas de vulnerabilidades críticas, médias e baixas são exibidas logo abaixo. O Dependency Track recupera vulnerabilidades conhecidas de uma ou mais fontes. A mais notável delas é a lista de Common Vulnerabilities and Exposures (CVE) do National Vulnerability Database dos Estados Unidos. Cada CVE é atribuído a um nível de criticidade, de desconhecido e baixo a crítico. Essa análise de risco é realizada pelo Dependency Track em tempos regulares nos bastidores usando o Software Bill of Material (SBOM) relevante como entrada. 

A seção diretamente abaixo do maior gráfico detalha violações de políticas, com políticas sendo configuradas de acordo com o que se considera importante. É possível registrar certas dependências como indesejadas, ou é possível exigir que certas licenças ou até mesmo grupos de licenças sejam incluídos no painel e relatados. Esse mecanismo de feedback é configurável com base em cada política.

A seção superior então representa as vulnerabilidades do portfólio, projetos em risco, componentes vulneráveis e uma pontuação de risco ao longo do tempo.

Existem mais visualizações, gráficos e estatísticas, como o progresso na auditoria, vulnerabilidade por projeto ao longo do tempo e vulnerabilidade por componente ao longo do tempo, entre outros, mas vamos nos concentrar em como o BitBucket pode gerar e enviar o SBOM para o Dependency Track.

BitBucket Prepara o SBOM

A preparação do SBOM acontece no pipeline de CI/CD do BitBucket que é executado após as solicitações de pull serem mescladas na branch principal. Isso garante que os painéis estejam sempre atualizados com o estado das coisas.

Eu usei um pipe do BitBucket que envolve o syft para gerar um SBOM do tipo CycloneDX. Os comandos do syft para as interrogações de código e contêiner são um pouco diferentes.

Identificação de Código

O comando do syft para analisar o código a partir da raiz do seu projeto é o seguinte:

syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .

Este comando gera o SBOM em um arquivo chamado code-cdx-sbom.json e utiliza a rede para obter informações de licença da internet; por exemplo, dos repositórios Maven centrais.

O pipe syft BitBucket da shiftleftcyber (obrigado!) é então configurado no bloco de script do pipeline do BitBucket para envolver este comando syft da seguinte forma:

YAML

 

O README do projeto syft lista uma impressionante variedade de linguagens suportadas, mas eu o utilizei apenas em Java e JavaScript com um projeto em Python na fila.

O que se Esconde em Seus Contêineres?

Para escanear um contêiner do seu registro, executa-se o seguinte comando dentro do escopo de um “docker login”:

syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry

O pipe correspondente do BitBucket é:

YAML

 

O switch all-layers instrui o syft a inspecionar todas as camadas da imagem do contêiner e não apenas o produto final.

BitBucket como o Meio de Depósito

Só resta que o Dependency Track ingira o SBOM. Eu usei o pipe irmã do pipe do BitBucket que gerou o SBOM:

YAML

 

Eu especifiquei três parâmetros de entrada:

  1. URL da instância do Dependency Track
  2. O ID do projeto do Dependency Track para carregar o SBOM
  3. A chave da API para autorizar o envio

O ID do projeto pode ser facilmente encontrado clicando em “Ver detalhes” na visualização do projeto:

Seguido pela cópia do Identificador do Objeto na parte inferior:

A chave da API é encontrada no campo de entrada com o mesmo nome da equipe de Automação, acessível no menu Administração do painel esquerdo:

Conclusão

Incidentes passados ensinaram que a exploração de vulnerabilidades tende a resultar em interrupções de serviço que podem se espalhar para sistemas ou indústrias vizinhas. Isso causa despesas inesperadas e inconvenientes. A recuperação disso desviará desenvolvedores e recursos dos objetivos da equipe.

A licença de um projeto aberto, além disso, pode se tornar comercial e resultar em uma organização sendo atingida com taxas de licenciamento retroativas. Por outro lado, podem ser feitas exigências para tornar de código aberto propriedade intelectual crítica usada para obter a vantagem competitiva devido a condições de licenciamento predatórias.

Portanto, é responsabilidade de cada desenvolvedor implementar e apoiar estratégias ativas para combater esses riscos. Caso o seu código esteja no BitBucket, a abordagem descrita acima pode ajudar seu(s) sistema(s) a se adequarem ao programa. No entanto, a API do Dependency Track não limita o acesso exclusivamente ao BitBucket e deve haver maneiras de enviar o Software Bill of Materials para ele a partir de outras tecnologias de pipeline CI/CD.

Source:
https://dzone.com/articles/on-sboms-bitbucket-and-owasp-dependency-track