O software open source está em todos os lugares. Ele movimenta navegadores, aplicativos, servidores e toda a infraestrutura digital que sustenta empresas modernas. Para muitos profissionais de segurança, esse tipo de código é apenas parte do ambiente — algo que já está ali, pronto para uso, e que raramente recebe atenção mais profunda.
Mas é justamente aí que mora o perigo.
Uma pesquisa recente conduzida por James Cusick, pesquisador da Universidade de Ritsumeikan, lança luz sobre um ponto crítico: o quão seguro é o código que usamos todos os dias?
Cusick analisou milhões de linhas de código, comparando projetos de código aberto com softwares proprietários, utilizando técnicas de varredura estática (static code scanning) para identificar vulnerabilidades — desde falhas leves até problemas críticos de segurança.
Dois projetos open source foram foco do estudo: o Chromium, base dos navegadores Chrome, Edge e Opera — um projeto gigantesco e amplamente auditado., e Genann, uma pequena biblioteca para redes neurais com menos de 700 linhas de código — muito menor e com menos visibilidade.
Além disso, foram incluídos no estudo softwares proprietários do tipo SaaS, desenvolvidos internamente por empresas, para efeito de comparação.
Os dados surpreendem: o Chromium apresentou 1.460 possíveis problemas em quase 6 milhões de linhas de código, sendo poucos considerados graves; já o Genann, com apenas 682 linhas, teve 6 problemas potenciais — o equivalente a 1 falha a cada 27 linhas, uma densidade alarmante.
Os softwares proprietários ficaram no meio-termo: cerca de 5.000 problemas em 3 milhões de linhas, com maioria de gravidade baixa ou média.
O resultado deixa claro que nem mesmo os projetos mais populares e bem mantidos estão livres de riscos ocultos. E quanto menor e menos auditado o projeto, maior pode ser a concentração de vulnerabilidades.
Para os líderes de segurança da informação (CISOs), esse estudo reforça um desafio crescente: a dependência de componentes de código aberto sem revisão adequada. Esses trechos de código são integrados em sistemas com frequência, mas raramente passam por uma análise rigorosa de segurança.
Mesmo grandes projetos como o Chromium podem conter brechas. E o perigo aumenta quando bibliotecas são adicionadas sem escaneamento prévio, já que, uma vez implantadas, se tornam difíceis de rastrear e atualizar.
Como alertou Cusick:
“Integrar código sem saber sua qualidade ou exposição a vulnerabilidades é como entrar num carro sem saber se os freios funcionam.”
Recomendação: Escaneamento Estático como Prática Padrão
A mensagem é clara: todo componente open source deve ser escaneado antes da implantação, e reavaliado a cada nova atualização. Além disso, é essencial ter um processo estruturado para priorizar e corrigir os problemas encontrados.
O estudo traz um guia prático para integrar o escaneamento estático ao ciclo de desenvolvimento seguro (Secure SDLC), cobrindo desde a escolha das ferramentas, aquisição do código, execução das análises, até o trabalho para revisar e corrigir vulnerabilidades.
Cada nova funcionalidade, atualização ou alteração no código pode introduzir falhas. Por isso, o escaneamento deve ser contínuo, conectado diretamente aos pipelines de desenvolvimento.
James Cusick acredita que a inteligência artificial já tem papel importante na detecção de falhas, mas alerta contra a ideia de que ela seja uma solução mágica:
“Ferramentas de IA para escaneamento estão prontas para uso, mas nenhuma oferece 100% de cobertura. Ainda é necessário julgamento humano, revisão de código, testes e priorização.”
Ele explica que, embora a IA possa otimizar partes do processo — como detecção e correção de vulnerabilidades —, o equilíbrio entre riscos, prazos e recursos ainda exige decisões humanas.
O código aberto continuará sendo parte fundamental do desenvolvimento moderno. No entanto, não pode ser tratado como livre de riscos. Ignorar essa realidade é um erro que pode comprometer a segurança de todo o sistema.
Ao integrar ferramentas de escaneamento ao desenvolvimento e à aquisição de software, as empresas ganham visibilidade sobre sua cadeia de suprimentos digital e reduzem o risco de falhas escondidas que podem se transformar em crises de segurança no futuro.
Abaixo está um checklist prático baseado nas recomendações do estudo de James Cusick, ideal para equipes de segurança, desenvolvimento ou DevOps que queiram adotar práticas seguras ao lidar com software open source:
- Antes de integrar uma biblioteca ou componente open source:
- Verificar a popularidade e atividade do projeto (número de contribuidores, commits recentes, issues abertas/fechadas).
- Confirmar a licença do projeto e se ela é compatível com o uso pretendido.
- Realizar escaneamento estático completo na biblioteca (usando ferramentas como SonarQube, Semgrep, Snyk, CodeQL etc.).
- Avaliar a densidade de vulnerabilidades encontradas (quantas falhas por linha de código).
- Classificar a gravidade das vulnerabilidades (baixa, média, alta, crítica).
- Registrar o componente e a versão utilizada em um inventário de dependências.
- Durante o ciclo de desenvolvimento:
- Integrar ferramentas de escaneamento no CI/CD para varreduras automáticas a cada commit ou merge.
- Estabelecer uma política de atualização de dependências com verificação contínua de novas versões.
- Definir processo de triagem e priorização de vulnerabilidades, com base em criticidade e impacto.
- Manter uma equipe (ou responsável) para revisão e remediação contínua dos riscos detectados.
- Ao atualizar bibliotecas open source:
- Avaliar impacto imediato no sistema ou serviço em produção.
- Corrigir ou mitigar o problema com hotfix ou rollback, se necessário.
- Documentar a vulnerabilidade, o impacto e as ações tomadas.
- Comunicar stakeholders internos, se houver risco relevante.
- Uso de Inteligência Artificial no processo (opcional):
- Testar ferramentas baseadas em IA para análise estática e priorização de falhas.
- Usar IA como complemento, não substituto, da revisão humana.
- Avaliar continuamente a acurácia dos resultados gerados por IA.
- Boas práticas de governança e cultura:
- Educar o time sobre os riscos de usar código open source sem análise.
- Estabelecer políticas formais de segurança de software.
- Fomentar uma cultura de responsabilidade compartilhada entre devs e segurança.
Nossa opinião
Mesmo projetos grandes e confiáveis como Chromium possuem falhas. Tamanho ou popularidade não garantem segurança. Avalie tudo. Sempre.