Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
O software de código aberto tornou-se um componente essencial do ecossistema de desenvolvimento de software. Ele vem sendo amplamente adotado por desenvolvedores em todo o mundo, graças aos seus benefícios — como economia, adaptabilidade e suporte oferecido pela comunidade.
O acesso a componentes de software já existentes permite que as empresas otimizem seus processos de desenvolvimento e lancem seus produtos no mercado com muito mais rapidez. No entanto, com o uso cada vez maior de pacotes de código aberto no desenvolvimento de aplicativos, surgem desafios crescentes de segurança. Esta postagem do blog aborda os desafios relacionados à segurança da cadeia de suprimentos de código aberto e como lidar com eles.
O ponto ideal para os atacantes
À medida que o uso de software de código aberto continua a crescer, os grupos de ataque têm a oportunidade de explorar a cadeia de suprimentos de software para acessar uma ampla gama de alvos que dependem dela.
Os cibercriminosos sabem que muitas organizações não têm conhecimento do software de código aberto utilizado em seus sistemas nem das vulnerabilidades presentes nesses componentes. Em vez de perderem muito tempo tentando invadir o código personalizado de uma organização, os hackers estão usando exploits disponíveis publicamente para atacar uma ampla gama de organizações e identificar sistemas com componentes de código aberto vulneráveis que possam ser explorados.
Além disso, uma das principais razões pelas quais os ataques às cadeias de suprimentos de código aberto são tão bem-sucedidos é a imensa complexidade dos gráficos de dependências.
O Efeito Jenga
Cada pacote de código aberto possui sua própria cadeia de suprimentos exclusiva e pode depender de várias bibliotecas de código aberto de terceiros. Essas bibliotecas de terceiros, por sua vez, costumam depender de outras bibliotecas, resultando em uma cadeia de interdependências altamente complexa.
Considerando que as bibliotecas populares são amplamente utilizadas por muitos pacotes de código aberto, uma única vulnerabilidade em uma delas pode causar estragos em todo o ecossistema. Já vimos isso acontecer muitas vezes: desde uma vulnerabilidade na biblioteca gratuita Log4j até um dos casos mais recentes, em que um desenvolvedor de código aberto introduziu um código defeituoso em seu pacote npm extremamente popular colors.
Fonte: https://xkcd.com/2347/
Não dá para proteger o que não se vê
Em um cenário ideal, as equipes de engenharia manteriam uma documentação abrangente do software de código aberto utilizado na organização — também conhecida como lista de materiais de software. Elas atualizariam essa documentação sempre que uma nova dependência fosse adicionada, permitindo identificar facilmente onde e se uma determinada biblioteca, como o log4j, está sendo utilizada.
Essa documentação também ajudaria a identificar pacotes sem manutenção em tempo hábil, já que eles podem representar riscos adicionais à segurança. No entanto, exige muito trabalho dos desenvolvedores para que documentem os componentes de software de maneira consistente. Ao mesmo tempo, as equipes de segurança em muitas organizações precisam de maior visibilidade sobre as dependências que suas empresas estão utilizando.
Atrasos no prazo de lançamento no mercado
Considerando a complexidade das cadeias de dependências do software de código aberto, manter-se atualizado com todas as correções mais recentes de vulnerabilidades e, ao mesmo tempo, impulsionar a inovação torna-se quase uma missão impossível.
Para garantir a segurança e a conformidade legal, as empresas passaram a implementar ativamente processos formais de aprovação para a adoção de novos componentes de código aberto. Em alguns casos, a aprovação de novos componentes pode levar até um mês ou mais.
Ao mesmo tempo, os gerentes de produto, que precisam equilibrar cuidadosamente seus recursos de desenvolvimento para manter a competitividade, enfrentam dificuldades para priorizar novos recursos em detrimento do número crescente de vulnerabilidades que afetam suas aplicações. Tudo isso pode causar um atraso significativo no desenvolvimento e, por sua vez, no tempo de lançamento no mercado, o que pode ser crítico e, no mínimo, resultar na perda de oportunidades.
O caminho a seguir
Uma das possíveis soluções para os desafios que as organizações enfrentam em relação à segurança da cadeia de suprimentos de código aberto é a prática de gerenciar centralmente um repositório de componentes de código aberto pré-aprovados e continuamente protegidos. Você pode criá-lo por conta própria ou fazer parceria com um fornecedor de confiança que irá criá-lo e gerenciá-lo para você.
O acesso a esse repositório permitirá que você:
- Minimize os riscos de segurança garantindo que suas dependências estejam livres de vulnerabilidades e códigos maliciosos
- Assuma o controle sobre seu gráfico de dependências com uma Lista de Componentes de Software (SBOM) garantida, fornecida para cada pacote
- Cumpra sua política de aplicação de patches e os requisitos regulatórios, estabelecendo SLAs confiáveis para correções de segurança
- Acelere o tempo de lançamento no mercado eliminando processos de aprovação excessivos e reduzindo sua dívida técnica
Um único repositório confiável de pacotes de código aberto verificados permitirá que você continue inovando, ao mesmo tempo em que mantém automaticamente a segurança de suas aplicações. Se você estiver interessado em proteger sua cadeia de suprimentos Java, acesse agora nosso repositório Java gratuito.
