A evolução da segurança em OSPOs: o modelo de Kübler-Ross aplicado ao código aberto

O que há em um OSPO? Os Escritórios de Programas de Código Aberto estão surgindo por toda parte, em reconhecimento à realidade: o software de código aberto — e eu diria que os padrões abertos também — desempenha um papel enorme na criação e manutenção do software que cada vez mais move o planeta. O relatório The Evolution of the Open Source Program Office (OSPO) da Linux Foundation descreve cinco estágios de desenvolvimento de um OSPO:

• Estágio 0: Adoção ad hoc de código aberto

• Estágio 1: Garantia de conformidade com software de código aberto, inventário e capacitação de desenvolvedores

• Estágio 2: Promoção do uso de software de código aberto e participação no ecossistema

• Estágio 3: Hospedagem de projetos de código aberto e crescimento de comunidades

• Estágio 4: Atuação como parceiro estratégico na tomada de decisões

Mas, quando o assunto é segurança, pode ser mais esclarecedor pensar em cinco estágios diferentes (à la modelo de Kübler-Ross):

• Negação: As organizações negam o quanto dependem do código aberto. Talvez achem que sabem, mas, quando começam a pensar no assunto, percebem o quanto estão apoiadas em uma variedade de códigos e ferramentas de código aberto, especialmente no pipeline de build. Confira também o Relatório de segurança do Snyk Open Source de 2022.

• Raiva: Como não prestaram atenção, as organizações nem sabem quanto código aberto estão usando. Essa raiva (esperamos) as leva a uma busca intensa por conhecimento e a contabilizar os projetos de código aberto, além de perceberem melhor o quanto o software de código aberto é central para a organização.

• Negociação: É quando as organizações começam a dialogar e a se aproximar da comunidade de software de código aberto, muitas vezes aproveitando o conhecimento adquirido por meio de uma participação ad hoc e começando a direcionar essa participação para uma estratégia coerente.

• Depressão: Nesta etapa, a situação começa a ficar séria, à medida que outras áreas da organização percebem o valor do OSPO. O que deveria ser ótimo, certo? Infelizmente, é também nesta etapa que fica claro que as dependências de software de código aberto representam um risco para toda a organização — especialmente quando se consideram as vulnerabilidades de segurança.

• Aceitação: Aceitar plenamente que vivemos em um ecossistema de código aberto significa aprender a exercer um papel de liderança nele e reconhecer que o OSPO deve ser não apenas um centro de excelência em ecossistemas abertos, mas também um centro de excelência em segurança.

Tudo bem, a comparação acima é um pouco forçada. O ponto é que o código aberto veio para ficar. Ele desempenha um papel muito importante na criação e manutenção da grande maioria dos softwares — especialmente daqueles que todos usamos no dia a dia. Código aberto significa abrir mão de parte do controle em favor da comunidade, em troca de mais qualidade e menor custo operacional. As organizações que aprenderem a aceitar esse fato e começarem a exercer um papel de liderança nessa comunidade se tornarão líderes de mercado. E a segurança é uma parte fundamental disso.

Então, como os OSPOs podem assumir efetivamente seu papel não só como promotores da abertura, mas também da segurança? Primeiro, trazendo conhecimento especializado em segurança para a equipe do OSPO. Tenha na equipe um especialista em segurança que conheça os desafios da cadeia de suprimentos de software. Participar do grupo de trabalho “End User” da Open Source Security Foundation pode ser uma forma de compartilhar informações em um espaço seguro com outras organizações semelhantes.

Um ótimo ponto de partida são alguns materiais recém-lançados pela Open Source Security Foundation (OpenSSF).

• Guia conciso para desenvolver softwares mais seguros

• Guia conciso para avaliar softwares de código aberto

• Guia de práticas recomendadas para NPM

Todos esses recursos da OpenSSF ajudam a começar a refletir sobre questões complexas relacionadas à segurança do código aberto. Se você está criando um OSPO ou uma função semelhante em uma organização de qualquer porte, certamente vai reconhecer de imediato alguns dos desafios abordados nesses guias. É bem provável que sua organização use npm. Seu código está em sistemas de gerenciamento de código-fonte, como o GitHub. Você usa softwares de código aberto de várias fontes, com diferentes licenças e históricos. Todos esses temas são tratados nos guias, que também incluem links para informações mais detalhadas.

A partir daí, os OSPOs precisam contratar profissionais de segurança ou trazer especialistas para se antecipar a esses desafios. Comece a pensar na lista de materiais de software (SBOM) para os processos de desenvolvimento, build e implantação. Liran Tal tem um ótimo artigo sobre SBOM para ajudar você a começar.

Como observação à parte, é interessante e positivo ver a legislação dos EUA voltada à proteção dos softwares de código aberto usados no desenvolvimento e na operação de serviços governamentais, que prevê a criação de OSPOs em órgãos públicos.

Um brinde a um 2023 seguro (e aberto)