Lições das vulnerabilidades do OpenSSL — parte 2: como encontrar e corrigir vulnerabilidades na cadeia de suprimentos

Esta série sobre a cadeia de suprimentos reúne lições aprendidas com o OpenSSL e o que você precisa considerar para fortalecer a segurança da sua cadeia de suprimentos. Embora esta série tenha foco no OpenSSL e em bibliotecas relacionadas, também vamos abordar vulnerabilidades de modo geral. Na primeira parte, explicamos tudo o que você precisa saber sobre onde procurar bibliotecas vulneráveis. Vamos à parte 2 e falar sobre como encontrar — e, mais importante, corrigir — vulnerabilidades na sua cadeia de suprimentos.

Como encontrar vulnerabilidades na cadeia de suprimentos

Os métodos usados para procurar bibliotecas ou pacotes problemáticos dependem das áreas que você está inspecionando. Hosts e máquinas virtuais usam mecanismos diferentes dos contêineres e do código. Hoje, vamos nos concentrar no lado do software: contêineres e código.

Ter uma visão centralizada de todo o seu ecossistema ajuda a responder à pergunta: “onde fomos afetados?”. Essa visão oferece visibilidade sobre todo o seu portfólio de aplicações. Ela deve incluir todas as suas aplicações e os componentes que as compõem: o código, os contêineres em que você as implanta e todas as dependências de código aberto. Essa “visão centralizada” armazenaria efetivamente uma lista de materiais de software (SBOM) para cada um dos seus componentes de software, criando um índice de todas as aplicações e todos os contêineres que você executa ou armazena.

Código-fonte e bibliotecas de código aberto

Uma visão centralizada é ótima, mas, como dizem, depois do ocorrido tudo fica mais claro. É perfeitamente possível que o anúncio sobre o OpenSSL tenha chegado antes de você conseguir criar um inventário (ou até antes de saber que era possível centralizá-lo). Vamos ver o que considerar e onde procurar se você ainda não tem essa centralização. As aplicações modernas usam componentes e bibliotecas de código aberto — 80% ou mais do código nas suas aplicações pode estar fora do seu controle direto. Por isso, determinar onde essas bibliotecas e esses pacotes são usados é uma parte importante do problema.

Encontrar as bibliotecas importadas pelas suas aplicações e projetos personalizados é mais complicado do que procurá-las em hosts físicos. Você pode fazer uma busca por “openssl” em todas as ocorrências de requirements.txt nos diretórios raiz dos seus projetos, mas provavelmente não encontrará muita coisa. Além de ser improvável que um único host tenha todo o código-fonte de todos os seus projetos, é totalmente possível (ou até provável) que, se suas aplicações dependem do OpenSSL, essa dependência seja transitiva, como vimos anteriormente.

O ideal é ter uma lista de materiais de software (SBOM) para cada uma das suas aplicações, o que permitiria determinar rapidamente os riscos, mas esse recurso ainda não é amplamente adotado. Várias ferramentas permitem gerar uma SBOM para suas aplicações. Por exemplo, a Snyk oferece uma API e o comando de CLI snyk sbom, que gera uma lista de materiais de software nos formatos SPDX ou CycloneDX. Mas verificar manualmente cada repositório de código-fonte não é prático. Em vez de analisar o código-fonte na sua máquina local, muitas soluções permitem fazer a análise onde ele está: nos repositórios. Com a Snyk, por exemplo, você pode monitorar repositórios com facilidade, vinculando suas contas e selecionando quais repositórios quer adicionar.

Quando os repositórios são vinculados dessa forma, eles podem ser analisados regularmente. Isso ajuda a encontrar vulnerabilidades recém-descobertas que já estavam ocultas nas dependências dos seus projetos (como as vulnerabilidades do OpenSSL, que desconhecíamos até ontem), além de vulnerabilidades que possam ter sido introduzidas por desenvolvedores.

Imagens de contêiner

As imagens de contêiner também fazem parte da sua cadeia de suprimentos de software. Além de servirem como base para suas cargas de trabalho, elas também incluem elementos que não fazem parte do seu código nem das dependências dele. Há várias ferramentas para analisar a composição, os pacotes e as vulnerabilidades de imagens de contêiner, incluindo Snyk Container, que oferece planos pagos e gratuitos, integrações com IDEs, uma interface de linha de comando e suporte à automação nos seus pipelines de CI/CD. Também há vários projetos de código aberto, como Syft, Grype, trivy e uma ferramenta não oficial chamada “docker index”, que podem verificar vulnerabilidades. A ferramenta docker-index pode ser usada na linha de comando para encontrar CVEs. Embora a ferramenta ainda não tenha assinatura, você pode executá-la em um contêiner (bem metalinguístico). Veja como exemplo a imagem pública apache/tika:2.6.0.1, que, no momento em que este texto foi escrito, ainda tinha uma versão vulnerável do OpenSSL. Expandi os argumentos para facilitar a leitura; fique à vontade para abreviar -it.

