Audite suas dependências do NPM, elas representam 86% dos erros de segurança

Um estudo recente conduzido por Snyk sobre o estado da segurança de código aberto mostrou resultados alarmantes - para pacotes NPM, 86% das vulnerabilidades de segurança residem em dependências secundárias sobre as quais você geralmente tem pouco controle.

O que são dependências secundárias?

Quando você instala algo do NPM, não está apenas instalando um pacote, mas também instalando esse pacote, além de qualquer uma das dependências necessárias. Você pode visualizar esta árvore de dependência para seus próprios projetos com npm ls --depth = 10. Mesmo um projeto básico com dois pacotes instalados na verdade contém quatro níveis de dependências, totalizando 10 pacotes reais:

O problema, então, é óbvio. Você está obtendo código de muitos mais pacotes do que o seu package. json sugeriria. E cada um desses pacotes é um bug de segurança em potencial.

Segundo o relatório de Snyk, é exatamente isso que acontece em ambientes de código aberto como NPM e Ruby Gems. O problema é desenfreado, e a maioria dos erros vem de pacotes indiretos que você não instalou manualmente.

O lado bom: esse problema não é tão ruim quanto parece. O NPM possui uma ferramenta interna de auditoria que captura a maioria das desagradáveis ​​e pede para você atualizar. Devido à prevalência de auditoria, esses bugs de segurança estão recebendo mais atenção e são corrigidos quando ocorrem, com atualizações enviadas rapidamente aos usuários afetados.

A maioria dos bugs encontrados por Snyk foram ataques XSS em potencial e, embora isso não seja ótimo, o impacto no mundo real é bastante baixo. Os principais bugs impactantes se resumiram a algumas dúzias de ataques de protótipos de poluição - potencial execução de código arbitrário - bem como alguns pacotes mal-intencionados ou hackeados projetados especificamente para tentar entrar furtivamente no pacote desavisado. json. / p>

O problema também está melhorando ou, pelo menos, recebendo mais atenção. O número de bugs relatados no NPM caiu 20% em relação ao ano passado, e a mesma tendência se aplicou a outros ecossistemas de gerenciadores de pacotes.

O principal argumento de tudo isso: você deve pensar sobre a origem do seu código. Com o surgimento do software FOSS, é fácil ficar preso no inferno das dependências com o código que você não planejava adicionar.

A solução: auditoria

É provável que haja erros em partes aleatórias do código-fonte aberto, e embora você não consiga consertar alguns dos pequenos sem desenvolver tudo internamente, é possível capturar alguns dos mais desagradáveis ​​com auditorias regulares.

O problema não é particularmente novo, e o npm possui uma ferramenta integrada para essa auditoria do npm. Você definitivamente já viu isso antes, porque é executado automaticamente sempre que você instala:

A auditoria interna do NPM, na maioria das vezes, verifica apenas atualizações dos pacotes que corrigem certos bugs; portanto, sempre há uma atualização que você pode fazer (embora seja potencialmente interrompida) que pode solucionar o problema. Existem outros scanners de segurança, como o próprio Snyk, que executam um serviço para verificar projetos do GitHub e mantêm um banco de dados acessível ao público de bugs conhecidos que você pode verificar.

Via: How to Geek