Como lidar com as ameaças à cadeia de suprimentos de código aberto:

Os patches do php2shell (CVE-2026-109618 e CVE-2026-109619) para o PHP em fim de vida (EOL) já estão disponíveis. Como as respostas do atendimento de vendas estão mais demoradas do que o normal devido à alta demanda, a maneira mais rápida de obter os pacotes corrigidos é adquirir o ELS para Runtimes on-line (abre em uma nova aba). Leia as perguntas frequentes sobre os patches

Vá direto para um resumo gerado por IA desta postagem do blog

  • Resuma esta postagem com o Perplexity
  • Resuma esta postagem com o Gemini

No mundo dos negócios atual, as empresas estão empenhadas em criar softwares mais rapidamente do que nunca. Os desenvolvedores estão sob imensa pressão para entregar produtos aos clientes rapidamente. Para acelerar esse processo, eles costumam recorrer a “blocos de construção” pré-fabricados – os componentes de código aberto. Isso significa que o software moderno é frequentemente montado a partir de peças existentes, em vez de ser construído inteiramente do zero. As empresas costumam combinar vários componentes de código aberto para criar um único produto, personalizando-o com seu código exclusivo conforme necessário, e é assim que concluem o trabalho. 

De acordo com Forrester, o uso de código aberto no desenvolvimento de software cresceu significativamente, passando de 36% em 2016 para 78% em 2021. E continua ganhando popularidade. Embora o uso dessas soluções prontas torne o processo mais eficiente, ele também traz vulnerabilidades em potencial. Se os adversários conseguirem comprometer essas bibliotecas integradas, eles poderiam, potencialmente, controlar todo o processo de entrega de software, colocando em risco o projeto como um todo. Isso é chamado de ameaça à cadeia de suprimentos. 

Vamos conversar sobre a gravidade desse problema e como torná-lo mais seguro.

 

Por que os hackers têm como alvo o código aberto? 

 

Bem, os projetos de código aberto geralmente são criados por grupos de pessoas que realmente amam o que fazem – desenvolvedores que trabalham juntos em algo que lhes interessa. O software de código aberto costuma ser distribuído gratuitamente e pode ser usado em diferentes tipos de sistemas. As empresas têm a liberdade de utilizá-lo e adaptá-lo aos seus produtos. Como esses projetos envolvem muitas pessoas trabalhando juntas, às vezes pessoas mal-intencionadas podem usá-los para fins ilícitos.

Os repositórios de projetos de código aberto frequentemente convidam desenvolvedores a adicionar atualizações e novos recursos, o que significa que qualquer usuário, inclusive agentes mal-intencionados, pode introduzir seu próprio código na plataforma. Muitas comunidades flexibilizam os controles sobre novos membros assim que a confiança é estabelecida. Consequentemente, um invasor pode, inicialmente, contribuir de maneira construtiva e, posteriormente, introduzir código malicioso sem ser percebido. 

Os hackers costumam recorrer a ameaças à cadeia de suprimentos de código aberto porque isso é mais fácil do que atacar diretamente alvos específicos, como servidores bancários, e tentar contornar suas medidas de segurança. Para invadir o sistema de computadores de um banco, um invasor pode explorar uma vulnerabilidade em uma biblioteca de código aberto utilizada pelo banco. Isso permite que ele entre pela “porta dos fundos” sem muita dificuldade. Mesmo que o banco identifique o ataque prontamente e tome medidas, isso ainda pode afetar outras empresas que utilizam a mesma biblioteca, levando a um ataque em grande escala à cadeia de suprimentos.

 

Ameaças à cadeia de suprimentos de software

 

Os ataques à segurança da cadeia de suprimentos de software estão causando grande repercussão no ecossistema de software de código aberto, ganhando cada vez mais atenção e provocando perturbações cada vez maiores. Os pesquisadores da empresa de segurança de aplicativos Synopsys investigaram e descobriram pelo menos uma vulnerabilidade conhecida de código aberto em 84% das bases de código. De acordo com o 9º relatório anual da Sonatype “State of the Software Supply Chain” da Sonatypeda Sonatype, houve um aumento de três vezes no número de pacotes de código aberto maliciosos em comparação com o relatório do ano anterior.

Tudo isso mostra que a cadeia de suprimentos de software se tornou um dos vetores de crescimento mais rápido para que agentes mal-intencionados executem códigos maliciosos. Vamos dar uma olhada rápida em algumas ferramentas que podem ajudar a manter o software seguro durante seu desenvolvimento. 

Ferramentas de Análise de Composição de Software (SCA)

 

As ferramentas de SCA, utilizando um arquivo de montagem de aplicativo, analisam automaticamente a base de código (incluindo os artefatos associados), geram uma lista das bibliotecas e componentes de terceiros utilizados no software e procuram vulnerabilidades. Além disso, esses scanners podem verificar se os elementos de código aberto estão em conformidade com os requisitos de licenciamento.

