4 melhores práticas para evitar vulnerabilidades em código aberto

Este ano apresentou ainda mais desafios para garantir a integridade e a segurança dos ecossistemas de código aberto. O código aberto tem sido o maior benefício para os desenvolvedores, pois praticamente qualquer pessoa pode usá-lo e personalizá-lo, normalmente sem nenhum custo, e contribuir com a comunidade. O que tem sido um meio de garantir maior transparência e segurança. Além de que, promover a colaboração do desenvolvedor entre os projetos também abriu caminhos para que os adversários lucrem com a causa.

Como um pesquisador de segurança, eu encontrei e analisei incidentes este ano em que mais de 700 pacotes RubyGems com erros de digitação serviram para nenhum outro propósito além de minerar bitcoins. Depois, há o caso popular do Octopus Scanner, malware que silenciosamente injetou seus tentáculos em pelo menos 26 projetos do GitHub. Esses incidentes ressaltam o fato de que qualquer sistema aberto acessível ao público também é acessível aos adversários e está sujeito a abusos.

Os exemplos acima se concentram em componentes maliciosos. E quanto aos pacotes legítimos de código aberto com vulnerabilidades de segurança que passam despercebidas?

Um pacote vulnerável ou malicioso que entra em repositórios populares e, eventualmente, em sua cadeia de suprimentos de software, pode causar estragos para seus clientes. Componentes vulneráveis e maliciosos foram detectados em repositórios populares de código aberto, como npm, PyPI, NuGet e Fedora.

“Nos últimos anos, vimos que em termos de vulnerabilidades totais identificadas em pacotes de código aberto nos ecossistemas, Node.js e Java têm tradicionalmente mostrado o maior número de novas vulnerabilidades a cada ano”, disseram os autores do Snyk’s State of Open Source Security Report 2020.

O relatório também sugere que os esforços de segurança implementados no início do processo de desenvolvimento de software são responsáveis pelo menor número de novas vulnerabilidades relatadas em 2019 do que em 2018. “Se essa tendência continuar, pode ser um sinal positivo de que os esforços para melhorar a segurança do software de código aberto estão começando a dar frutos”, continua o relatório.

Aqui estão algumas práticas recomendadas para gerenciar código-fonte aberto com segurança.

Conheça o seu software

O 2020 DevSecOps Community Survey conduzido pela Sonatype revela que a maioria das empresas – mesmo aquelas com algum nível de práticas DevOps embutidas em seu fluxo de trabalho, não têm visibilidade completa de todos os componentes de código aberto que seus aplicativos de software estão usando e quais vulnerabilidades se aplicam a eles.

“Quando uma vulnerabilidade é anunciada em um projeto de código aberto, você deve fazer duas perguntas imediatamente: já usamos esse componente de código aberto e (se sim) onde ele está?”, disseram os autores do relatório.

Uma pesquisa separada da Sonatype com mais de 5.000 desenvolvedores mostrou que apenas 45% das organizações com práticas de DevOps maduras mantêm uma lista completa de materiais de software (SBOM) para seus aplicativos. “Os resultados revelam que até 74% das organizações com ‘práticas imaturas’ não teriam meios de saber se uma vulnerabilidade recém-divulgada em um componente de código aberto é aplicável ao seu software”, disse o relatório. Isso significa que as organizações com práticas imaturas que mantêm um SBOM completo não saberiam se haviam usado código-fonte aberto vulnerável ou onde encontrar vulnerabilidades recém-anunciadas em seus ambientes.

Dado o vasto volume de vulnerabilidades publicadas todos os dias no NVD, GitHub e outros sites de hospedagem, seria muito difícil para os desenvolvedores e profissionais de segurança acompanhar esses dados sem alguma solução automatizada. A história mostra que a maioria das organizações espera até que um incidente de segurança ocorra para intensificar seus esforços de segurança. No entanto, como diz o velho ditado, um grama de prevenção é melhor do que meio quilo de cura.

Implementar a segurança desde o início, adotando uma abordagem de “mudança para a esquerda” quando se trata de seu ciclo de vida de desenvolvimento de software pode ter retornos dez vezes maiores e aumentar a consciência geral de seus desenvolvedores.

Resolva problemas de dependência

