Conteúdo
Prioridades linux em 2022: O Linux está em todo lugar. É o que todas as nuvens, até mesmo o Microsoft Azure, executam . É o que faz todos os 500 dos 500 melhores supercomputadores funcionarem.
Caramba, até mesmo o Linux para desktop está crescendo, se você pode acreditar no Pornhub, que afirma que os usuários do Linux cresceram 28% , enquanto os usuários do Windows diminuíram 3%.
O software de código aberto também 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”.
Pensando em bancos de dados, a carne e batatas do software empresarial, o Gartner prevê que mais de 70% dos novos aplicativos internos serão desenvolvidos em um banco de dados de código aberto.
Simultaneamente, 50% das instâncias de banco de dados relacional proprietário existentes terão sido convertidas ou estão sendo convertidas em DBMSs de código aberto.
Vou comprar esses números. Tenho seguido Linux e software de código aberto desde o primeiro dia. Onde quer que eu vá e todas as pessoas com quem falo reconhecem que a dupla executa o universo do software.
Mas com grande poder também vêm grandes responsabilidades, como o Homem-Aranha sabe. E, como muitos desenvolvedores descobriram recentemente quando várias vulnerabilidades de segurança com a biblioteca de código-fonte aberto log4j2 do Apache Java foram descobertas, também vêm grandes dores de cabeça.
Segurança e vulnerabilidade
Com isso, a prioridades linux em 2022 é os problemas do log4j2 que são os piores possíveis. Pela escala do National Vulnerability Database (NVD), é classificado como 10,0 CVSSv3, o que é perfeitamente terrível.
Seu verdadeiro problema não é tanto com o código aberto em si. Não há nada de mágico na metodologia e segurança de código aberto. Erros de segurança ainda podem inserir o código. A lei de Linus é que, com olhos suficientes, todos os insetos são superficiais. Mas, se não houver desenvolvedores suficientes procurando, as vulnerabilidades de segurança ainda passarão despercebidas.
Como o que agora estou chamando de lei de Schneier, “A segurança é um processo, não um produto “, indica que é necessária 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) .
O resultado? Você pode estar usando uma versão vulnerável do log4j e não saber até que seja explorado.
Como Josh Bressers, vice-presidente de segurança da Anchore explicou recentemente, “Um dos desafios que a vulnerabilidade do log4j apresenta é realmente encontrá-la.
Aplicativos Java e dependências geralmente estão em algum tipo de formato de pacote 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 ajudá-lo a identificar bibliotecas log4j defeituosas em uso. Mas, eles não são perfeitos.
Por trás da bagunça do log4j está outro problema: “Como você sabe quais componentes de código aberto seu software está usando?” Por exemplo, log4j2 está em uso desde 2014.
Você não pode esperar que alguém se lembre se usou aquela primeira versão em algum programa que você ainda usa hoje.
A resposta é aquela que a comunidade de código aberto começou a levar a sério nos últimos anos: a criação de listas de materiais de software (SBOM).
Entendem o motivo da prioridades linux em 2022 ser com segurança?
Um SBOM especifica exatamente quais bibliotecas de software, rotinas e outros códigos foram usados em qualquer programa. Armado com isso, você pode examinar quais versões de componentes são usadas em seu programa.
Como David A. Wheeler, Diretor de Segurança da Cadeia de Abastecimento de Código Aberto da Linux Foundation , explicou, usando SBOMs e compilações reproduzíveis verificadas , você pode ter certeza de saber o que está em seus programas.
Dessa forma, se uma falha de segurança for encontrada em um componente, você pode simplesmente corrigi-lo, em vez de pesquisar como um maníaco por qualquer código de problema possível antes de poder corrigi-lo.
“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”.
Para fazer isso, você e seus desenvolvedores precisam rastrear seus programas em um SBOM usando o formato Software Package Data Exchange (SPDX) da Linux Foundation . Em seguida, para garantir ainda mais que seu código é realmente o que afirma ser, você precisa autenticar e verificar seu SBOM com serviços como o Codenotary Community Attestation Service e Tidelift Catalogs.
Breve futuro e muito trabalho pela frente
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.
Ao mesmo tempo, os desenvolvedores Linux estão trabalhando para proteger ainda mais o sistema operacional, tornando o Rust Linux a segunda linguagem . Por quê? Porque, ao contrário do C, a linguagem principal do Linux, o Rust é muito mais seguro.
Especificamente, Rust é muito mais seguro do que C no tratamento de erros de memória.
Como Ryan Levick, principal defensor do desenvolvedor de nuvem da Microsoft, explicou: “Rust é completamente seguro para a memória “. Isso é um grande negócio, pois, como os desenvolvedores do kernel do Linux Alex Gaynor e Geoffrey Thomas apontaram no Linux Security Summit 2019, quase dois terços das falhas de segurança do kernel do Linux vêm de problemas de segurança de memória. E de onde vêm isso? Problemas inerentes com C e C ++.
Agora o Linux será reescrito em Rust. Pelo menos não nesta década, verifique comigo novamente nos anos 2030, mas muitos drivers Linux e outros códigos serão escritos daqui para frente em Rust.
Conclusão prioridades linux em 2022
Como Linus Torvalds me disse enquanto “de forma alguma ‘pressiona’ pela Ferrugem”, ele está “aberto a isso, considerando as vantagens prometidas e evitando algumas armadilhas de segurança. Mesmo assim, ele concluiu:” Também sei que às vezes as promessas não dão certo”.
Vamos ver como tudo funciona. Não importa como vão as especificações, uma coisa eu sei com certeza. Veremos a proteção de código se tornar o principal problema para desenvolvedores Linux e de código aberto em 2022. Por isso as prioridades linux em 2022 é na segurança. Ambos se tornaram muito importantes para que possam seguir outro caminho.
Leia também: Novos recursos do Windows Server 2022
