Sempre haverá vulnerabilidades no software - não existe segurança perfeita, não há código perfeito. Isso levanta a questão: qual é a melhor maneira de corrigir problemas de software, especialmente em grande escala? Como muitas vezes acontece em questões de segurança, a resposta é "depende".
Quem deixou os bugs escaparem?
O software de código aberto permite a qualquer pessoa – para o bem ou para o mau - dar uma olhada por baixo do capô e, com sorte, corrigir problemas de segurança ou funcionalidade. Mas eles também podem introduzir backdoors que muitas vezes passam despercebidos, às vezes por anos, de acordo com um estudo de 2022 publicado na 31ª USENIX Security Symposium.
Por outro lado, o software de código fechado depende do sigilo de seu código-fonte e da perícia de seus próprios desenvolvedores de software, uma espécie de segredo interno, mantido por especialistas com sólidas reputações em segurança, onde sua habilidade é pelo menos boa o suficiente para manter clientes e garantir a permanência do negócio. Independentemente de disponibilizarem ou não o código-fonte, os desenvolvedores podem se beneficiar de documentos como o OWASP Top Ten e os Padrões de Codificação SEI CERT, que promovem o desenvolvimento de práticas de codificação segura.
Embora o software de código aberto tenha raízes desde a década de 1950, só na década de 1980 o software passou a ser considerado passível de direitos autorais nos Estados Unidos. Um dos resultados disso foi que muitos fornecedores que anteriormente incluíam o código-fonte em seus produtos deixaram de fazê-lo. Ao longo das décadas de 1980 e 2000, algumas empresas de software, como a Microsoft, viam o software de código aberto como uma espécie de ameaça existencial aos seus negócios, antes de abraçá-lo na década de 2010.
Hoje, as grandes empresas de tecnologia promovem cada vez mais a colaboração público-privada na segurança do software de código aberto, a ponto de a Casa Branca ter realizado uma cúpula sobre a segurança desse tipo de software em 2022, possivelmente em resposta à exploração generalizada de vulnerabilidades no software de código aberto. Durante a produção deste artigo, a CISA anunciou a publicação de seu roadmap de segurança para software de código aberto, destacando tanto o reconhecimento de sua importância no ecossistema tecnológico quanto o compromisso em ajudar a garantir sua segurança.
As empresas de software de código fechado também têm a capacidade de designar alguém para atualizar o software com base nos problemas que surgem. O software de código aberto depende geralmente mais de voluntários para intervir e corrigir problemas à medida que surgem, uma propriedade conhecida como "Lei de Linus": "dados olhos suficientes, todos os erros são óbvios". Mas como é difícil coordenar voluntários, é ainda pior forçá-los com que façam o trabalho diário de correção oportuna de bugs - a parte da segurança que não é glamorosa - e as atualizações podem atrasar. No entanto, isso pode estar mudando: programas de recompensa por bugs oferecidos por empresas como Google e Huntr são uma forma de monetizar a descoberta e correção de vulnerabilidades em software de código aberto.
A realidade do software moderno está em algum lugar no meio - muitos projetos de código fechado costumam depender fortemente de grandes volumes de "estrutura" de software de código aberto para realizar as tarefas básicas antes de adicionar sua "fórmula secreta" por cima. Faz sentido, por exemplo, não construir um aplicativo de e-mail do zero para notificações administrativas: existem projetos de código aberto bem testados que podem lidar facilmente com isso.
Algumas empresas mais orientadas para o código aberto, por outro lado, contribuem ativamente para projetos de software de código aberto que consideram importantes, e como têm clientes comerciais, sua receita comercial faz com que seja possível empregar alguém cujo trabalho é corrigir bugs.
Mas essa estranha confluência de forças ainda pode permitir problemas como as vulnerabilidades do Log4j, que podem minar a infraestrutura e possivelmente fornecer um backdoor, independentemente de o stack completo que você usa como produto ser aberto, fechado ou, o mais provável, algo entre os dois.
Um efeito secundário do software de código aberto é que ele ajuda a impulsionar comunidades inteiras de software de comunicação que desejam atuar de forma segura, uma vez que não precisam construir tudo do zero para tentar acertar na criptografia.
Isso é o que fazem alguns dos projetos de software de proteção de privacidade mais populares do mundo, como Proton e Signal, cada um com sólidas reputações e históricos de manter as coisas privadas e seguras.
Os criadores do Signal convidam qualquer pessoa a revisar seu código, e como a mensagens pessoais são uma função tão importante para a sociedade, multidões de profissionais de segurança estão focados nisso, porque uma vulnerabilidade ou fraqueza criptográfica pode ter consequências de longo alcance.
O Proton, sediado na Suíça, começou com e-mail superseguro e depois expandiu para uma série de outros serviços relacionados à proteção da identidade do usuário - outra função extremamente importante para a sociedade e com consequências significativas se errarem.
Para que você não pense que o código fechado tem um histórico melhor, até mesmo o software de código fechado mais amplamente utilizado no mundo pode conter vulnerabilidades por anos, se não décadas. Considere a vulnerabilidade CVE-2019-0859. Descoberta pela Kaspersky Lab, é uma vulnerabilidade de uso após liberação encontrada em dez anos de sistemas operacionais Microsoft Windows, desde o Windows 7 até o Windows 8, o Windows 8.1 até o Windows 10 no lado do desktop, e as versões do Windows Server 2008 R2, 2012, 2012 R2, 2016 e 2019.
O problema pode estar nos detalhes
A verdade é que nem o software de código aberto nem o software de código fechado são inerentemente mais seguros do que o outro. O que importa é o processo pelo qual o software é desenvolvido e as correções são implementadas para as vulnerabilidades. A confiabilidade dessas correções e a velocidade com que podem ser implementadas são o que as organizações devem se concentrar para determinar uma postura de segurança - não o tipo de licença de software.
No final, tudo se resume à responsividade da organização anfitriã à comunidade de segurança em geral. A ESET, por exemplo, contribui significativamente para o framework MITRE ATT&CK® e fornece muitas outras ferramentas de segurança que frequentemente são gratuitas para uso ou de código aberto.
No mundo híbrido do software, quase sempre uma combinação de software de código aberto e de código fechado, isso se torna o teste decisivo: se a empresa ou organização está aberta a sugestões e contribuições e se reinveste na comunidade de segurança. Há um ditado sobre a empresa que você mantém, certifique-se de que sua equipe de software está em boa companhia, e a crescente maré de segurança elevará todas as embarcações digitais. E embora a segurança perfeita continue sendo elusiva, ótimas equipes com boas reputações certamente podem ajudar.
