Skip to main content

4 etapas para lidar com dependências vulneráveis

Escrito por

7 de julho de 2016

0 minutos de leitura

Há algumas semanas, lançamos a integração completa do Snyk com o GitHub. Durante o desenvolvimento, nosso objetivo era facilitar ao máximo a correção de vulnerabilidades conhecidas. Para isso, buscamos identificar as ações mais simples e claras que você precisa realizar. No fim, chegamos a 4 etapas, que se aplicam a todos os ambientes, de npm e Maven a ferramentas de Infraestrutura como Código, como Chef e Puppet.

Neste post, explicamos as etapas e como implementá-las com o Snyk (para npm). Embora os exemplos do Snyk se concentrem em testar aplicações usando o GitHub, você também pode seguir essas etapas com a CLI do Snyk.

As etapas

Independentemente das ferramentas ou do ambiente, estas são as etapas necessárias para lidar com vulnerabilidades conhecidas nas suas dependências:

  1. Identifique as dependências vulneráveis

  2. Corrija as vulnerabilidades

  3. Impeça a inclusão de novos pacotes vulneráveis

  4. Responda de forma rápida e eficiente a vulnerabilidades recém-divulgadas.

As duas primeiras etapas ajudam você a eliminar as vulnerabilidades. Ambas são necessárias: identificar problemas sem corrigi-los não adianta muito, mas também não é possível corrigir problemas que você nem conhece. Facilitar a correção é fundamental, pois é muito fácil ignorar alertas quando não é simples agir sobre eles. Por isso, as ferramentas devem não só permitir a correção, mas torná-la extremamente fácil.

Depois de eliminar as vulnerabilidades, as duas etapas seguintes ajudam você a manter esse estado à medida que o código evolui e novas vulnerabilidades são divulgadas. Tanto a sua aplicação quanto o conhecimento público sobre vulnerabilidades estão em constante evolução, por isso é preciso adotar uma solução contínua para esse problema.

1) Identifique vulnerabilidades nos seus repositórios

A primeira etapa é testar todos os seus projetos em busca de vulnerabilidades conhecidas.

No Snyk, oferecemos uma visão única para testar todos os seus repositórios. Basta clicar em “Testar meus repositórios” nesta página do blog ou na nossa página de testes para acessar uma página com as vulnerabilidades encontradas em todos os seus repositórios que usam npm.

Para cada repositório que usa npm, o Snyk mapeia as dependências e verifica se há correspondências no nosso banco de dados de vulnerabilidades de código aberto. As vulnerabilidades são classificadas como de gravidade alta, média ou baixa para facilitar a priorização. Você também pode acessar relatórios de teste detalhados.

Painel de repositórios do GitHub com uma lista de repositórios, contagens de vulnerabilidades, relatórios de testes e botões Monitor

2) Corrija as vulnerabilidades

Nos projetos com dependências vulneráveis, a próxima etapa é, naturalmente, eliminá-las. Identificar problemas ajuda a avaliar o risco atual, mas o que você realmente quer é corrigi-los. Investir em ferramentas que simplificam a correção é essencial. Caso contrário, você logo se acostumará com esses erros e passará a ignorá-los. O mesmo acontece com linting, testes de desempenho e outros testes de qualidade.

No Snyk, nosso principal objetivo é facilitar a correção com um simples botão “Corrigir”, que gera automaticamente as alterações de código necessárias para eliminar as vulnerabilidades. Para isso, monitore um repositório na tela mencionada acima e acesse a página do projeto no Snyk clicando em “Ver projeto”. Lá, no canto superior direito, você encontrará o botão “Corrigir vulnerabilidades”. Ele gera um pull request com as alterações mínimas necessárias para corrigir o problema e permitir que você volte a escrever código.

Para corrigir os problemas, o Snyk primeiro procura a atualização direta mínima que você pode aplicar para obter uma versão não vulnerável do pacote em questão. Se não houver uma atualização desse tipo, o Snyk tentará corrigir a vulnerabilidade usando patches de código aberto do nosso banco de dados de vulnerabilidades.

Pull request do GitHub do bot do Snyk propondo correções para oito caminhos de dependências npm vulneráveis

3) Impeça a inclusão de pacotes vulneráveis

Assim como a qualidade, a segurança é um processo contínuo. Depois de eliminar as vulnerabilidades, você precisa garantir que novas dependências vulneráveis não sejam incluídas à medida que o projeto evolui. E, como acontece com qualquer questão de qualidade, quanto mais cedo você identificar esse tipo de falha, mais fácil e barato será corrigi-la.