1docker run \
2    --interactive \
3    --tty \
4    --rm \
5    ghcr.io/docker/docker-index:main \
6    cve -i \
7    apache/tika:2.6.0.1 CVE-0000

O comando docker-index identifica as vulnerabilidades 3602 e 3768 do OpenSSL, mas não encontra mais nada:

1INFO Requesting image apache/tika:2.6.0.1
2INFO Copied image
3INFO Indexed 333 packages
4INFO Detected 2 vulnerabilities
5
6Detected CVE-2022-3602  HIGH
7https://dso.docker.com/cve/CVE-2022-3602
8
9pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.6?os_distro=jammy&os_name=ubuntu&os_version=22.04
10ADD file:ba96f963bbfd429a0839c40603fdd7829eaca58f20adfa0d15e6beae8244bc08 in /
110: sha256:301a8b74f71f85f3a31e9c7e7fedd5b001ead5bcf895bc2911c1d260e06bd987
12
13Detected CVE-2022-3786  HIGH
14https://dso.docker.com/cve/CVE-2022-3786
15
16pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.6?os_distro=jammy&os_name=ubuntu&os_version=22.04
17ADD file:ba96f963bbfd429a0839c40603fdd7829eaca58f20adfa0d15e6beae8244bc08 in /
180: sha256:301a8b74f71f85f3a31e9c7e7fedd5b001ead5bcf895bc2911c1d260e06bd987

A maioria dos scanners de contêineres e componentes de código aberto exibe uma lista de vulnerabilidades; alguns também indicam uma versão com correção. Um exemplo é a saída do Trivy, que identifica uma longa lista de vulnerabilidades que o docker-index não detecta (veja abaixo uma amostra):

A ferramenta identificou as duas novas vulnerabilidades HIGH do OpenSSL, junto com uma visão geral e uma versão com correção, mas não ajuda muito a criar um contêiner mais seguro:

┌────────────────┬────────────────┬──────────┬───────────────────┬────────────────────┐
│ libssl3        │ CVE-2022-3602  │ HIGH     │ 3.0.2-0ubuntu1.6  │ 3.0.2-0ubuntu1.7   │
│                │                │          │                   │                    │
│                ├────────────────┤          │                   │                    │
│                │ CVE-2022-3786  │          │                   │                    │
│                │                │          │                   │                    │
└────────────────┴────────────────┴──────────┴───────────────────┴────────────────────┘

Assim como no caso do código aberto, discutido na primeira publicação, analisar uma ou duas imagens de contêiner pode ser viável, mas analisar centenas ou milhares delas não é realista em um fluxo de desenvolvimento típico.

Assim como acontece com dependências transitivas e código aberto, provavelmente você não executa imagens como Ubuntu ou tika diretamente, mas usa imagens derivadas delas — herdando todas as vulnerabilidades incluídas, além de outras que você adicionou por meio de instruções do usuário. Isso torna a busca mais complexa.

Onde fomos afetados

Como vimos, várias ferramentas podem ajudar a encontrar bibliotecas vulneráveis nas imagens de contêiner e nas dependências de código aberto. Ferramentas que fazem análises pontuais no ambiente de desenvolvimento local podem funcionar em projetos com poucos desenvolvedores, mas se tornam difíceis de administrar à medida que a equipe e o número de projetos crescem. Por outro lado, ferramentas que se integram às fontes oficiais do seu portfólio de aplicações — repositórios de código-fonte e registros de imagens de contêiner — podem acompanhar seu inventário e fornecer informações atualizadas sobre possíveis impactos. Por exemplo, ao filtrar por outra vulnerabilidade de grande repercussão, o Snyk Reporting mostra uma visão centralizada dos nossos projetos afetados pelo Log4Shell. Seja pelo método de força bruta ou por uma visão centralizada e organizada, pelo menos conseguimos responder à pergunta: “onde fomos afetados?”.

Não basta apenas encontrar as ocorrências

Vimos que mais de 80% do código na sua cadeia de suprimentos de software pode vir de fontes externas, mas encontrar as ocorrências é apenas parte da resposta que seu chefe vai pedir. Agora que sabemos onde estamos vulneráveis e temos uma lista do que corrigir, ainda falta responder à outra metade da pergunta: “como vamos corrigir isso?”. Em sistemas operacionais ou aplicações, “corrigir” geralmente significa aguardar e aplicar patches ou atualizações do fornecedor.

