Código aberto: os 10 principais riscos para os negócios

As empresas de TI foram as primeiras a adotar o código aberto e muitas grandes empresas seguiram o exemplo. Afinal, a capacidade de reutilizar e modificar o código independentemente, bem como corrigir bugs, estimula a inovação rápida e a redução de custos.

Mas o código aberto também tem algumas características negativas inerentes – devido às responsabilidades confusas de criar e manter o código. O Endor Labs, auxiliado por mais de 20 CISOs e CTOs de grandes empresas de TI, realizou uma análise sistemática para produzir esta lista dos 10 principais riscos.

Vulnerabilidades conhecidas

O risco mais significativo identificado foi a presença de vulnerabilidades tanto no próprio projeto de código aberto quanto em suas dependências — ou seja, componentes externos de código aberto usados ​​no projeto. Vulnerabilidades em dependências podem causar problemas críticos para dezenas de grandes suites de software comercial, como foi o caso da modesta biblioteca Apache Log4j (CVE-2021-44228).

Como se proteger: Examine regularmente seus aplicativos em busca de vulnerabilidades conhecidas — incluindo aquelas com dependências diretas e indiretas. Aplique as correções disponíveis prontamente. Para otimizar os recursos da empresa, as patches podem ser priorizadas com base na gravidade de uma determinada vulnerabilidade e na probabilidade de sua exploração no software utilizado.

Pacotes legítimos comprometidos

Como até 80% do código do projeto de código aberto é herdado de outros projetos na forma dessas dependências, sempre há uma chance de que os componentes de terceiros usados ​​em seu aplicativo tenham sido trojanizados. Isso pode acontecer quando o desenvolvedor desses componentes é hackeado ou o sistema de distribuição de componentes (ou seja, o gerenciador de pacotes) contém uma vulnerabilidade que permite que o pacote seja falsificado. Nesse caso, um código malicioso de terceiros aparece repentinamente em seu aplicativo, que na prática é frequentemente usado para roubar informações ou para vários esquemas ilícitos de enriquecimento (spam, golpes de adware, mineração).

Como se proteger: Atualmente, não existe uma metodologia madura para proteger contra essa ameaça, portanto, uma combinação de medidas é necessária: sistemas manuais e automáticos para análise de código-fonte e monitoramento de repositórios; armazenamento local de versões confiáveis ​​de componentes; uso de Inteligência contra ameaças para detectar tais ataques em seus estágios iniciais (antes que eles tenham tempo de afetar os pacotes usados ​​nos aplicativos de código aberto da empresa).

Ataque dos “homônimos”

Os invasores criam pacotes com nomes que lembram pacotes legítimos ou copiam os nomes de pacotes verdadeiros desenvolvidos em outras linguagens de programação ou publicados em diferentes plataformas de distribuição. Isso cria o risco de que seus desenvolvedores de código aberto possam integrar um pacote malicioso “homônimo” em vez do genuíno.

Como se proteger: instrua os desenvolvedores a ficarem vigilantes. Como parte de um procedimento padrão, antes do uso, os desenvolvedores precisam verificar o código-fonte dos pacotes quanto a peculiaridades, como fragmentos criptografados no código, sequestro de funções e afins. E é aconselhável verificar as assinaturas digitais dos pacotes (se houver).

Código não suportado

Os desenvolvedores de componentes, pacotes e aplicativos de código aberto podem obter suporte para eles a qualquer momento e por qualquer motivo. Isso geralmente acontece com pequenos pacotes desenvolvidos por uma ou duas pessoas. Se isso acontecer, não há quem atualize o pacote para compatibilidade com novas tecnologias ou elimine riscos de segurança da informação.

Como se proteger: Avalie o nível de maturidade do projeto e as perspectivas de desenvolvimento/suporte antes de integrá-lo aos processos de negócios e ao seu próprio código. Preste atenção ao número de desenvolvedores que mantêm o projeto e à frequência dos lançamentos. Verifique os lançamentos de suporte de longo prazo (LTS, na sigla em inglês) e quando eles foram lançados. Para alguns projetos estáveis, no entanto, é normal que os lançamentos sejam pouco frequentes e apenas corrijam bugs.

Software desatualizado

