Linux e o mundo open source como um todo estão em todos os lugares. Até mesmo a concorrente Microsoft se rendeu aos dois nos últimos anos. Estão na nuvem, nos 500 melhores e mais potentes supercomputadores do planeta. E, claro, no desktop. Afinal, o Linux só cresce, mesmo que não seja no ritmo desejado. Até mesmo a polêmica plataforma Pornhub afirma que os usuários do Linux cresceram 28%. Já o número de usuários do Windows caiu 3%.
O software de código aberto não tem ficado para trás, embora o ritmo seja bem reduzido. está crescendo aos trancos e barrancos. De acordo com o Hype Cycle de 2021 do Gartner para software de código aberto (OSS):
Até 2025, mais de 70% das empresas aumentarão seus gastos com TI em OSS, em comparação com seus gastos atuais com TI. Além disso, até 2025, software como serviço ( SaaS) se tornará o modelo de consumo preferido para OSS devido à sua capacidade de oferecer melhor simplicidade operacional, segurança e escalabilidade.
De acordo com a Gartner cerca de 70% dos novos aplicativos internos serão desenvolvidos em um banco de dados de código aberto. Ao mesmo tempo, nada menos que 50% das instâncias de banco de dados proprietário existentes se converteram ou ainda serão convertidas em DBMSs de código aberto.
Segurança será prioridade de desenvolvedores de código aberto e Linux
No entanto, essa ampliação de uso traz consequências nem sempre benéficas. Basta que citemos as recentes falhas de segurança com a biblioteca de código-fonte aberto log4j2 do Apache Java. Isso tem causado muita dor de cabeça, já que essa falha é considerada a pior possível. De acordo com o National Vulnerability Database (NVD), a classificação é 10,0 no CVSSv3.
O grande problema não é existirem falhas no Linux ou no código aberto. A grande questão é ter pessoal suficiente para fazer a varredura constante desses problemas e tentar solucionar o mais rápido possível. A lei de Linus aborda exatamente isso. Também podemos citar a lei de Schneier, “A segurança é um processo, não um produto” Portanto, tudo isso indica que é necessário haver uma vigilância constante para proteger todos os softwares. Dito isso, a verdadeira dor de cabeça com o log4j é como o Java esconde quais bibliotecas seu código-fonte e binários usam em diversas variações do Java Archive (JAR). Assim, você pode estar usando uma versão vulnerável do log4j e não saber até que seja explorado.
Josh Bressers, vice-presidente de segurança da Anchore afirma:
Um dos desafios que a vulnerabilidade do log4j apresenta é realmente encontrá-la. Aplicativos e dependências Java geralmente estão em algum tipo de formato de empacotamento que torna a distribuição e a execução realmente fáceis, mas pode tornar difícil descobrir o que está dentro desses pacotes de software.
Felizmente, existem scanners log4j que podem ajudar a identificar bibliotecas log4j defeituosas em uso. No entanto, eles não são perfeitos. Entretanto, fica difícil saber exatamente quais componentes com problema estão sendo usados. Para isso, foi criada um lista de softwares, ou software (SBOM). Esse SBOM especifica exatamente quais bibliotecas de software, rotinas e outros códigos foram usados em qualquer programa. Somente assim, é possível examinar quais versões de componentes são usadas em seu programa.
David A. Wheeler, Diretor de Segurança da Cadeia de Suprimentos de Código Aberto da Linux Foundation, já falou sobre SBOMs e compilações reproduzíveis verificadas. Assim, a falha de segurança pode ser achada com maior facilidade e, consequentemente, corrigida o quanto antes.
Uma compilação reproduzível, a propósito explica Wheeler, é aquela que sempre produz as mesmas saídas dadas as mesmas entradas para que os resultados da compilação possam ser verificados. Uma compilação reproduzível verificada é um processo em que organizações independentes produzem uma compilação a partir do código-fonte e verifique se os resultados construídos vêm do código-fonte reivindicado.
Os desenvolvedores fazem esse rastreio de programas em um SBOM usando o formato Software Package Data Exchange (SPDX) da Linux Foundation. Depois disso, como garantia é preciso usar o Codenotary Community Attestation Service e Tidelift Catalogs para autenticar e verificar o SBOM.
Tudo isso é fácil de dizer. Fazendo difícil. Em 2022, praticamente todos os desenvolvedores de código aberto gastarão muito tempo verificando se há problemas no código e, em seguida, criando SBOMs baseados em SPDX. Os usuários, preocupados com desastres do tipo Solarwind e problemas de segurança do log4j, estarão exigindo isso.
Linguagem de programação Rust para proteção
Esse processo é bem complexo. Até mesmo a linguagem de programação Rust vem sendo empregada para dar mais robustez à segurança no Linux. Segundo especialistas, a linguagem Rust é muito mais segura que a C, especialmente quando lida com erros de memória. Um dos principais defensores desta mudança é o desenvolvedor de nuvem da Microsoft, Ryan Levick. Essa preocupação tem uma razão de ser. Nada menos que dois terços das falhas de segurança do kernel Linux estão relacionados a problemas de segurança de memória, especialmente por causa das linguagens C e C ++.
Portanto, a solução é reescrever o Linux em Rust. Isso não deve ocorrer imediatamente, mas é esperado até o ano de 2030. Assim, haverá a troca gradativa pelo Rust nos próximos anos.
Via ZDNet
