Negligenciar desenvolvedores de código aberto coloca a Internet em risco

O software está no centro de todos os negócios modernos e é crucial em todos os aspectos das operações. Quase todas as empresas usarão software de código aberto, conscientemente ou não, uma vez que até mesmo software proprietário depende de bibliotecas de código aberto. OpenUK O relatório “State of Open” de 2022 descobriu que 89% das empresas dependiam de software de código aberto, mas nem todas têm clareza sobre os detalhes do software em que confiam.

As empresas estão cada vez mais exigindo mais informações sobre seus softwares críticos para a operação. As empresas responsáveis ​​estão se interessando detalhadamente por sua cadeia de fornecimento de software e criando uma lista de materiais de software (SBOM) para cada aplicação. Este nível de informação é crucial para que, quando forem identificadas falhas de segurança no seu software, possam ter imediatamente a certeza de quais softwares e versões estão em uso e quais sistemas são afetados. Conhecimento é poder nessas situações!

Confiança em Voluntários

No final de 2021, uma vulnerabilidade de segurança chamada Log4Shell foi identificado em uma estrutura de log Java amplamente utilizada, Log4j. Como esta é uma biblioteca de código aberto amplamente utilizada, a vulnerabilidade foi bem divulgada e correções eram esperadas. No entanto, o mantenedores do projeto eram voluntários. Eles tinham empregos diurnos e não estavam de plantão para correções urgentes de segurança, mesmo que um grande número de sistemas fosse afetado. Estima-se que esta vulnerabilidade por si só tenha afetado 93% dos ambientes de nuvem empresarial.

Na altura, houve alguma imprensa negativa sobre o código aberto, mas a verdade é que se este fosse um componente de código fechado, a vulnerabilidade poderia nunca ter sido conhecida publicamente, deixando as organizações abertas a ataques. A natureza de código aberto da biblioteca significava que ela poderia ser inspecionada, os problemas encontrados e conselhos oferecidos por terceiros. Então, sim, os mantenedores não estavam de plantão por problemas de segurança em seu projeto voluntário. A grande questão, então, é: como chegámos a uma situação em que grandes empresas dependiam de software que era da responsabilidade de alguém que faz outra coisa para pagar as suas contas?

Negligenciar as dependências de software é um negócio arriscado, qualquer que seja a licença do software, mas quando é de código aberto e amplamente utilizado, torna-se especialmente perigoso. Continuar com a história de uma vulnerabilidade; o problema existia na base de código há anos, mas não foi detectado. A ferramenta tão amplamente utilizada não era, na verdade, tão amplamente apoiada — e o que aconteceu depois é história.

Essa história se repete continuamente em tantas empresas que têm dependências críticas, mas não tomam medidas para apoiar os mantenedores ou os próprios projetos. Ter um SBOM para o software usado por uma empresa significa que ela tem as informações em mãos. Para organizações que fornecem software a terceiros, a expectativa de fornecer o SBOM juntamente com o código é cada vez mais a norma.

Conheça as dependências para avaliar o risco

Trazer conhecimento das dependências facilita a avaliação do risco associado a cada uma delas. Esses projetos de código aberto são os mais simples de avaliar: os problemas foram resolvidos e houve algum lançamento recentemente? Ser capaz de ver os mantenedores e as atividades do projeto para cada projeto proporciona uma boa visão sobre a saúde do projeto.

As empresas podem desempenhar o seu papel na redução dos riscos, apoiando os projetos dos quais dependem. Alguns projetos aceitam patrocínio diretamente por meio do esquema GitHub Sponsors, outros podem, em vez disso, aceitar ofertas de hospedagem ou uma auditoria de segurança. Todo projeto de código aberto agradece contribuições. Se a sua empresa tivesse criado essa biblioteca sozinha, os engenheiros da empresa teriam que consertar todos os bugs sozinhos.

O código aberto é mais como um esquema de propriedade compartilhada. Nem todos temos que construir a mesma coisa repetidamente, mas podemos contribuir, o que exige menos esforço e, como resultado, leva a uma melhor qualidade. Uma das coisas mais impactantes que as empresas podem fazer é usar um pouco dos seus recursos de engenharia e contribuir para correções de bugs ou recursos para projetos que são tão essenciais para o negócio.

Manter seus próprios engenheiros envolvidos em um projeto tem muitos benefícios. Eles ficam sabendo e podem ficar de olho em novos recursos ou quando um novo lançamento estiver disponível. Crucialmente, a empresa tem uma visão sobre a saúde e o status do projeto dependente e faz parte do que o mantém saudável, reduzindo o risco para a empresa de um problema com uma dependência. Várias organizações, incluindo a Aiven, possuem um OSPO (escritório de programas de código aberto), com funcionários dedicados a contribuir ou mesmo manter os projetos utilizados pela organização. Esses departamentos muitas vezes contribuem para a presença geral da empresa no ecossistema de código aberto e permitem que outros funcionários se envolvam com o código aberto.

Outra abordagem é apoiar as organizações que existem para apoiar o código aberto. O OpenSSF (Fundação de Segurança de Código Aberto) trabalha para melhorar a segurança de projetos de código aberto e é financiado pelas organizações que dependem desses projetos. Também publica excelentes recursos de aprendizagem para que as empresas possam se informar sobre os riscos do software que utilizam. Outra organização semelhante é Tidelift, que faz parceria com mantenedores para garantir que certos requisitos básicos sejam atendidos, novamente financiado pelas organizações. A Tidelift também fornece ferramentas e educação para ajudar as empresas a gerenciar sua cadeia de fornecimento de software e a adotar as melhores práticas nesta área.

Garantindo um futuro de software mais seguro

As empresas dependem de software, e isso inclui software de código aberto, que é amplamente utilizado e normalmente mais seguro do que alternativas proprietárias.

Esta é uma jogada inteligente, mas ainda mais inteligente é ter um conhecimento claro da cadeia de fornecimento de software e suas dependências. Quando surge um problema, depender de projetos saudáveis ​​e ter os detalhes do seu software disponíveis ajuda todas as organizações. Se todas as organizações fizessem isso, o risco de eventos como a vulnerabilidade Log4Shell seria reduzido.