No caso de vulnerabilidades em bibliotecas de código aberto e contêineres, você também provavelmente terá de aguardar atualizações dos responsáveis pelos projetos, mas há outras etapas envolvidas. É provável que os responsáveis também estejam esperando uma correção de alguém mais acima na cadeia. Veja como exemplo o Ubuntu 22.04, versão de suporte de longo prazo (LTS) da popular distribuição Linux. Quando as vulnerabilidades do OpenSSL foram divulgadas, o Ubuntu 22.04 incluía o OpenSSL 3.0.2 (mais especificamente, 3.0.2-0ubuntu1.6), uma das versões vulneráveis. No caso do Ubuntu, em vez de passar para a versão 3.0.7, a versão 3.0.2 foi corrigida para incluir as correções das vulnerabilidades. Mas não parou por aí. Depois de corrigir a biblioteca, ainda era preciso lançar a atualização para o próprio Ubuntu 22.04 e criar imagens de contêiner atualizadas.

Se você usa imagens do Ubuntu diretamente (por exemplo, se o seu Dockerfile começa com FROM ubuntu:22.04), pode recriar suas imagens para incluir a correção assim que as imagens afetadas forem publicadas (e esperamos que você teste suas imagens, pois até as menores alterações precisam ser verificadas). Mas, se você usa imagens derivadas dessa nova versão do Jammy Jellyfish, talvez precise esperar mais algumas etapas até que as correções cheguem à imagem que você aguarda.

Ao contrário das opções de análise de contêineres de código aberto da seção anterior, Snyk Container ajuda você a navegar pelas árvores de dependências das imagens para encontrar imagens-base melhores e criar imagens mais seguras. A Snyk mantém e atualiza regularmente um índice de versões de imagens oficiais populares no Docker Hub, permitindo identificar quando imagens que usam tags móveis (atualizadas no próprio local, em vez de receber uma nova versão menor) estão desatualizadas. Neste caso, Snyk Container detecta que ubuntu:22.04 foi atualizado desde a criação da imagem analisada e indica que ela deve ser recriada para incluir a alteração:

1Your base image is out of date
21) Pull the latest version of your base image by running 'docker pull ubuntu:22.04'
32) Rebuild your local image

Snyk Container também pode apresentar uma lista de opções melhores de imagens, tanto para imagens oficiais do Docker quanto para imagens-base personalizadas. A ferramenta também permite gerar pull requests com um clique, para que você possa atualizar rapidamente e corrigir várias vulnerabilidades de uma só vez.

Com a Snyk, também é simples corrigir vulnerabilidades em dependências de código aberto. Além de informações sobre bibliotecas vulneráveis, você encontra detalhes sobre as versões corrigidas, como no exemplo abaixo:

A Snyk também oferece ferramentas para corrigir essas vulnerabilidades por meio de “PRs de correção”, permitindo resolver várias delas com um clique.

Se corrigir uma vulnerabilidade de cada vez não funciona na escala da sua operação, a resposta para “como vamos corrigir isso?” é simples: “Vamos corrigir com a Snyk”.

Prepare-se para a próxima vulnerabilidade na cadeia de suprimentos com a Snyk

Aproveite a redução da gravidade das vulnerabilidades do OpenSSL para testar seus processos de tratamento de vulnerabilidades. Crie planos de ação e listas de verificação para lidar com a próxima vulnerabilidade, incluindo quem envolver, como avaliar o impacto, qual inventário precisa ser avaliado e como comunicar as descobertas e os impactos internamente (e externamente, se aplicável). Talvez o mais importante seja garantir que todos saibam onde encontrar os planos de ação. Antes da próxima vulnerabilidade crítica, comece a usar ferramentas para acompanhar seu código-fonte e o inventário de contêineres, a fim de se preparar melhor.

Com Snyk Container e Snyk Open Source, você pode proteger sua cadeia de suprimentos de software e monitorar proativamente seus contêineres e projetos de código aberto. Em vez de correr para encontrar imagens de contêiner ou pacotes de código aberto vulneráveis, você pode saber se foi afetado antes mesmo de as vulnerabilidades serem divulgadas e ter a confiança de que terá as respostas quando clicar em “enviar mensagem” no Slack para avisar seu chefe.

Saiba mais sobre ferramentas de segurança da cadeia de suprimentos de software e descubra como a Snyk pode ajudar você a fortalecer a segurança da sua cadeia de suprimentos de software. Comece agora gratuitamente.