Com tantas notícias sobre vazamentos de dados, mesmo em um mundo onde recebemos atualizações de softwares o tempo todo, nos questionamos sobre quais as melhores práticas para mantermos nossos dados seguros. Programas com código fechado podem parecer mais seguros, afinal, como ninguém, além dos desenvolvedores, conhece o código-fonte, fica mais difícil encontrar brechas. Por outro lado, programas com código aberto podem receber sugestões de melhoria vindas de qualquer um, aumentando o número de pessoas dedicadas a aprimorá-lo.
Em 2022, a empresa Synopsis analisou a base do código de 2.400 empresas distribuídas entre 17 mercados e constatou que 78% do código-fonte utilizado era aberto, entretanto, cerca de 81% deles continham ao menos uma vulnerabilidade. Tudo fica mais claro, ao vermos o dado de que 88% dos componentes utilizados não estão em sua última versão e, na verdade, 85% dos programas de código aberto não foram atualizados nos últimos quatro anos.
Isso indica que as vulnerabilidades apresentadas pelas empresas não originam do código ser aberto ou fechado, mas por ela não seguirem boas práticas, como manter seus programas atualizados. Ademais, ter código fechado, não garante que outras pessoas não realizem engenharia reversa para compreender como o programa funciona, apesar de ser mais difícil do que simplesmente ler o código-fonte.
Qual a sua opinião? O código ser aberto ou fechado influencia na segurança do software? Quais outras medidas ajudam a garantir a segurança?
Estive lendo um artigo em que afirmaram que ninguém vai ficar verificando os milhares de códigos abertos que são criados e isso me fez pensar que podem haver sim trechos maliciosos nesses códigos por já serem impossíveis de verificação e que nem com engenharia reversa ou outras técnicas seriam capazes de detectar.
Complicado falar que “ninguém vai verificar/é impossível verificar” quando o código está escancarado para qualquer um que tiver interesse e, em projetos famosos o suficiente (como o Linux), há organizações que vivem de olhar esse código, como a Qualys e Project Zero (Google).
Fora que compilando e analisando binário que é produzido, dá para detectar trechos frágeis com os mesmos métodos usados quando o código fonte não é disponível.
Taí uma coisa boa para a IA: vasculhar vulnerabilidades em códigos abertos. Imagine como seria incrível.
Você faz um fork de um projeto e pede para o Copilot no GitHub checar o código… aí ele faz testes e mais testes propõe melhorias e pode aplicar você permitir. Daria uma velocidade monstra nos updates de projetos de código aberto.
Em resumo: grande parte das vulnerabilidades são detectadas e corrigidas rapidamente em programas de código aberto. O problema é que as correções muitas vezes acabam não chegando às máquinas.
Infelizmente, a irresponsabilidade ainda é muito frequente no mercado. E surpreende que aconteça até mesmo em grandes empresas e instituições públicas. O item mais básico, que é manter o sistema operacional com as atualizações de segurança em dia, acaba sendo negligenciado.
Essa proporção de componentes não atualizados nos últimos quatro anos é insana e mostra o tamanho do problema. Eu mesmo trabalho em uma instituição pública e, por observação própria, posso dizer que o setor de TI é despreparado e sofre com falta de pessoal.
Se não me engano o Debian tem um início desse tipo de projeto, não é uma IA mas tem um robo procurando falhas e vulnerabilidades nos pacotes.
Pode ser um começo de algo grande e que não fique restrito só há uma distro.
E como um humano sabe? Um spoiler pra adiantar: não sabe, análise de um software depende da parte dinâmica e uma IA não consegue a parte dinâmica, o código do Plasma Vault seria facilmente identificado como malicioso, embora definitivamente não seja
Eu não acho que programas de código aberto ou fechado sejam necessariamente mais seguros ou menos seguros apenas por serem de código aberto ou fechado. Acredito que essa discussão seja bastante plausível, e concordo com a maioria dos comentários acima, como os do @Capezotte , @KairanD e @Rodrigo_Zimmermann1 . No entanto, acredito que muitas pessoas optam por usar softwares de código aberto não apenas por questões de segurança, mas também por uma questão de filosofia e transparência sobre o uso de seus dados, como mencionado em um post que vi neste fórum.
segue a postagem: Como ter NetWork sem rede social
Nisso não da pra discordar nem um pouco, pois tanto IAs quanto Bots deixam passar muita coisa em questão de problemas, não só segurança mas funcionamento dos softwares
Por isso que testes com “humanos”(tanto quanto os proprios devs testam) sempre e mais facil detectar bugs
Um IA pode “entender” um comportamento estranho de um programa com base em seu código fonte. Mas o problema de segurança mais grave é no elo humano em um sistema. Quem faz toda a “mágica” da insegurança é o usuário que não respeita as camadas de segurança.
Não exatamente, o que uma IA faz se chama análise estática, ela meio que não consegue saber como um código vai se comportar dinamicamente, considere a função abaixo:
O que ele faz? Analisando estaticamente ele baixa alguma coisa de algum e salva em outro, a questão aqui é, como saber se ela é perigosa ou não?
Ela pode estar no APT
Pode estar num gerenciador de download
Pode estar num Trojan
O que a torna nociva não é sua implementação (que é o que analise estática consegue ver) mas o que ela baixa em execução e isso é imprevisível a IA não consegue identificar comportamento estranho no código porque ele simplesmente não existe, o que a IA pode e está sendo usada é corrigir código ruim que leva a falha de segmentação (identificar se o programa tenta acessar um ponteiro nulo por exemplo) nesse tipo de segurança a IA brilha, mas sinceramente qualquer linter ou compilador já faz isso
E se ela usar um sandbox para estudar o potencial?
Um dos exemplos práticos do uso da IA, pode ser em evolução de código, melhorias de compiladores, gerenciamento de memória, tonar códigos mais enxutos, documentar etc.
A IA vai fazer o que o humano disser a ela, ela lida com o passado (conhecimento).
