0
0
A falta de visibilidade na cadeia de suprimentos de software cria um ciclo insustentável de descoberta de vulnerabilidades e fraquezas em software e sistemas de TI, sobrecarregando as organizações, de acordo com Lineaje.
Diversidade e complexidade da comunidade de código aberto
O Lineaje Data Labs analisou 41.989 componentes de código aberto incorporados nos 44 principais projetos populares da Apache Software Foundation em suas últimas três versões. A análise revelou que 68% das dependências estão em projetos de código aberto não-Apache Software Foundation.
Essas dependências tornam até mesmo a integridade e o risco inerente da Apache Software Foundation tão fortes quanto o componente mais fraco que ela incorpora. Com as dependências diretas representando apenas 10%, os 90% restantes são dependências transitivas, que não são facilmente visíveis para os desenvolvedores que selecionam esses pacotes. Isso cria uma cadeia de suprimentos de software opaca e profunda, invisível para os desenvolvedores.
“É fascinante notar que, embora o Apache seja um grande contribuinte para o software de código aberto, uma boa parte do software em que se baseia é a Apache Software Foundation. Isso destaca a incrível diversidade e complexidade da comunidade de código aberto”, disse Manish Gaur, chefe de segurança de produtos da VMware, depois de analisar o relatório de pesquisa.
Escolhendo dependências com base em sua popularidade
Risco inerente extremamente alto – 82% dos componentes são inerentemente arriscados devido a vulnerabilidades, problemas de segurança, qualidade do código ou preocupações de manutenção.
A popularidade do software não indica qualidade – Assim, escolher dependências com base em sua popularidade não é uma abordagem confiável de mitigação de riscos. O eCharts da Apache Software Foundation é seu pacote mais popular e também é um dos mais arriscados, por exemplo.
A miragem de corrigir vulnerabilidades – Enquanto as organizações se afogam em um mar de patches que devem aplicar, a pesquisa revela que 64,2% de todas as vulnerabilidades ainda não têm correções disponíveis – então elas não podem ser corrigidas.
Ao mesmo tempo, devido à profunda natureza transitiva das dependências, outros 25,8% de todas as vulnerabilidades não são corrigíveis pela organização que implanta ou inclui software de código aberto. Efetivamente, a aplicação completa de patches – se alcançada – aborda apenas cerca de 10% da exposição à vulnerabilidade de uma organização.
Detecção de adulterações vitais para manter a integridade do software
É crucial notar que o risco mais significativo não está nas vulnerabilidades que não são corrigidas, mas naquelas para as quais não existem correções. Essas vulnerabilidades continuam a existir e representam uma ameaça persistente, independentemente de outros patches aplicados.
A capacidade de detectar adulteração da cadeia de fornecimento de software está diretamente ligada à integridade do software. Das dezenas de milhares de projetos de código aberto decompostos pelo Lineaje Data Labs, os resultados mostraram:
- Componentes desconhecidos – Embora a maioria dos softwares avaliados tivesse componentes atestáveis de alta integridade, nossa pesquisa revela que cerca de 3% de todos os componentes não tinham origem conhecida. Estes estão profundamente incorporados no software Apache Software Foundation, e sua origem e mecanismos de atualização são opacos.
- Componentes de origem duvidosos – 5,3% dos componentes falharam em uma verificação básica de integridade de que o pacote publicado pelos desenvolvedores correspondia ao código-fonte ao qual afirmava estar associado. Esse tipo de verificação de integridade teria sinalizado tanto o recente comprometimento do 3CX quanto o comprometimento da SolarWinds.
“É imperativo que as organizações de hoje entendam que o software de código aberto tem riscos e é inviolável, mesmo que seja muito popular ou fornecido por uma marca estabelecida”, disse o CEO da Lineaje, Javed Hasan.
“Com mais software sendo montado do que construído, tornou-se mais importante do que nunca ter ferramentas formais para descobrir o DNA do software. Os desenvolvedores não têm visão de raios-X para ver dentro de um componente de software que eles incluem, nem são especialistas em segurança de seletores de código aberto. Devemos usar ferramentas de gerenciamento da cadeia de suprimentos de software, como o SBOM360, para avaliar continuamente o risco dinâmico e inerente e a integridade desses componentes de software que são construídos à esquerda do turno à esquerda”, concluiu Hasan.
FONTE: HELPNET SECURITY