Frank Crane não estava falando sobre código aberto quando disse a famosa frase: “Você pode ser enganado se confiar demais, mas viverá em tormento se não confiar o suficiente”.
Mas essa é uma ótima maneira de resumir a lacuna atual entre o modo como o código aberto é na verdade sendo consumidos, em comparação com os padrões de confiança zero que as empresas estão tentando codificar em suas práticas DevSecOps.
Todos os estudos que vejo sugerem que entre 90% e 98% do software mundial é de código aberto. Todos nós estamos pegando código escrito por outras pessoas – apoiados nos ombros de gigantes – e construindo e modificando todo esse código, confiando implicitamente em cada autor, mantenedor e contribuidor que veio antes de nós.
Antes mesmo de começarmos a escrever nosso código, confiamos que o código-fonte aberto subjacente foi escrito com segurança. Então, quando o usamos, confiamos que os autores não eram maliciosos e que o código não foi adulterado antes de instalá-lo. Isso é o oposto da confiança zero. Isso é máximo confiar.
Vamos dar uma olhada na evolução da distribuição de software e onde novas raízes de confiança precisam ser plantadas para apoiar as próximas décadas de inovação de código aberto.
Software de código aberto é seguro
Nos primeiros dias, os detratores do código aberto suscitaram muito medo, incerteza e dúvidas em torno de sua segurança. O argumento deles era que o código-fonte do software proprietário estava isolado de olhares indiscretos e, portanto, mais seguro do que o código-fonte aberto, cujo código-fonte estava prontamente disponível para qualquer pessoa.
Mas o código aberto provou que existe uma positivo efeito quando você tem transparência do código-fonte. O efeito de rede de muitos olhares sobre o código-fonte revela vulnerabilidades mais rapidamente e cria ciclos de correção muito mais rápidos. Os resultados falam por si: 90% das vulnerabilidades exploradas conhecidas (na lista CVE mantida pela CISA) são software proprietário, apesar de cerca de 97% de todo o software ser de código aberto.
É muito fácil, sempre que há uma grande vulnerabilidade, prejudicar o estado geral da segurança de código aberto. Na verdade, muitas dessas vulnerabilidades de maior perfil mostram o poder da segurança de código aberto. Log4shell, por exemplo, foi o pior cenário para uma vulnerabilidade de OSS em escala e nível de visibilidade – esta foi uma das bibliotecas mais utilizadas em uma das linguagens de programação mais utilizadas. (O Log4j estava até rodando no rover de Marte. Tecnicamente, essa foi a primeira vulnerabilidade intergaláctica de OSS!) A vulnerabilidade do Log4shell era fácil de explorar, incrivelmente difundida e com sérias consequências. Os mantenedores conseguiram corrigi-lo e implementá-lo em questão de dias. Foi uma grande vitória para a resposta de segurança de código aberto no nível do mantenedor, e não um fracasso.
E essa conquista deve ser amplamente reconhecida. Compare esse tempo de divulgação e correção de alguns dias com os programas de divulgação de fornecedores de firmware ou provedores de nuvem que levam 30, 60 ou até 90 dias para implementar correções para algo assim, na melhor das hipóteses. No entanto, as empresas demoraram a responder para tomar as medidas necessárias contra a vulnerabilidade. De acordo com um relatório recente da Veracode, mais de um em cada três, ou 38%, dos aplicativos que executam o Log4j ainda usam versões vulneráveis do programa.
Mas o código aberto requer confiança
Quando você começa a construir seu software, isso é apenas a ponta do iceberg acima da superfície. Você está construindo milhões de linhas de software livre criadas para o bem público, de graça. Isso é possível por causa confiar.
As distribuições Linux – além de lidar com a compilação do código-fonte e evitar que os usuários de OSS tenham que compilar e depurar – devem ser creditadas pelo enorme papel que desempenharam no estabelecimento dessa confiança. Ao usar binários de uma distribuição Linux, você confia nos mantenedores originais que escrevem o código-fonte e a distribuição. São dois grupos diferentes de pessoas. As distribuições Linux entenderam isso e realmente avançaram no estado da arte em segurança de software nas últimas décadas, através de abordagens pioneiras para cadeias de fornecimento de software e estabelecendo métodos rigorosos para verificar os mantenedores de pacotes.
O Debian é um dos mais notáveis na área por sua sofisticação na codificação da confiança dentro da distribuição. O Debian usa o sistema de assinatura de chave PGP, onde somente se mantenedores suficientes assinarem as chaves para eventos de criptografia, eles serão adicionados ao chaveiro do Debian. Essas assinaturas são verificadas conforme novos pacotes são carregados e então a própria distribuição Debian assina novamente todos os pacotes que foram integrados. Então, quando eles são publicados no Debian, os usuários podem verificar essas assinaturas, não importa onde encontrem esses pacotes e garantir que esses pacotes vieram através de uma distribuição Debian de mantenedores em que eles confiam e que os pacotes não foram adulterados no caminho.
É um modelo que funcionou fenomenalmente bem.
E as dependências de OSS superaram os modelos de confiança
Mas hoje, a maior parte do consumo de software ocorre fora das distribuições. Os próprios gerenciadores de pacotes de linguagens de programação – npm (JavaScript), pip (Python), Ruby Gems (Ruby), compositor (PHP) – parecem gerenciadores de pacotes de distribuição Linux, mas funcionam de maneira um pouco diferente. Eles basicamente oferecem curadoria zero – qualquer um pode fazer upload de um pacote e imitar um mantenedor de linguagem. E como você sabe em que está confiando, quando uma única instalação de pacote geralmente instala pacotes de dezenas de outras pessoas aleatórias na Internet?
O Docker multiplicou ainda mais esse problema de confiança transitiva. As imagens Docker são fáceis de construir porque usam os gerenciadores de pacotes existentes dentro delas. Você pode usar uma instalação npm para obter pacotes npm e, em seguida, agrupá-los em uma imagem Docker. Você pode instalar um aplicativo com os gerenciadores de pacotes de qualquer idioma e enviá-lo como uma grande bola TAR. O Docker reconheceu essa lacuna de confiança e, para seu crédito, tentou colmatar isso com algo chamado Verified Builds, que evoluiu para um recurso dentro do Docker Hub.
Esses Docker Verified Builds eram uma forma de os usuários especificarem o script de construção para uma imagem Docker na forma de um arquivo Docker, no repositório de código-fonte. O mantenedor escreve o arquivo Docker, mas então o Docker faz a construção, então o que você vê na imagem é o mesmo código de seus mantenedores originais. O Docker lançou isso há anos e continua a melhorá-lo, então eles merecem um grande elogio.
No entanto, o Docker não é o único player nesta web confiável para software nativo da nuvem; fica mais complicado. Há uma camada acima do Docker que é comumente usada no domínio Kubernetes. Helm permite empacotar várias imagens e configurações do Docker. É um pacote de pacotes.
Portanto, se você instalar o gráfico Helm para Prometheus, por exemplo, provavelmente também obterá várias outras imagens de projetos pessoais aleatórios. Você pode ter certeza de que está obtendo o Prometheus dos mantenedores do Prometheus, porque o hub do artefato mostra que ele veio de um editor verificado, mas o Prometheus geralmente tem dependências que não vêm de editores verificados.
O repositório oficial de gráficos do Helm, mantido pelos criadores originais do Helm, foi uma tentativa curada de codificar a confiança nessas imagens. Ele tinha o potencial de trazer para aplicativos nativos da nuvem o mesmo tipo de curadoria de segurança fornecida pelas distribuições Linux. Mas, infelizmente, provou ser muito difícil de escalar e adotou um modelo mais federado, como os gerenciadores de pacotes de linguagens de programação, onde cada projeto mantém seus próprios gráficos Helm.
Todas essas camadas de dependências transitivas constituem a maior parte do problema de segurança da cadeia de suprimentos de software moderno e uma das áreas mais interessantes para serem exploradas por atores mal-intencionados. Esta é a linha de frente da nova batalha para preservar toda a grande confiança no código aberto que foi construída ao longo das décadas.
Tornando o software seguro desde o início
A distribuição de software é dramaticamente diferente do que era há 20 anos, quando você costumava comprar software embalado em uma loja como CompUSA ou Best Buy. Quando você comprou uma caixa de software, você sabia exatamente o que estava comprando. Você sabia que veio da pessoa que deveria vir e que não havia sido adulterado.
À medida que a distribuição de software passou dos CD-ROMs para a Internet, as distribuições Linux provaram ser surpreendentemente bem-sucedidas em fornecer confiança.
Quando Log4j e SolarWinds mostraram algumas das falhas que novos ataques à cadeia de fornecimento de software estão explorando, as equipes começaram a bloquear sistemas de construção, usando estruturas como SSDF e SLSA, e verificando assinaturas de software produzidas por Sigstore (agora o método de assinatura de software padrão usado por Kubernetes e todos os principais registros de linguagens de programação). Isso é progresso.
Este domínio de segurança de código aberto é complexo. Estamos falando de modelos de confiança de décadas contra 372 milhões de repositórios somente no GitHub!
Ainda há uma grande desconexão entre CVEs conhecidos e desenvolvedores que os reinstalam involuntariamente por meio de dependências transitivas. Ainda existe toda uma classe de vulnerabilidades que residem inteiramente fora das distribuições Linux e, portanto, não são detectadas pelos scanners de segurança. Já é difícil o suficiente para os consumidores de software perceberem quando estão executando pacotes de software maliciosos, e muito menos serem ágeis o suficiente para corrigi-los rapidamente com atualizações quando disponíveis.
Em 2024, veremos as lacunas de segurança da cadeia de fornecimento de software diminuírem entre CVEs, distribuições Linux e pacotes de software. Veremos uma grande redução nos artefatos de software não essenciais fornecidos tanto nas distros quanto nas imagens, e as próprias distros começarão a competir com base na eficiência com que podem enviar correções de vulnerabilidades o mais rápido possível, como Wolfi.
Começaremos a ouvir as equipes de segurança alinharem suas expectativas de segurança da infraestrutura de aplicativos com conceitos de confiança zero e não aceitarão mais um monte de lixo em suas distros e imagens que podem introduzir rachaduras e backdoors para dependências transitivas. Veremos equipes de segurança que desejam se aproximar do kernel com tecnologias como eBPF e Cilium e usar a aplicação de políticas de segurança em tempo de execução que projetos como o Tetragon podem fornecer. E veremos esse bloqueio acelerado por casos de uso de IA que exigem que as empresas confiem em ainda mais estruturas com dependências ainda mais transitivas, incluindo arquiteturas de GPU especializadas e backdoors cada vez mais diferenciadas.
Para que os desenvolvedores continuem a aproveitar a liberdade de escolha de seus componentes OSS favoritos sobre os quais eles constroem, a distribuição de software precisa ser repensada. Precisamos de maneiras mais uniformes de construir, empacotar, assinar e verificar todo o código-fonte que entra nos pacotes em contêineres e a distribuição desses componentes nativos da nuvem, mantendo-os mínimos e seguros por padrão. Eles estão todos no topo da pilha, que é o lugar perfeito para refatorar raízes de confiança que darão suporte às próximas décadas de inovação de código aberto no mundo nativo da nuvem. É hora de uma fonte segura padrão de fato para software de código aberto.
Dan Lorenc é CEO e cofundador da Protetor de corrente. Anteriormente, ele foi engenheiro de software e líder da equipe de segurança de código aberto do Google (GOSST). Ele fundou projetos como Minikube, Skaffold, TektonCD e Sigstore.
–
O New Tech Forum oferece um local para líderes de tecnologia – incluindo fornecedores e outros colaboradores externos – explorarem e discutirem tecnologias empresariais emergentes com profundidade e amplitude sem precedentes. A seleção é subjetiva, baseada na escolha das tecnologias que acreditamos serem importantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não aceita material de marketing para publicação e reserva-se o direito de editar todo o conteúdo contribuído. Envie todos consultas para [email protected].
