Quando software não é um “suprimento”

Nota do editor: O artigo de opinião a seguir, escrito por Daniel Appelquist, diretor de Estratégia de Open Source e Padrões Abertos da Snyk, examina a origem do termo “segurança da cadeia de suprimentos” e questiona se ele se encaixa no processo atual de desenvolvimento de software open source.

Fui inspirado a escrever este texto depois de ler uma publicação de Thomas Depierre no Mastodon:

A publicação aborda algo que tem me preocupado ultimamente. Quando o assunto é segurança de software, passamos muito tempo falando sobre a cadeia de suprimentos de software e conceitos relacionados, como a lista de materiais de software (SBOM). Essa metáfora vem do vocabulário industrial. Quem está acostumado a falar sobre economias e processos de fabricação conhece a ideia de cadeia de suprimentos. Por isso, é compreensível que tantas pessoas do setor tenham adotado essa metáfora ao falar de software — especialmente de software open source, com seu conjunto de dependências aninhadas. É uma forma resumida de explicar o desenvolvimento moderno de software a quem talvez não entenda conceitos como dependências.

No entanto, como muitas metáforas úteis, ela não é exata e só pode ser levada até certo ponto. A metáfora da cadeia de suprimentos pretende abranger não apenas o mantenedor, mas todo o ecossistema e tudo o que há entre ele e a inclusão de uma biblioteca em um projeto open source. Por exemplo, o registro do npm é uma fonte de “suprimentos”, enquanto o marketplace do GitHub Actions é outra.

Algumas pessoas gostam de tratar o mundo open source como uma comunidade única e coesa. Na realidade, o open source é bastante fragmentado. Há um lado mais corporativo, às vezes chamado de “complexo industrial do open source”, para o qual a terminologia da cadeia de suprimentos seria totalmente apropriada. No outro extremo está o movimento do software livre, que provavelmente consideraria a ideia de “cadeia de suprimentos de software” incompatível com sua forma de pensar. E há um amplo espectro entre esses dois extremos.

Em sua publicação, Thomas aponta, com razão, que as dependências de software open source não implicam nenhum acordo real com fornecedores. Nesse sentido, quem desenvolve OSS não é fornecedor de projetos que dependem de seu trabalho. O uso da metáfora da “cadeia de suprimentos” pode gerar mal-entendidos — como quando mantenedores de projetos open source recebem notificações legais ou cartas de empresas. Foi exatamente isso que aconteceu durante o incidente do Log4j. Daniel Stenberg, desenvolvedor open source conhecido por seu trabalho fundamental no projeto Curl, recebeu cartas de uma equipe de compras corporativa (bem-intencionada) sobre o projeto Curl. A equipe o tratou como fornecedor e o pressionou a fornecer, dentro de um prazo rígido, dados sobre o uso do Log4j no Curl. Esse tipo de comunicação pode ser apropriado em uma relação formal com um fornecedor, definida por contrato e acordo de nível de serviço. Mas não é apropriado — de forma alguma — no contexto do open source.

Acho que a terminologia e o modelo mental da cadeia de suprimentos de software ainda são muito úteis, especialmente na comunicação com formuladores de políticas e outros tomadores de decisão que não conhecem as dependências de software nem como funciona o open source. No entanto, essa metáfora só vai até certo ponto. Ao usá-la, também devemos ter em mente que as dependências open source não representam um acordo com fornecedores e, mais importante, que existe toda uma comunidade de pessoas que desenvolvem software open source e não se veem dessa forma. O complexo da segurança de software precisa ser inclusivo — acolhendo também pessoas e comunidades que talvez não se sintam tão à vontade com a ideia de “cadeia de suprimentos” — se quisermos elevar o nível da segurança de software em todo o setor.

Então, como podemos lidar com esse problema? Acho que deveríamos considerar o uso de uma terminologia um pouco diferente em alguns contextos. O termo cadeia de dependências de software talvez seja mais adequado quando estamos falando da comunidade geral de desenvolvedores open source. Outra opção é nós, como setor, explicarmos com muita clareza aos desenvolvedores open source o que queremos dizer — e o que não queremos dizer — com cadeia de suprimentos de software.