Linus Torvalds, o criador do Linux e do Git, tem sua própria lei no desenvolvimento de software, e é assim: ” com olhos suficientes, todos os bugs são superficiais .” Esta frase coloca o dedo no próprio princípio do código aberto: quanto mais, melhor, se o código estiver facilmente disponível para qualquer um e todos corrigirem bugs, é bastante seguro. Mas é? Ou o ditado “todos os bugs são superficiais” é válido apenas para bugs superficiais e não para aqueles que são mais profundos? Acontece que falhas de segurança em código aberto podem ser mais difíceis de encontrar do que pensávamos.
A emoção da caça (à vulnerabilidade)
Encontrar vulnerabilidades de código aberto normalmente é feito pelos mantenedores do projeto de código aberto, usuários, auditores ou pesquisadores de segurança externos. Mas apesar desses grandes arqueólogos de código ajudarem a proteger nosso mundo, a comunidade ainda luta para encontrar falhas de segurança.
Em média, leva mais de 800 dias para descobrir uma falha de segurança em projetos de código aberto. Por exemplo, a infame vulnerabilidade Log4shell (CVE-2021-44228) não foi descoberta por 2.649 dias.
Java e Ruby parecem ter os maiores desafios aqui, pois a comunidade leva mais de 1.000 dias para encontrar e divulgar vulnerabilidades.
A agulha em um techstack
Outros fatores interessantes são que alguns dos diferentes tipos de fraqueza (CWE) parecem ser mais difíceis de encontrar e divulgar, o que na verdade contradiz a lei de Linus. Os tipos de fraqueza CWE-400 (consumo de recursos não controlados) e CWE-502 (desserialização de dados não confiáveis) normalmente não são localizados em uma única função ou podem aparecer como lógica pretendida no aplicativo. Em outras palavras, não pode ser considerado “um bug superficial”.
Parece também que a comunidade de desenvolvedores é um pouco melhor em encontrar CWE-20 (Improper Input Validation), onde a falha na maioria das vezes são apenas algumas linhas de código em uma única função.
Resolva vulnerabilidades com remediação poderosa
Por que isso importa? Como consumidores de código aberto, e isso é quase todas as empresas em todo o mundo, o problema das vulnerabilidades em código aberto é importante. Os dados nos dizem que não podemos confiar totalmente na Lei de Linus – não porque o código aberto seja menos seguro do que outros softwares, mas porque nem todos os bugs são superficiais .
Felizmente, existem ferramentas poderosas para realizar análises em escala de muitos projetos de código aberto de uma só vez. Seria ingênuo não supor que organizações e indivíduos mal-intencionados façam o mesmo. Como um ecossistema que estabelece as bases para nosso mundo centrado em software, a comunidade deve melhorar significativamente sua capacidade de encontrar, divulgar e corrigir falhas de segurança em código aberto.
No ano passado, o Google destinou US$ 10 bilhões a um fundo de código aberto para ajudar a proteger o código aberto com uma função de curador específica para trabalhar ao lado dos mantenedores com esforços de segurança específicos.
Além disso, há empresas mundo a fora que ajudam a tornar essas vulnerabilidades acionáveis, verificando todos os seus softwares, todas as filiais, todos os push e todos os commits em busca de novas vulnerabilidades (de código aberto). Essas empresas verificam continuamente todos os seus commits antigos em busca de cada nova vulnerabilidade, para garantir que eles tragam inteligência atualizada, precisa e acionável no código aberto que você utiliza. Além disso, algumas empresas ainda ajudam os desenvolvedores a corrigir suas falhas de segurança com pull requests automatizados que não causarão dependências infernais; muito preciso!
A verdade está nos dados
Então, sabendo de tudo isso, qual a melhor forma de proteger seu projeto ou empresa contra vulnerabilidades open source? Como vimos no caso do Log4j e Spring4shell, bem como os números, nunca podemos realmente confiar que a comunidade encontrará e corrigirá todos os riscos. Há uma boa chance de que existam muitas e muitas vulnerabilidades não descobertas e não divulgadas em seu código hoje, e não há muito que você possa fazer sobre isso. A melhor maneira de mitigar isso é implementando a verificação contínua de vulnerabilidades em seu SDLC. Isso garante que você seja atualizado em tempo real, você saberá sobre novas vulnerabilidades antes de qualquer outra pessoa.
REFERÊNCIAS:
https://thehackernews.com/2022/11/last-years-open-source-tomorrows.html