Basicamente, essas ferramentas verificam se há uma versão mais recente de um componente de software e se há problemas conhecidos relacionados a ele que tenham sido divulgados.

 

Saiba como identificar vulnerabilidades da cadeia de suprimentos preventivamente.

 

Lista de Componentes de Software (SBOM)

 

SBOM é uma lista de elementos de código aberto e de terceiros utilizados na base de código do software. Ela contém informações técnicas sobre todos os componentes e suas relações entre si. A SBOM também pode incluir informações resumidas sobre o nome do componente, versão, licença, vulnerabilidades, dependências transitivas e assim por diante.

Os programas de SBOM ajudam a identificar e mitigar vulnerabilidades por meio do acompanhamento dos componentes de código, do gerenciamento de licenças de software e da otimização do ciclo de vida do desenvolvimento de software (SDLC). A primeira etapa da criação de um programa envolve a implementação de ferramentas de SCA e outros analisadores que possam ser integrados de forma transparente ao pipeline de CI/CD. 

 

Estrutura de Níveis da Cadeia de Suprimentos para Artefatos de Software (SLSA)

 

Essa estrutura foi lançada pelo Google em colaboração com a Open Source Security Foundation (OpenSSF). O SLSA contém uma lista de padrões e diretrizes para proteger contra acessos não autorizados e garantir a integridade dos artefatos de software nas cadeias de suprimentos. O SLSA mostra claramente quais partes da cadeia de suprimentos estão suscetíveis a vulnerabilidades.

 

Fonte: https://slsa.dev/spec/v1.0/threats-overview 

 

Antes de utilizar qualquer dependência, devemos garantir que ela provenha de uma fonte confiável. Para ser considerada confiável, uma fonte deve confirmar que sua biblioteca atende a todos os requisitos estabelecidos e não contém nenhum código malicioso que possa prejudicar seus usuários. Idealmente, deveríamos dispor do que se denomina “proveniência” — informações adicionais sobre a origem de um artefato, que podem ser utilizadas para rastrear, desde o início, quem, onde, quando e como algo foi criado.

Para seguir esse princípio, o SLSA introduz quatro níveis de segurança: desde o primeiro nível, que implica na ausência total de quaisquer garantias, até o quarto nível, que oferece o mais alto grau de confiança e segurança.

Nível Descrição
0 Sem garantias
1 Documentação do processo de compilação
2 Resistência à adulteração do serviço de compilação
3 Resistência adicional a ameaças específicas
4 Os mais altos níveis de confiança e credibilidade

 

Cada nível contém requisitos relativos ao código-fonte (Source), ao processo de compilação (Build), bem como informações adicionais sobre a origem dos artefatos (Provenance). 

 

Repositório confiável de componentes de código aberto verificados

 

Contar com um repositório confiável de componentes de código aberto, que são constantemente atualizados, testados e verificados quanto a vulnerabilidades, pode reduzir significativamente a carga de trabalho dos desenvolvedores. Ao garantir que você sempre tenha as versões corretas das bibliotecas disponíveis, é possível mitigar os riscos associados às dependências.

É isso que o SecureChain para Java oferece. O processo seguro de processo de verificação do SecureChain permite que você aproveite as melhores e mais seguras bibliotecas comumente utilizadas para suas aplicações. Isso reduz o tempo gasto com atualizações manuais e o risco de incorporar uma biblioteca com possíveis vulnerabilidades.

O SecureChain oferece tranquilidade, garantindo que sua cadeia de suprimentos de software esteja segura, o que permite que você se concentre mais na criação e no aprimoramento de seus aplicativos.

 

Uma porta de entrada para os invasores, mas não um beco sem saída 

 

O código aberto pode servir de porta de entrada para que invasores comprometam muitas empresas. Nem todas as organizações conseguem identificar rapidamente as ameaças à cadeia de suprimentos de código aberto. Os invasores ocultam suas ações e utilizam técnicas engenhosas, como explorar vulnerabilidades nas configurações de gerenciamento de pacotes ou invadir repositórios. No entanto, essas ameaças não devem nos levar a evitar completamente o código aberto. Em vez disso, elas incentivam as empresas a escolherem componentes de código aberto com mais cuidado e a aprimorarem suas medidas de segurança.

Resumo
Como lidar com as ameaças à cadeia de suprimentos de código aberto: protegendo seu ecossistema de software
Nome do artigo
Como lidar com as ameaças à cadeia de suprimentos de código aberto: protegendo seu ecossistema de software
Descrição
Saiba como proteger seu ecossistema de software contra ameaças à cadeia de suprimentos de código aberto. Descubra ferramentas e estratégias
Autor
Nome da editora
TuxCare
Logotipo da editora

Junte-se a mais de 4.500 profissionais de Linux e código aberto!

2 vezes por mês. Sem spam.

Índice
Obtenha as respostas sobre segurança de código aberto de que você precisa

Junte-se a mais de 4.500 profissionais de Linux e código aberto!

2 vezes por mês. Sem spam.