78% das vulnerabilidades estão em dependências indiretas, o que torna a correção complexa

Boas-vindas ao relatório anual da Snyk sobre o estado da segurança de código aberto de 2019. Este relatório está dividido em várias publicações:

• O número de pacotes no Maven Central dobra; um quarto de milhão de novos pacotes indexados no npm

• Aumento de 88% nas vulnerabilidades em bibliotecas de aplicações em dois anos

• 81% acreditam que os desenvolvedores devem ser responsáveis pela segurança, mas não estão bem preparados

• Quem mantém projetos de código aberto quer garantir a segurança, mas 70% não têm as habilidades necessárias

• As dez imagens Docker mais populares contêm pelo menos 30 vulnerabilidades cada

• Vulnerabilidades ReDoS no npm aumentam 143%, e os casos de XSS continuam crescendo

• 78% das vulnerabilidades estão em dependências indiretas, o que torna a correção complexa

Ou baixe nosso simpático relatório em PDF, feito à mão, com todas essas informações e muito mais em um só lugar.

Baixe o Relatório sobre o estado da segurança de código aberto de 2019

Dependências indiretas

É difícil imaginar como era escrever software sem nenhuma dependência de código aberto. Gerenciar as dependências de um projeto é uma tarefa importante que exige o cuidado necessário para acompanhar corretamente as bibliotecas das quais você depende. Afinal, a aplicação que você implanta reúne seu código e suas dependências.

A maioria das dependências no npm, no Maven e no Ruby é indireta, solicitada pelas poucas bibliotecas definidas explicitamente. As vulnerabilidades em dependências indiretas representam 78% do total de vulnerabilidades.

A Snyk analisou mais de um milhão de projetos em snapshots e descobriu que as vulnerabilidades em dependências indiretas representam 78% do total. Isso reforça a necessidade crucial de ter uma visão clara da árvore de dependências e de identificar com precisão as particularidades de um caminho vulnerável para corrigir essas vulnerabilidades.

É claro que encontrar vulnerabilidades em uma dependência é apenas o primeiro passo. Identificar com precisão todos os caminhos na árvore de dependências pelos quais é possível chegar à dependência vulnerável é uma questão mais complexa.

Além disso, sugerir as etapas necessárias para eliminar a vulnerabilidade e, ao mesmo tempo, preservar a compatibilidade entre as dependências é um desafio ainda maior e muito mais interessante.

Riscos e impactos

Apenas um em cada três desenvolvedores consegue corrigir uma vulnerabilidade de gravidade alta ou crítica em um dia ou menos

Para a maioria, não deve ser surpresa que, no relatório State of the Octoverse deste ano, do GitHub, segurança seja a categoria mais popular de aplicativos de integração de projetos, com mais de uma integração para desenvolvedores. Veja uma citação da Gartner, empresa de análise do setor, em um relatório recente sobre segurança de aplicações que destaca a importância de as organizações testarem a segurança o quanto antes no ciclo de vida das aplicações.

Quase metade (43%) das pessoas entrevistadas tem pelo menos 20 dependências diretas, o que reforça a necessidade de monitorar vulnerabilidades de código aberto introduzidas por essas bibliotecas

Quanto mais usamos software de código aberto, mais riscos acumulamos, pois incorporamos código de terceiros que pode conter vulnerabilidades agora ou no futuro. Além disso, o risco não se resume à segurança do código: também envolve a conformidade das licenças do código adotado e a possibilidade de esse código violar a própria licença.

Tome uma atitude

A composição de aplicações é complexa. Quem mantém sistemas operacionais e desenvolve software pode tomar medidas para melhorar a segurança dos projetos que possui e para os quais contribui.

Quem mantém projetos de código aberto

Se você mantém um projeto de código aberto, deve oferecer versões seguras do seu código e definir uma estratégia de comunicação com quem o utiliza. Isso pode beneficiar outros projetos e aplicações e, provavelmente, também os seus.

• Sempre que possível, faça revisões seguras de código com seus colegas e siga as práticas recomendadas de codificação segura. Inclua considerações de segurança na lista de verificação da revisão de código e oriente quem faz a revisão para que saiba o que procurar.

• Faça auditorias regulares do seu código em busca de vulnerabilidades, por exemplo, com análise estática e dinâmica, que pode ser automatizada no fluxo de desenvolvimento para facilitar a identificação de vulnerabilidades antes que se tornem públicas.

• Defina claramente um processo simples para comunicar divulgações responsáveis, usando sua própria política ou encaminhando os relatos a um programa existente. Para demonstrar seu compromisso com a segurança, considere adotar uma política SECURITY.MD e um selo que indique o nível de segurança do projeto.

• Implemente uma estratégia de segurança integrada desde o início do desenvolvimento (shift left) para que sua equipe tenha visibilidade dos problemas de segurança durante o desenvolvimento, na CI e até mesmo na criação de pull requests, reduzindo ao máximo a chance de código vulnerável entrar nos seus projetos.

Desenvolvedores de código aberto

Ao usar componentes de código aberto, é sua responsabilidade entender completamente as dependências diretas e indiretas dos seus projetos, incluindo as possíveis falhas de segurança nessa árvore de dependências. Considere adotar as seguintes diretrizes de segurança:

• Faça auditorias regulares do seu código com uma ferramenta que detecte automaticamente vulnerabilidades nas dependências de terceiros, ofereça recomendações de correção à sua equipe e monitore as dependências do projeto mesmo após a implantação.

• Siga as políticas de divulgação responsável ao relatar uma vulnerabilidade de segurança, para não colocar os usuários em risco. Se não souber como fazer isso, considere comunicar a vulnerabilidade a uma empresa de segurança que possa orientar você durante o processo, como o programa de divulgação responsável da Snyk.

• Inscreva-se nos canais de comunicação de segurança das suas dependências de código aberto, caso existam, para ficar sabendo de possíveis vulnerabilidades assim que forem divulgadas.

Continue lendo nossas publicações com as principais conclusões:

• O número de pacotes no Maven Central dobra; um quarto de milhão de novos pacotes indexados no npm

• Aumento de 88% nas vulnerabilidades em bibliotecas de aplicações em dois anos

• 81% acreditam que os desenvolvedores devem ser responsáveis pela segurança, mas não estão bem preparados

• Quem mantém projetos de código aberto quer garantir a segurança, mas 70% não têm as habilidades necessárias

• As dez imagens Docker mais populares contêm pelo menos 30 vulnerabilidades cada

• Vulnerabilidades ReDoS no npm aumentam 143%, e os casos de XSS continuam crescendo

• 78% das vulnerabilidades estão em dependências indiretas, o que torna a correção complexa