O uso de versões antigas de componentes em projetos torna a correção muito mais difícil. Esse problema é especialmente crítico no caso do risco número um: vulnerabilidades em componentes. Normalmente, um problema com dependências obsoletas surge quando uma nova versão de um componente difere significativamente das iterações anteriores em termos de sintaxe ou semântica. Nesse cenário, uma versão desatualizada pode permanecer em uso por muitos anos sem nenhuma atualização de segurança.

Como se proteger: dê tempo aos desenvolvedores para trabalhar com dependências — incluindo a refatoração do código para atualizá-las para as versões mais recentes dos componentes em uso.

Dependências não rastreadas

Como quase todos os aplicativos usam componentes de terceiros — que, por sua vez, usam outros componentes de terceiros — os desenvolvedores do aplicativo principal geralmente não sabem que um determinado componente está em seu código. Nesse caso, ele não é verificado quanto a todos os outros riscos da lista. O status de atualizações, vulnerabilidades e o resto é simplesmente desconhecido.

Como se proteger: Mantenha uma Lista de Materiais de Software (SBOM, na sigla em inglês) detalhada com o uso de ferramentas de varredura que podem detectar até mesmo dependências que são usadas sem um gerenciador de pacotes.

Riscos regulatórios e de licenciamento

Apesar de ser de código aberto, todo aplicativo e pacote deste tipo vem com sua própria licença de uso. Os riscos surgem se a licença for incompatível com o uso do aplicativo para a finalidade pretendida ou se as licenças de alguns componentes do aplicativo forem incompatíveis entre si. Também é possível que um ou mais componentes de dependência violem as leis aplicáveis ​​ou os requisitos regulatórios impostos à empresa.

Como se proteger: A já mencionada SBOM e as ferramentas de varredura de código devem ser usadas ​​para rastrear licenças e requisitos de licenciamento aplicáveis ​​a aplicativos e componentes de código aberto usados ​​na empresa. E faz sentido trabalhar com o departamento jurídico para desenvolver uma lista de licenças padrão aceitáveis ​​para a empresa, detalhando sua compatibilidade com a finalidade do software utilizado. Software com licenças incompatíveis ou sem licença deve ser removido.

Software imaturo

Utilizar componentes desenvolvidos por uma equipe sem maturidade traz uma série de inconveniências e riscos. Os problemas associados ao software imaturo variam de documentação de código insuficiente ou imprecisa a instabilidade e operação propensa a erros e a ausência de um conjunto de testes para avaliação de regressão. Além do mais, o código imaturo tem maior probabilidade de abrigar vulnerabilidades críticas. Tudo isso torna impraticável o uso de software imaturo e aumenta tanto os custos envolvidos quanto os riscos de eventos críticos e tempo de inatividade.

Como se proteger: Antes de implantar um aplicativo ou componente, verifique se os desenvolvedores estão usando as melhores práticas atuais. Indicadores disso incluem documentação completa e atualizada, pipelines de CI/CD para testes de regressão, bem como informações detalhadas sobre a cobertura do teste e até mesmo o número de pacotes que já usam o componente fornecido.

Alterações não aprovadas

Os componentes usados ​​por um aplicativo podem mudar de maneira completamente invisível para seus desenvolvedores. Essa situação pode surgir se os componentes forem baixados de um servidor sem controle de versão estrito e/ou por canais de comunicação não criptografados e não forem verificados usando hashes e assinaturas digitais. Nesse caso, a montagem do aplicativo teoricamente pode produzir um resultado diferente a cada vez.

Como se proteger: Seja rigoroso na aplicação de práticas de desenvolvimento seguras. Durante o desenvolvimento, use identificadores de recursos que indiquem claramente a versão do componente. Além disso, verifique os componentes baixados usando assinaturas digitais. Sempre use protocolos de comunicação seguros.

Dependências muito grandes ou muito pequenas

Atualmente, os desenvolvedores podem integrar um componente com apenas três linhas de código. Ao mesmo tempo, é igualmente prejudicial quando todo o componente consiste em quatro linhas de código (muito pequenas) e quando o código que você pretende usar é apenas um dos milhares de recursos do componente — o restante não é usado no aplicativo da empresa. Nesse caso, os desenvolvedores ficam sobrecarregados com a manutenção de mais uma dependência por causa desta funcionalidade mínima.

Como se proteger: Evite dependências com pouca funcionalidade; desenvolva tal funcionalidade dentro do aplicativo principal.