Novo livro da O’Reilly: Como proteger bibliotecas de código aberto, por Guy Podjarny

A Snyk se uniu à O’Reilly para oferecer um novo livro, Como proteger bibliotecas de código aberto: gerenciamento de vulnerabilidades em pacotes de código aberto. No livro, Guy Podjarny, CEO e fundador da Snyk, aborda diversos temas para ajudar você a lidar com os riscos das bibliotecas de código aberto vulneráveis usadas atualmente pelos seus aplicativos.

As dependências vulneráveis são a parte dos seus aplicativos com maior probabilidade de ser explorada por invasores. O livro aborda algumas das principais práticas recomendadas e ferramentas para proteger seus aplicativos em grande escala.

Baixe seu livro gratuito agora!

Guy começa explicando o que é uma vulnerabilidade conhecida e como ela é registrada publicamente, por exemplo, nos bancos de dados CVE e NVD. Ele também explica por que confiar apenas nessas fontes não é suficiente. Além disso, Guy aborda a divulgação responsável e as medidas que você pode tomar em relação às vulnerabilidades que descobrir.

No capítulo 2, Guy entra no cerne do livro e mostra como as vulnerabilidades podem ter vários caminhos dentro do seu aplicativo. Isso acontece quando uma biblioteca vulnerável aparece várias vezes na árvore de dependências.

Imagine um aplicativo que usa dois pacotes, A e B, sendo que A também usa B (na mesma versão), resultando na seguinte árvore de dependências:

Agora, vamos supor que B@1.0.0 tenha uma vulnerabilidade conhecida de negação de serviço (DoS). Ao testar o aplicativo, quantas vulnerabilidades devemos reportar? Por um lado, o aplicativo tem apenas uma vulnerabilidade conhecida: DoS em B@1.0.0. Por outro, há duas instâncias dessa vulnerabilidade. O que devemos reportar: uma ou duas?

Outro tema importante é quando testar. O livro analisa os benefícios de testar tanto no nível do código-fonte quanto nos aplicativos compilados. No entanto, testar o código-fonte é uma aproximação, enquanto testar um aplicativo compilado é mais preciso. A melhor solução é usar as duas abordagens!

Para combinar as duas abordagens, algumas ferramentas testam _aplicativos_compilados, mas também procuram arquivos de manifesto de pacotes, criam uma árvore lógica e tentam encaixar nela as bibliotecas encontradas. Assim, você tem a cobertura dos testes do aplicativo compilado e, na medida do possível, a profundidade de análise proporcionada pelo código-fonte.

Como alternativa, você pode usar as duas abordagens em diferentes etapas do desenvolvimento. Por exemplo, pode usar a análise do código-fonte no fluxo de trabalho do GitHub/GitLab/BitBucket e testar o aplicativo compilado no processo de build ou como etapa de aprovação da implantação. Na maioria dos casos, as duas abordagens apresentam os mesmos resultados e funcionam de forma consistente. Quando isso não acontece, os testes do aplicativo compilado garantem que você não implante uma versão vulnerável. 

O capítulo aborda como encontrar vulnerabilidades conhecidas no seu SCM, na linha de comando, em registros de contêineres e no navegador. Mas essa é apenas metade da história. A parte mais interessante é o que fazer com os dados encontrados. Guy explica como atualizar dependências diretas e indiretas, além de aplicar patches quando não há caminhos de atualização disponíveis. No entanto, em algumas linguagens, ainda podem ocorrer conflitos:

Muitas linguagens, como Ruby e Python, exigem que as dependências sejam globais, e clientes como o bundler do Ruby e o pip do Python determinam quais versões de bibliotecas podem coexistir. Por isso, atualizar uma biblioteca pode gerar conflito com outra. Embora os desenvolvedores saibam lidar bem com esses conflitos, às vezes simplesmente não é possível resolvê-los.

Além de abordar as vulnerabilidades de aplicativos, o livro também mostra como corrigir vulnerabilidades nas imagens de contêineres. Guy explica que, ao contrário das vulnerabilidades de aplicativos, as vulnerabilidades do sistema operacional raramente têm versões corrigidas para as quais basta atualizar. Por isso, precisamos dar mais atenção a boas práticas de triagem. 

O capítulo 4 aborda um tema essencial no ritmo acelerado do desenvolvimento moderno: incluir testes de segurança nos pipelines existentes para garantir que você teste as mudanças de desenvolvimento à medida que elas seguem para produção. Esse processo costuma ser chamado de pipeline DevSecOps.

Baixe o livro completo!

Prepare-se para corrigir vulnerabilidades rapidamente

Uma parte importante de todo esse processo é a forma como suas equipes reagem à descoberta de novas vulnerabilidades, seja por causa de uma mudança no código ou da divulgação de uma nova vulnerabilidade. Quem você deve contatar quando receber uma nova notificação de segurança? A equipe de segurança? Os desenvolvedores? A gerência? Com que rapidez você deve reagir a diferentes tipos e níveis de gravidade de problemas? Você deve interromper o build quando surgirem novas vulnerabilidades? Sua cadeia de dependências está vulnerável a atualizações? Baixe o livro agora para receber orientações e conselhos práticos sobre como começar a proteger suas bibliotecas de código aberto.