Linhas de falha na imagem do contêiner estão sendo expostas

Com quase 16.000 falhas na Califórnia – e 500 delas “ativas” – os cientistas dizem que há mais de 95% de chance de um grande terremoto nos próximos 30 anos. É por isso que, em 2013, São Francisco implementou um programa obrigatório de modernização sísmica, que mais de 90% das estruturas-alvo foram concluídas com sucesso.

Estamos hoje em uma situação semelhante na segurança da cadeia de suprimentos de software, onde grande parte da indústria ficou assustada com a ameaça XZ Utils, que rapidamente se juntou a outras vulnerabilidades como SolarWinds e Log4j na infâmia. As empresas estão a analisar atentamente as suas cadeias de abastecimento e a perguntar-se o que podem fazer para se protegerem contra o “grande problema”.

Vamos dar uma olhada nas questões fundamentais que tornaram a segurança da cadeia de suprimentos de software um domínio tão complicado, alguns dos importantes trabalhos fundamentais que estão sendo feitos nas linhas de falha e algumas dicas sobre como você deve pensar sobre como se preparar melhor para o futuro. sua empresa contra as principais vulnerabilidades de software no futuro

Expondo as linhas de falha na segurança de software

De acordo com o 9º Relatório Anual sobre o Estado da Cadeia de Fornecimento de Software da Sonatype, foram descobertos mais de 245.000 pacotes maliciosos de código aberto no ano passado (o dobro do número de todos os anos anteriores combinados). Eles também descobriram que 1 em cada 8 downloads de pacotes de código aberto incluía riscos conhecidos.

A base da segurança de software apresenta algumas falhas graves que precisam ser resolvidas.

Uma área onde há claramente espaço para melhorias é a proveniência. Ao instalar uma imagem de contêiner, você precisa saber de onde ela veio — mas muitos desenvolvedores ainda dependem do nome da imagem, com base no namespace do repositório e no registro de onde ela veio. Eles confiam em uma imagem porque ela tem um grande número de downloads, ou apareceu primeiro em uma pesquisa, ou porque seu nome indica que ela veio de sua organização ou de outro registro confiável. Mas este tipo de dados do namespace não é totalmente confiável: maus atores podem imitar as convenções de nomenclatura, e o nome não prova nada sobre as origens de uma imagem – muito menos aqueles que podem tê-la adulterado durante o transporte.

Há também um problema separado com a reprodutibilidade. Mesmo se eu tiver um Dockerfile e a fonte usada para criar a imagem, se eu executar uma compilação do Docker novamente, terminarei com uma imagem um pouco diferente. Haverá coisas como carimbos de data e hora diferentes e IDs de construção, o que significa que acabarei com uma imagem que não é idêntica em termos de bits.

E a verificação de segurança é um jogo Whac-A-Mole. Essas são ótimas ferramentas realmente poderosas, mas nos fornecem muitos resultados para a maioria das imagens de contêiner. A maioria das organizações não sabe o que fazer com esse resultado. Se você obtiver 100 vulnerabilidades ou 200 vulnerabilidades, o que você fará com isso? Você não tem tempo para investigar cada um deles. E mesmo se você fizer isso, na próxima semana, haverá mais uma dúzia. É uma situação muito difícil.

Por último, mas não menos importante, avaliar a exposição é incrivelmente difícil. Se uma vulnerabilidade cair amanhã e parecer importante, os CISOs gostariam de poder identificar os contêineres que estão executando na produção e que estão potencialmente expostos à vulnerabilidade. Mas a realidade é que mesmo as organizações que tentam usar listas de materiais de software (SBOMs) estão longe de conseguir identificar todos os seus softwares. As ferramentas existentes geralmente perdem itens e dependências transitivas. (Você pode não estar usando uma biblioteca vulnerável diretamente, mas o banco de dados que está executando em produção pode estar!)

