Uma nova esperança para segurança de software

Por Matt Asay

Colaborador, InfoWorld |

A vulnerabilidade Log4j em dezembro de 2021 destacou a cadeia de fornecimento de software como uma área de segurança extremamente negligenciada. Revelou o quão interconectados estão nossos artefatos de software e como nossos sistemas são tão seguros quanto seus elos mais fracos. Também reforçou a ideia de que podemos pensar que a segurança é algo que podemos comprar, mas na verdade trata-se de como funcionamos como equipas de desenvolvimento.

Desde então, temos corrido para melhorar.

Talvez o mais notável seja o fato de o projeto Sigstore, de código aberto do Google, ter se tornado o método de assinatura de fato para artefatos de software, adotado por todos os principais ecossistemas de linguagens, incluindo Java, Python, Node, Ruby e muito mais. Tornou-se um dos projetos de segurança de código aberto mais rapidamente adotados na história e deu aos desenvolvedores um “selo de cera” de autenticidade para determinar as origens e procedência de seus blocos de construção de software.

Então, já chegamos?

Na verdade. Ainda não. O conceito de lista de materiais de software (SBOM) introduzido pelo decreto da Casa Branca em maio de 2021 continua distante. Este conceito de língua franca para os desenvolvedores compartilharem listas de ingredientes em pacotes de software tem vários formatos emergentes (SPDX, CycloneDX), o que complica as coisas. Pior ainda, não está claro como os SBOMs realmente se encaixariam nos fluxos de trabalho dos desenvolvedores e quais vantagens específicas um desenvolvedor obteria no processo.

O que está começando a reunir tudo isso – e criar mais urgência para criar uma estratégia coesa em torno da assinatura de software, SBOMs e fluxo de trabalho do desenvolvedor – é a regulamentação, que exigiria uma propriedade mais rigorosa da integridade da segurança do software.

Em abril, a Agência de Infraestrutura e Cibersegurança (CISA) publicou um pedido de comentários sobre um recém-proposto Formulário de Atestado de Desenvolvimento de Software Seguro que colocará sobre os CEOs de empresas de software o ônus de atestar que seu software foi construído em ambientes seguros e que foram feitos esforços razoáveis ​​e de boa-fé para manter cadeias de fornecimento de código-fonte confiáveis.

O que é considerado “razoável”?

Até agora, os esforços “razoáveis” parecem ser as diretrizes estabelecidas nos Requisitos de verificação de vulnerabilidades para contêineres do FedRAMP e na Estrutura de desenvolvimento seguro de software do Instituto Nacional de Padrões e Tecnologia. Mas a interpretação muito mais matizada e lida nas entrelinhas dos novos requisitos de autocertificação está nas cláusulas que cobrem o código de terceiros incorporado ao software. Em suma, os fornecedores de software serão responsabilizados pelo código aberto popular, não financiado e não mantido, que utilizam nas suas cadeias de abastecimento.

Espere o que? Responsável por algum código aleatório do mantenedor do projeto? Aparentemente, sim. Isso é “razoável”?

Essa vertiginosa variedade de considerações para os CISOs se tornou o alvo de uma série de memes no Twitter:

Esta é uma verificação um tanto chocante, se necessário, da adoção irrestrita do código aberto. Não estou sugerindo que as empresas não devam usar código aberto, muito pelo contrário. Estou lembrando que não existe almoço grátis, inclusive quando se trata de software gratuito (e de código aberto). Alguém precisa pagar para manter as luzes acesas para os mantenedores, e alguém precisa ajudar os desenvolvedores a entender todo esse software de código aberto de entrada.

Chainguard pode ser alguém assim.

Chainguard é uma empresa liderada por ex-Googlers por trás do projeto Sigstore. Ele está tentando reunir tudo em um conjunto de ferramentas coeso para desenvolvedores. Os esforços iniciais da startup se concentraram em etapas para bloquear o processo de construção e tornar recursos como assinaturas, proveniência e SBOMs nativos das cadeias de fornecimento de software e do processo de construção de software. No ano passado, com Wolfi, eles introduziram a primeira (des)distribuição comunitária de Linux construída especificamente em torno dos primitivos de segurança da cadeia de suprimentos. Eles também lançaram Chainguard Images, que são imagens base para binários independentes, aplicativos como nginx e ferramentas de desenvolvimento como compiladores Go e C.