O relatório 2020 State of Software Security da Veracode destaca um problema comum de segurança de software. Em vez dos próprios desenvolvedores, as “dependências interconectadas” indiretamente introduzem riscos latentes em seus aplicativos que podem escapar do radar da maioria dos desenvolvedores. “Nossos dados revelam que a maioria das bibliotecas com falhas termina no código indiretamente. Quarenta e sete por cento das bibliotecas com falhas em aplicativos são transitivas – em outras palavras, elas não são puxadas diretamente pelos desenvolvedores, mas estão sendo puxadas pela primeira biblioteca (42% são puxadas diretamente, 12% são ambas). Isso significa que os desenvolvedores estão introduzindo muito mais código, e muitas vezes código com falhas, do que poderiam estar prevendo”, leu o relatório.

No entanto, corrigir esse problema não parece ser uma tarefa importante, de acordo com o Veracode: “Resolver as falhas de segurança nessas bibliotecas, na maioria das vezes, não é um trabalho significativo. A maioria das falhas introduzidas pela biblioteca (quase 75%) nos aplicativos podem ser resolvidas com apenas uma pequena atualização da versão. Geralmente, não são necessárias grandes atualizações de biblioteca! Este ponto de dados sugere que este problema é de descoberta e rastreamento, não grande refatoração de código”.

Automatize a varredura de código para encontrar novos desconhecidos

O incidente do Octopus Scanner e outras formas de abuso do ecossistema de código aberto, como typosquatting, levaram os mantenedores de repositórios como o GitHub a reforçar a varredura automática de projetos de código aberto que hospedam. Conforme relatado este ano, o GitHub agora integra varredura automática baseada em CodeQL de seus repositórios de código aberto.

Justin Hutchings, Gerente de Produto Sênior do GitHub, disse ao The Register: “Acontece que esse recurso é extremamente útil em segurança. A maioria dos problemas de segurança são fluxo de dados ruim ou uso de dados ruim de uma forma ou de outra”.

Além de identificar vulnerabilidades e bugs ocultos, a varredura regularmente varre projetos de código aberto em busca de sinais de vazamento de dados, como chaves privadas e credenciais inadvertidamente tornadas públicas pelo contribuidor. Desde o ano passado, alguns fornecedores integraram esforços de varredura automatizada em seus produtos para identificar malware publicado em repositórios legítimos de código aberto. Essas técnicas incorporam análise comportamental com machine learning para caçar proativamente por “componentes falsificados”.

Scanners experimentais de código aberto (como npm-scan) publicados por desenvolvedores independentes em uma escala menor também surgiram e servem a propósitos semelhantes de detecção de componentes vulneráveis usando heurísticas. Na frente do RubyGems, esforços contínuos de monitoramento e análise de ReversingLabs é o que levou à descoberta dos mais de 700 componentes maliciosos mencionados anteriormente.

Habilitar essas auditorias de segurança generalizadas usando ferramentas de automação pode ajudar a aumentar os problemas de confiança e integridade dentro do ecossistema de código aberto, antes que os componentes cheguem à sua cadeia de suprimentos.

Cuidado com os riscos de licenciamento

A vantagem principal de usar software de código-fonte aberto é a liberdade oferecida por suas licenças permissivas. Se você descobrir um bug em um pacote de código aberto que não foi corrigido, você mesmo pode corrigi-lo, em vez de esperar pelo fornecedor. Você pode personalizar um aplicativo de código aberto em seu projeto como achar adequado e enviar uma versão personalizada para seus clientes.

No entanto, é necessário um pouco mais de habilidade para estar ciente de quaisquer conflitos de licenciamento em potencial que podem surgir do uso de componentes de código aberto. O relatório de análise de risco e segurança de código aberto de 2020 publicado pela Synopsys afirma:

“Os conflitos de licença declarados surgem quando uma base de código contém componentes de código aberto cujas licenças parecem conflitar com a licença geral da base de código. Por exemplo, o código sob a GNU General Public License v2.0 (GPLv2) geralmente apresenta um problema de conflito quando compilado em um software comercial normalmente distribuído. Mas o mesmo código não é um problema em software considerado software como serviço ou SaaS”.

Esses termos conflitantes podem criar confusão para os desenvolvedores que usam os mesmos aplicativos de código aberto em contextos ligeiramente diferentes. Algumas soluções de automação podem reconhecer várias licenças e conflitos potenciais decorrentes delas, além de vulnerabilidades e componentes maliciosos.

Um relatório da Black Duck descobriu que 67% das bases de código auditadas de 2019 continham componentes com conflitos de licença. Essa porcentagem era muito maior para alguns setores, como internet e aplicativos móveis (93%) “A GPL é uma das licenças de código aberto mais populares e suas várias versões podem criar conflitos de licença com outros códigos em bases de código. Na verdade, cinco das 10 principais licenças com conflitos eram a GPL e suas variantes”, afirmou o relatório.