0 
0 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, já que mesmo software proprietário depende de bibliotecas de código aberto. O relatório “State of Open” de 2022 da OpenUK descobriu que 89% das empresas estavam confiando em software de código aberto, mas nem todas são claras sobre os detalhes do software em que confiam.
As empresas estão exigindo cada vez mais informações sobre seus softwares de operação crítica. As empresas responsáveis estão se interessando detalhadamente por sua cadeia de suprimentos de software e criando uma lista de materiais de software (SBOM) para cada aplicativo. Esse nível de informação é crucial para que, quando forem identificadas falhas de segurança em seus softwares, eles possam ter certeza imediatamente de quais softwares e versões estão em uso e quais sistemas são afetados. Conhecimento é poder nessas situações!
Dependência de voluntários
No final de 2021, uma vulnerabilidade de segurança chamada Log4Shell foi identificada em uma estrutura de log Java amplamente usada, Log4j. Como esta é uma biblioteca de código aberto amplamente usada, a vulnerabilidade foi bem divulgada e as correções eram esperadas. No entanto, os mantenedores do projeto eram voluntários . Eles tinham empregos diários 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 essa vulnerabilidade sozinha tenha afetado 93% dos ambientes de nuvem corporativa.
Na época, houve alguma imprensa negativa sobre o código aberto, mas a verdade é que, se esse fosse um componente de código fechado, a vulnerabilidade talvez nunca fosse 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 outros. Então, sim, os mantenedores não estavam de plantão para problemas de segurança em seu projeto voluntário. A grande questão, então, é: como chegamos a uma situação em que grandes empresas dependiam de software que era responsabilidade de alguém que faz outra coisa para pagar suas contas?
A negligência de dependências de software é um negócio arriscado, qualquer que seja a licença do software, mas quando é de código aberto e muito usado, torna-se especialmente perigoso. Ficar com a história de uma vulnerabilidade; o problema existia na base de código há anos, mas não foi detectado. A ferramenta que foi tão amplamente utilizada não foi, de fato, tão amplamente suportada – e o que aconteceu a seguir é história .
Essa história é repetida várias vezes, em tantos negócios 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 eles têm as informações em mãos. Para organizações que fornecem software para outras, a expectativa de fornecer o SBOM junto com o código é cada vez mais a norma.
Conheça as dependências para avaliar o risco
Trazer o 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 respondidos e houve algum lançamento recentemente? Ser capaz de ver os mantenedores e a atividade do projeto para cada projeto fornece uma boa visão da saúde do projeto.
As empresas podem fazer sua parte para reduzir os riscos apoiando os projetos dos quais dependem. Alguns projetos aceitam patrocínio diretamente por meio do esquema de patrocinadores do GitHub, outros podem apreciar ofertas de hospedagem ou uma auditoria de segurança. Todo projeto de código aberto aprecia contribuições. Se sua empresa tivesse criado essa biblioteca por conta própria, os engenheiros da empresa teriam que corrigir todos os bugs por conta própria.
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 significa menos esforço e, como resultado, leva a uma melhor qualidade. Uma das coisas mais impactantes que as empresas podem fazer é usar um pouco de seus recursos de engenharia e contribuir para correções de bugs ou recursos para projetosque são tão essenciais para os negócios.
Manter seus próprios engenheiros envolvidos em um projeto tem muitos benefícios. Eles o conhecem e podem ficar de olho em novos recursos ou quando uma nova versão estiver disponível. Fundamentalmente, o negócio tem uma visão da saúde e do status do projeto dependente e faz parte do que o mantém saudável, reduzindo o risco para o negócio de um problema com uma dependência. Várias organizações, incluindo a Aiven, têm um OSPO (open source program office), com funcionários dedicados a contribuir ou até mesmo manter os projetos utilizados pela organização. Esses departamentos geralmente 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 dar suporte ao código aberto. O OpenSSF (Open Source Security Foundation) trabalha para melhorar a segurança dos projetos de código aberto e é financiado pelas organizações que dependem desses projetos. Também publica excelentes recursos de aprendizado para que as empresas possam se informar sobre os riscos do software que usam. Outra organização semelhante é a Tidelift , que faz parceria com mantenedores para garantir que certos requisitos básicos sejam atendidos, novamente financiados pelas organizações. A Tidelift também fornece ferramentas e educação para ajudar as empresas a gerenciar sua cadeia de suprimentos de software e adotar as melhores práticas nessa á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 as alternativas proprietárias.
Esta é uma jogada inteligente, mas uma jogada ainda mais inteligente é ter um conhecimento claro da cadeia de suprimentos de software e suas dependências. Quando surge um problema, depender de projetos saudáveis e ter os detalhes de seu software disponíveis ajuda todas as organizações. Se todas as organizações fizerem isso, o risco de eventos como a vulnerabilidade do Log4Shell será reduzido.
FONTE: DARK READING