Protegendo seu SBOM no Google Cloud

Nos últimos anos, a segurança da cadeia de suprimentos de software tem sido uma prioridade para governos e empresas. Após o Log4Shell, no fim de 2021, a Estratégia Nacional de Segurança Cibernética do governo Biden passou a dar atenção à segurança da cadeia de suprimentos de código aberto.

Recentemente, a Agência de Segurança Nacional dos EUA (NSA) publicou novas orientações sobre como proteger as cadeias de suprimentos de software de código aberto. O documento traz recomendações para gerenciar software de código aberto (OSS) e manter uma lista de materiais de software (SBOM).

A segurança da cadeia de suprimentos de software está recebendo atenção por um bom motivo. O número de pacotes de software afetados por ataques à cadeia de suprimentos passou de cerca de 700 em 2019 para mais de 185 mil em 2022.

Ao avaliar como seguir as novas orientações da NSA, especialmente em ambientes de nuvem como o Google Cloud, as equipes de desenvolvimento precisam encontrar parceiros que possam apoiá-las nessa jornada e integrar essas práticas recomendadas a um modelo iterativo de DevSecOps.

Conheça as recomendações da NSA

O novo documento de recomendações, intitulado Protegendo a cadeia de suprimentos de software: práticas recomendadas para gerenciar software de código aberto e listas de materiais de software, aborda quatro temas principais de segurança:

1. Gerenciamento de software de código aberto

2. Criação e manutenção de repositórios seguros de código aberto

3. Manutenção de software de código aberto e gerenciamento de crises

4. Criação e validação de SBOMs

Vamos conhecer algumas recomendações do documento voltadas a desenvolvedores.

Gerenciamento de software de código aberto

O documento atribui aos desenvolvedores a maior parte da responsabilidade pelo gerenciamento de software de código aberto. Cabe a eles escolher as melhores opções de OSS, verificar licenças e vulnerabilidades, integrá-las ao ciclo de vida do desenvolvimento e criar um SBOM.

A NSA recomenda várias práticas para usar software de código aberto no processo de desenvolvimento, incluindo:

• Seleção: avaliar corretamente o OSS para escolher as opções mais seguras

• Avaliação de riscos: entender por completo os riscos associados a cada OSS escolhido

• Licenciamento: cumprir as obrigações e restrições estabelecidas pelas licenças

• Controle de exportação: cumprir as regulamentações de exportação aplicáveis

• Manutenção: manter um repositório interno seguro

• Resposta a vulnerabilidades: estabelecer um processo para encontrar e corrigir vulnerabilidades recém-descobertas

• Entrega segura de software: conferir o conteúdo da versão final com uma análise de composição binária antes do lançamento

Criação e manutenção de repositórios seguros de código aberto

A publicação recente da NSA dedica uma seção a recomendações para criar um repositório interno seguro.

As duas recomendações para manter esse repositório são:

• Estabelecer um processo de adoção de OSS adequado ao porte e aos recursos disponíveis na sua organização.

• Realizar avaliações de vulnerabilidade e risco antes e depois da adoção e usar os resultados para decidir quais componentes utilizar ou quais devem ser revertidos ou atualizados para versões mais seguras.

Manutenção de software de código aberto e gerenciamento de crises

Mesmo softwares de código aberto considerados seguros e aprovados anteriormente para um repositório interno ainda podem estar vulneráveis a falhas de dia zero. As organizações também devem pensar em como encontrar e lidar com esses novos riscos no OSS escolhido.

As empresas podem criar um plano de continuidade para encontrar e corrigir novas vulnerabilidades e ameaças em software de código aberto seguindo estas práticas recomendadas:

• Usar informações confiáveis para identificar ameaças emergentes.

• Usar um SBOM para localizar componentes vulneráveis nas bibliotecas.

• Seguir um processo para corrigir a vulnerabilidade, como atualizar para uma versão corrigida ou voltar para uma versão não afetada.

• Preparar um plano de gerenciamento de crises para responder com antecedência a problemas graves de software e fornecer informações oportunas às partes interessadas.

Criação e validação de SBOMs

O documento também destaca a importância dos SBOMs: é preciso criá-los e atualizá-los, além de disponibilizá-los às pessoas e ferramentas certas.

A NSA destaca algumas características de um SBOM eficaz:

• Detalhes sobre componentes, versões, licenças e dependências

• Integração ao pipeline com técnicas de segurança, como análise de composição de software (SCA)

• Ferramentas de extração automatizada para facilitar a descoberta e a atualização de componentes em todo o ciclo de vida do desenvolvimento de software (SDLC)

• Garantia de qualidade e validação para assegurar que os dados do SBOM estejam no formato correto para que os desenvolvedores possam integrá-los a ferramentas e automações

Como usuários do Google Cloud podem seguir essas recomendações com a Snyk

Esses processos podem parecer uma carga extra para as equipes de desenvolvimento, mas não precisam ser. Com o gerenciamento de segurança de código aberto da Snyk, você encontra e corrige vulnerabilidades nos componentes de código aberto que já utiliza, verifica pull requests em busca de componentes inseguros antes de fazer o merge e cria SBOMs enriquecidos. Graças à Snyk Open Source, nossa ferramenta de SCA, 99% dos clientes da Snyk afetados pelo Log4J corrigiram a vulnerabilidade Log4Shell em até três dias. Com a plataforma de segurança da Snyk, desenvolvida para desenvolvedores, você pode seguir as diretrizes federais de segurança com mais facilidade:

• Encontre dependências vulneráveis enquanto programa, diretamente no seu IDE ou CLI.

• Teste seus projetos diretamente no repositório antes do merge e monitore-os diariamente para detectar novas vulnerabilidades.

• Adicione um teste automatizado da Snyk ao pipeline de CI/CD para impedir que novas vulnerabilidades avancem pelo processo de build.

• Teste seu ambiente de produção para verificar se ele está exposto a vulnerabilidades conhecidas.

• Gere SBOMs com informações enriquecidas da Snyk para cada pacote de código aberto, incluindo detalhes de licenças, links externos, informações sobre mantenedores e muito mais.

Além disso, a Snyk trabalha com o Google Cloud para proteger as cadeias de suprimentos de software, integrando-se aos serviços do Google que você usa para criar e executar seus aplicativos, incluindo:

• Google CloudBuild. A Snyk verifica todos os pacotes dos seus projetos e fornece recomendações automatizadas para corrigi-los.

• Google Artifact Registry (GAR). A Snyk verifica seus contêineres em busca de vulnerabilidades e testa suas imagens-base.

• Google Kubernetes Engine (GKE). A Snyk permite importar e verificar cargas de trabalho em execução, identificando vulnerabilidades em imagens e configurações.

Com essas integrações, as equipes que desenvolvem aplicativos modernos em contêineres no Google Cloud podem validar seus SBOMs e proteger a cadeia de suprimentos de software sem sair dos ambientes que já utilizam.

Os clientes também podem usar os mecanismos de faturamento que já têm com o Google para comprar o software da Snyk diretamente no Google Cloud Marketplace.

Saiba como a Snyk ajudou a equipe da Kroger a proteger sua cadeia de suprimentos.