Sobre SBOMs, BitBucket e OWASP Dependency Track

Tutoriais

O museu de arquiteturas antigas e novas com o qual estou envolvido me forçou a investigar maneiras de salvaguardá-las. Por exemplo, uma antiga dependência pode se tornar CVE ou um sólido projeto de código aberto pode se tornar comercial. É nesse contexto que o conceito de Software Bill of Material (SBOM) surgiu para catalogar o ecossistema de licenças e dependências dos sistemas. Este artefato de construção, por sua vez, é analisado para determinar se os componentes constituintes são:

  1. Vulneráveis à exploração, ou
  2. Licenciados sob condições desfavoráveis, como ser demasiado comercial ou predatório.

Este artigo explicará como controlar tais vulnerabilidades usando:

  1. Pipes do BitBucket 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 espreita em seu código e contêineres é uma benção, mas perigoso. No entanto, passar todos os seus componentes por um analisador de dependências pode fornecer um feedback esmagador. É melhor criar um painel e incorporar na cultura da equipe que a quantidade de problemas de dependência deve sempre ser menor hoje do que era ontem.

Wikipedia afirma que: “O Open Worldwide Application Security Project (OWASP) é uma comunidade online que produz artigos, metodologias, documentação, ferramentas e tecnologias disponíveis gratuitamente nas áreas 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 para todos os projetos sendo monitorados. Métricas sobre 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 Vulnerabilidades e Exposições Comuns (CVE) dos Estados Unidos Banco Nacional de Vulnerabilidades. Cada CVE recebe um nível de criticidade que varia de desconhecido e baixo a crítico. Esta análise de risco é realizada pelo Dependency Track em intervalos regulares nos bastidores, utilizando o Software Bill of Material (SBOM) relevante como entrada.

A seção logo 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 pode-se exigir que certas licenças ou até mesmo grupos de licenças sejam monitorados e relatados. Este mecanismo de feedback é configurável com base em cada política.

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

Há mais visualizações, gráficos e estatísticas, como o progresso na auditoria, vulnerabilidades por projeto ao longo do tempo e vulnerabilidades por componente ao longo do tempo, entre outros, mas vamos direcionar nossa atenção a como o BitBucket pode gerar e enviar o SBOM para o Dependency Track.

BitBucket Prepara o SBOM

A preparação do SBOM ocorre no pipeline CI/CD do BitBucket que é executado após os pull requests serem mesclados ao branch principal. Isso garante que os painéis estejam sempre atualizados com o estado das coisas.

Eu usei um pipe do BitBucket que envolve syft para gerar um SBOM em CycloneDX. Os comandos syft para interrogações de código e contêiner diferem ligeiramente.

Sniffing de Código

O comando 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 usa a rede para recuperar informações de licença da internet; por exemplo, dos repositórios centrais do Maven.

O pipe do 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 só o utilizei 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 âmbito 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

Tudo o que resta é que o Dependency Track ingresse o SBOM. Eu usei o pipe irmã pipe 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. A ID do projeto do Dependency Track para carregar o SBOM
  3. A chave da API para autorizar o upload

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

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

A chave da API é encontrada no campo de entrada com nome semelhante da equipe Automação, acessível a partir do menu Administração no 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. Recuperar-se disso desviará desenvolvedores e recursos das metas da equipe.

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

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

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