O que está escondido no seu código?

Mesmo projetos simples tendem a crescer rapidamente e essa tendência é amplificada pela facilidade de incorporar pedaços de código ou bibliotecas de nós existentes.

Ainda é um pouco gerenciável quando você é o único que escreve esse código, mas fica mais difícil quando o código é escrito por vários desenvolvedores e equipes, como normalmente acontece.

Mesmo o líder da equipe, responsável por aprovar todas as solicitações pull, não consegue conhecer cada linha de código, cada função e cada variável.

Uma questão de confiança

Esse é um dos motivos da pequena alteração de código que ocorreu no aplicativo Orion no final de 2020, no caso mais tarde conhecido como Solar Winds, passou despercebido por tanto tempo. Toda a mudança envolveu apenas algumas dezenas de linhas de código, e elas foram muito bem escondido dentro da classe original.

O produto alterado foi devidamente assinado, portanto não havia motivo para suspeitar e as equipes de desenvolvimento confiaram no proprietário do código.

Só recentemente soubemos que o NPM tinha um “falha lógica”que permitiu que atores mal-intencionados passassem bibliotecas desonestas como legítimas. Basicamente, o NPM permitia adicionar qualquer pessoa como mantenedor de um pacote sem notificar esses usuários ou obter seu consentimento. 

Isso permitiu a criação de pacotes contendo malware e sua atribuição a mantenedores populares e confiáveis ​​sem o seu conhecimento. Um caso de confiança perdida pode significar uma vulnerabilidade problemática escondida em seu código.

Outra prática comum a ser considerada é que os desenvolvedores copiem e colem código de bibliotecas existentes ou StackOverFlow para uso em seu próprio código ou para recarregar em novas bibliotecas. Fazer isso aumenta a chance de copiar também código inseguro e vulnerável que agora não é rastreado. Mesmo que o código original receba um CVE e, eventualmente, uma correção, a função problemática que você copiou fica invisível e pode contaminar qualquer base de código que a utilizaria nos próximos anos. 

Em um estudo recente realizado na Universidade do Kansas (“O que é o garfo? Encontrando clones de código oculto no npm”), os pesquisadores ilustram como o uso de pacotes totalmente verificados pode ser inseguro.

O que você pode fazer sobre isso?

Portanto, você não pode confiar nos produtos assinados e nas atualizações dos fornecedores. Seu próprio código pode já ter sido modificado ou adicionado, devido a todas as bibliotecas externas e códigos incorporados a ele. O que, então, você pode fazer para ter certeza de que não está instalando arquivos maliciosos em seu sistema?

Há algumas coisas que tu podes fazer:

1. Solicite um SBOM completo de cada proprietário de biblioteca ou fornecedor de programa que você incorpora. Um SBOM pode ajudá-lo a ter certeza de quais são todos os 'ingredientes' da biblioteca ou produto. Além disso, se você encontrar algo na biblioteca ou produto que não esteja listado no SBOM, isso deverá ser considerado suspeito. Você pode aprender mais sobre o que é um SBOM SUA PARTICIPAÇÃO FAZ A DIFERENÇA.
2. Solicite um atestado confiável do fornecedor ou proprietário da biblioteca de que uma verificação de integridade foi feita e de que você está obtendo o que espera. Você não deveria ter que confiar apenas na garantia do próprio fornecedor.
   
3. Ao instalar pacotes, use o sinalizador CLI npm --ignore-scripts para evitar a execução de scripts de pacotes de terceiros durante a fase de instalação.
4. Usar um Pacote-lock.json arquivo para bloquear números de versão do pacote. Quando você usa um Pacote-lock.json você não bloqueia apenas as versões do pacote que está usando, mas também bloqueia suas dependências. O risco é que você não receba nenhuma atualização automatizada de pacotes que possa incluir correções para vários bugs. Mas, se você se esforçou para verificar uma determinada versão e não deseja incluir mais nada sem verificá-la primeiro, bloquear os números da versão é a melhor opção.

Agora sobre o novos regulamentos, espera-se que a maioria das pessoas comece a usar SBOMs em um futuro muito próximo. Quanto mais as empresas solicitarem SBOMs e outros atestados, mais organizações e mantenedores terão que cumprir.