Identificar problemas cedo significa incluí-los no fluxo de testes contínuos, normalmente por meio de testes executados no CI ou como parte de um pull request do GitHub.

Quando você integra um projeto do GitHub ao Snyk (clicando no botão “Monitorar” mencionado acima), o Snyk também adiciona testes às etapas de verificação dos seus pull requests. Assim, sempre que um desenvolvedor cria um pull request, o Snyk testa as alterações para verificar se elas tornam a aplicação vulnerável. Se isso acontecer, o teste falha claramente e mostra detalhes sobre como resolver o problema.

As verificações da solicitação de pull request mostram que todas falharam devido a um caminho vulnerável, enquanto a ramificação não apresenta conflitos com a ramificação base.

Adicionar testes aos pull requests dá bastante visibilidade aos pacotes vulneráveis sem atrapalhar o fluxo de trabalho (você pode configurar o limite). Isso ajuda os membros da equipe a identificar falhas acidentais logo no início e permite que projetos de código aberto garantam que as contribuições não incluam problemas de segurança. Em geral, os testes de pull request não bloqueiam o processo, então você ainda pode optar por integrar uma alteração com vulnerabilidades se estiver com pressa e tiver avaliado as consequências.

4) Responda a novas vulnerabilidades

É nesta última etapa que a segurança se diferencia um pouco de outras questões de qualidade. Na maioria dos casos, você só cria novos bugs ao modificar o código. Já as vulnerabilidades conhecidas podem surgir mesmo que o código não tenha mudado.

Novas vulnerabilidades são divulgadas regularmente, revelando falhas de segurança até então desconhecidas na sua aplicação. Essas falhas já existiam na aplicação e nas dependências, mas, uma vez divulgadas, têm muito mais chances de ser exploradas por invasores. Para manter a segurança, você precisa de uma configuração que permita descobrir essas novas divulgações com rapidez e eficiência e corrigi-las antes que os invasores possam explorá-las.

No Snyk, também buscamos simplificar essa resposta. Ao usar a integração com o GitHub, o Snyk registra as dependências usadas pela sua aplicação e acompanha as alterações no seu package.json ao longo do tempo. Quando uma nova vulnerabilidade é divulgada e adicionada ao nosso banco de dados, o Snyk verifica se ela afeta o seu projeto e, em caso positivo, envia um e-mail para todas as pessoas da sua organização no Snyk. Além disso, enviamos automaticamente um pull request de correção, poupando mais uma etapa.

E-mail de alerta de vulnerabilidade do Snyk mostrando dois projetos com problemas de injeção de comandos e negação de serviço por expressão regular, além de opções de correção.

Proteja todos os seus projetos

Ao executar um teste, é tentador olhar apenas para os projetos que têm dependências vulneráveis no momento. De fato, esses são os únicos projetos que precisam da segunda etapa: a correção.

No entanto, lembre-se de que um projeto não estar vulnerável hoje não significa que não estará amanhã. Monitore todos os seus projetos para poder impedir e responder adequadamente quando surgirem novas dependências vulneráveis.

Resumo

Pronto. Com estas 4 etapas, você estará bem preparado para lidar com dependências vulneráveis. Para dependências npm, o Snyk facilita muito a execução de todas elas. Em outras plataformas, você pode escolher as ferramentas que preferir (se houver), mas não deixe de cumprir as quatro etapas.

Comece agora: basta clicar em “Testar meus repositórios” e dar o primeiro passo!

Comece a jogar Capture the Flag

Aprenda a resolver desafios de Capture the Flag assistindo à gravação sob demanda do nosso workshop virtual introdutório.

Leia mais

Blog

Modelos de ponta encontraram as vulnerabilidades. Só o atacante encontrou as cadeias.

A análise estática encontrou as falhas, mas só os testes de ataque em aplicações ativas provaram como elas poderiam ser encadeadas para causar invasões. Uma comparação entre Evo COS, Claude Security e Claude Code Security.

feature insights context
Blog

Os ataques autônomos já chegaram. A defesa precisa acompanhar o ritmo.

Os atacantes autônomos estão reduzindo o tempo disponível para a defesa. Saiba como a descoberta, a correção, a validação e a prevenção contínuas ajudam as equipes de segurança a acompanhar esse ritmo.

Blog

Por que agentes de programação com IA continuam criando falhas de controle de acesso

Agentes de programação com IA podem gerar uma lógica de autorização que compila e passa pela revisão, mas permite que um tenant acesse os dados de outro. Saiba por que é difícil detectar falhas de controle de acesso e como evitá-las.