Quando sua cadeia de fornecimento de software está vinculada a uma base com tantas incógnitas, você não apenas traz vulnerabilidades para seu ambiente: você também não consegue nem mesmo verificar o que está executando de uma forma que permita uma correção mais rápida.

Vamos dar uma olhada em duas etapas principais para controlar esse problema.

Assine e verifique o software que você traz

Nos últimos dois anos assistimos a um progresso significativo na adição de assinaturas a imagens de contentores, principalmente devido à ampla adoção do projeto Sigstore. Este progresso aumenta enormemente a capacidade de compreender e provar a proveniência das imagens – de onde vieram, quem as construiu e se foram alteradas inesperadamente de alguma forma.

O Sigstore agora é usado para assinar todas as imagens oficiais do projeto Kubernetes e também está sendo adotado nos ecossistemas de pacotes npm e Homebrew. As assinaturas do Sigstore podem ser armazenadas diretamente em registros de contêiner junto com imagens, para que você não precise executar uma infraestrutura separada para armazenar assinaturas. Sigstore também oferece suporte à assinatura “sem chave” por meio do protocolo OpenID Connect (OIDC), para que você não precise se preocupar em manter as chaves privadas seguras.

Não adianta assinar coisas se você também não verificar as assinaturas. Hoje, a maneira que normalmente é feita no cluster Kubernetes é usar uma ferramenta de gerenciamento de políticas como Kyverno ou Open Policy Agent (OPA).

Elimine o inchaço em suas imagens básicas

A imagem de contêiner típica vem com muito inchaço – normalmente, ferramentas de sistema operacional fornecidas pela distribuição básica do Linux – que não são necessárias para executar o aplicativo. Além de aumentar os custos de armazenamento e transferência, este inchaço representa um risco, pois pode conter vulnerabilidades potencialmente exploráveis.

Por exemplo, observe uma imagem NGINX no Docker Hub (usando Debian por padrão) e execute Snyk, Trivy, Grype ou qualquer outro scanner. Você encontrará cerca de 100 dependências fornecidas com essa única imagem NGINX e herdará as vulnerabilidades correspondentes, independentemente de usar ou não qualquer um desses outros artefatos de software.

Há um custo para essas centenas de dependências e vulnerabilidades que acompanham o inchaço na imagem típica de contêiner. Mesmo que apenas uma pequena porcentagem das vulnerabilidades seja realisticamente explorável, elas prejudicam sua capacidade de raciocinar com seu ambiente.

É possível reduzir drasticamente esse ruído e chegar ao ponto em que seus relatórios encontrem apenas algumas vulnerabilidades com as quais você pode lidar. Basicamente, a resposta é reduzir os componentes de software nas imagens do contêiner ao conjunto mínimo de dependências necessárias e atualizar continuamente esse conjunto.

O que uma melhor base para cadeia de suprimentos compra

No curto prazo, a combinação do uso de assinaturas de software e distros minimalistas e imagens de contêiner proporcionará muito menos exposição: exposição a vulnerabilidades, exposição a dependências transitivas e exposição a software que foi adulterado.

O objetivo de todo esse trabalho é chegar a um ponto em que você saiba — e possa provar — de onde vem todo o seu software e seja capaz de identificar exaustivamente todas as versões de todos os softwares em uso. Sempre haverá vulnerabilidades, mas usando imagens mínimas e reforçadas, você pode minimizar o número e estar em posição de identificar imediatamente todas as ocorrências de software vulnerável quando o próximo “grande problema” ocorrer.

Chainguard Images oferece às equipes de segurança aquele ponto de partida crucial “Zero CVE” para a segurança da cadeia de suprimentos de software – imagens de contêiner com design mínimo, com atestados integrados que descrevem as origens e versões exatas de todos os pacotes e continuamente atualizadas para remediar novas vulnerabilidades.

A postagem Linhas de falha da imagem do contêiner estão sendo expostas apareceu pela primeira vez em The New Stack.