0
0
O software de código aberto (OSS) tem muitos defensores. Afinal, por que tentaríamos continuamente escrever código que resolva problemas que outros já resolveram? Por que não compartilhar o conhecimento e melhorar gradual e incrementalmente as soluções de código aberto existentes? Esses ideais igualitários são indiscutivelmente centrais para a própria civilização – não importa o software – mas também contêm tensões subjacentes que têm sido um desafio por gerações.
Os prós e contras do OSS
O desafio da segurança do OSS é que só porque todos podem ver o código-fonte, isso não significa que ninguém o fará. Existem projetos de código aberto amplamente usados que estão sendo mantidos apenas por um pequeno número de engenheiros, e esses engenheiros não podem ser totalmente altruístas com suas contribuições de tempo e esforço – eles também têm contas a pagar.
Isso pode ser um desafio mesmo para projetos de código aberto maiores. Por exemplo: o projeto do kernel Linux tem mais de 30 milhões de linhas de código, centenas de bugs que precisam ser corrigidos e quase 2.000 desenvolvedores ativos trabalhando nele. São mais de 15.000 linhas de código por desenvolvedor ativo!
Um relatório recente da Linux Foundation descobriu que o número médio de vulnerabilidades críticas pendentes em um aplicativo é 5,1 e que 41% das organizações não confiam em sua segurança de software de código aberto. Pior ainda: apenas 49% das organizações têm uma política de segurança de código aberto.
Mesmo que um problema de segurança seja encontrado em um software de código aberto , isso não significa que alguém irá corrigi-lo. Este é um fato destacado pelo relatório, que descobriu que o número médio de dias para corrigir uma vulnerabilidade atualmente é de 97,8 – deixando as empresas que executam esse software abertas a ataques por muitos meses. Este é o lado frequentemente ignorado da segurança do OSS: enquanto os mocinhos podem caçar bugs e vulnerabilidades no código para corrigi-los, os bandidos podem caçar esses mesmos bugs para explorá-los.
Desafios de segurança do mundo real
A realidade é que esses possíveis problemas de segurança não são um problema imaginário distante ou FUD do setor que pode ser facilmente ignorado no mundo real. Devido à grande quantidade de código OSS em uso ativo, são inúmeros os exemplos de problemas de segurança ativos com código aberto. De fato, 70% do programa médio hoje é feito de software de código aberto, com o número de dependências variando amplamente de acordo com a linguagem: meras 25 dependências por projeto no caso do Python, mas enormes 174 por projeto no caso do JavaScript.
Como a situação com os pacotes colors.js e faker.js demonstrou no início deste ano, problemas com dependências podem ter um impacto real no software corporativo. As duas bibliotecas JavaScript simples foram incorporadas a milhares de programas Node Package Manager (NPM), que por sua vez foram baixados vários milhões de vezes toda semana – até que seu criador, o desenvolvedor JavaScript Marak Squires, os quebrou deliberadamente por razões desconhecidas. O resultado de Squires adicionar um loop infinito a colors.js e faker.js foi uma falha generalizada dos NPMs que incluíam seu código, levando a uma disputa para reverter as alterações para versões seguras (colors.js v1.40 e faker.js v5. 5.3).
Os benefícios da ajuda profissional
Contar exclusivamente com uma comunidade de voluntários para identificar vulnerabilidades, reportá-las e corrigi-las é uma aposta com probabilidades longas. Pagar alguém para investigar a segurança de suas soluções de código aberto pode ajudar a preencher essa lacuna, enquanto você continua aproveitando os benefícios mais amplos do código aberto.
Outro desafio com atualizações e patches de OSS é que eles precisam ser aplicados a sistemas seguros, fato que pode apresentar desafios específicos. Se sua solução de missão crítica depende de uma versão de software específica, a atualização pode significar perda de funcionalidade e/ou exigir tempo de inatividade não programado. Nesses cenários críticos para os negócios, às vezes é mais elegante empregar um especialista para fazer backport da correção e manter uma versão por um período mais longo do que a comunidade mais ampla suporta.
A segurança não é gratuita nem fácil
“É de código aberto, vá mudá-lo!” é uma afirmação que você ouvirá muito da comunidade de código aberto e destaca um fato importante: esperar bons níveis de segurança gratuitamente enquanto outros contribuem com tempo, esforço ou dinheiro para a equação não é razoável ou sustentável.
As opções incluem contribuir para o código aberto como foi originalmente planejado, melhorando o código e publicando-o para outros, ou empregando especialistas para gerenciar o código OSS e depurá-lo conforme necessário. Mas não fazer nenhuma contribuição é uma opção que a indústria não pode pagar.
FONTE: HELPNET SECURITY