Skip to main content

Relatório de segurança do código aberto 2024: avanço lento e novos desafios para DevSecOps

Escrito por
SOOS Featured

3 de dezembro de 2024

0 minutos de leitura

A confiança é a base da comunidade de código aberto — mas o que acontece quando ela é traída? 

Quando uma vulnerabilidade de backdoor foi descoberta em uma ferramenta de compressão de dados baseada em Linux e amplamente utilizada, ela quase abriu caminho para que agentes maliciosos assumissem o controle de inúmeros computadores no mundo todo. A vulnerabilidade foi introduzida por um colaborador de confiança que, depois de anos construindo uma relação com os mantenedores, acabou explorando essa confiança. O incidente abalou a comunidade de código aberto, que depende da boa vontade e da integridade de seus participantes para criar softwares funcionais e seguros.

Entre os problemas de segurança generalizados e questões sistêmicas, como dificuldades de financiamento e esgotamento de desenvolvedores, o universo do código aberto está passando por um período de transformação. Iniciativas como o Open Source Pledge buscam ajudar a manter o código aberto viável e garantir a segurança da cadeia de suprimentos de software. Mas ainda há muito que não sabemos sobre o futuro desse trabalho de desenvolvimento, que dá suporte a 70% a 90% dos softwares atuais. 

No relatório State of Open Source 2024 da Snyk, buscamos revelar o cenário atual da segurança do código aberto e seus desafios em evolução. Nossas descobertas mostram um setor em uma encruzilhada: embora o desenvolvimento de código aberto continue sendo a base da maioria dos softwares atuais, ele enfrenta obstáculos persistentes — do avanço estagnado de DevOps à complexidade crescente da segurança da cadeia de suprimentos. Ainda assim, apesar desses desafios, há mudanças promissoras na forma como as organizações lidam com essas questões. 

O avanço de DevOps estagna — e o esgotamento em AppSec aumenta

Nossas descobertas indicam que o universo do código aberto chegou a um platô de maturidade em DevOps: a frequência de lançamentos de código permanece praticamente igual à do relatório do ano passado. Com o amadurecimento dos processos de DevOps, as implantações de código deveriam se tornar menores e mais frequentes. Essa inércia mostra que a adoção desses processos realmente desacelerou. Da mesma forma, muitos entrevistados consideram desafiador cumprir os prazos dos SLAs para vulnerabilidades. 52% das equipes disseram que frequentemente não cumprem esses prazos, e 74% definem SLAs pouco realistas, de uma semana ou menos.

Essa estagnação também aparece no rastreamento de dependências, que teve apenas uma pequena melhora: 25% dos entrevistados disseram rastrear somente as dependências diretas, e quase 5% não rastreiam nenhuma. Em AppSec, o avanço também é lento. Em um ciclo de DevSecOps no qual ferramentas diferentes podem fornecer informações de segurança em momentos inconvenientes, os desenvolvedores precisam de uma ferramenta centralizada para visualizar e gerenciar essas informações. 

Uma cadeia de suprimentos de software segura continua fora de alcance

Com sua complexa rede de equipes e ferramentas interconectadas, a cadeia de suprimentos de software pode ser difícil de gerenciar. Para protegê-la, é preciso identificar e corrigir vulnerabilidades em todas as etapas do ciclo de vida do software. Mas será que as estratégias das organizações para lidar com a segurança da cadeia de suprimentos evoluíram? 

Para muitas empresas, a resposta é não: as vulnerabilidades na cadeia de suprimentos continuam representando uma ameaça séria. Em 2024, 45% das organizações precisaram substituir componentes de build vulneráveis, o que significa que quase metade das cadeias de suprimentos teve exposição a vulnerabilidades. E ainda há muito a avançar na adoção de práticas de segurança para a cadeia de suprimentos. Das práticas sobre as quais perguntamos, somente duas são amplamente adotadas: monitoramento de SBOM (62%) e segurança de pipelines (50%).

Para corrigir esses pontos fracos, as organizações estão optando cada vez mais por ferramentas automatizadas de segurança de pacotes. Embora a automação possa acelerar muitos fluxos de trabalho com segurança, essa dependência crescente da automação para verificar a segurança de pacotes pode ser preocupante. A confiança excessiva nessas ferramentas pode fazer com que vulnerabilidades críticas passem despercebidas.

A análise de risco precisa ser mais sofisticada

Em um cenário de aumento das violações de segurança, o gerenciamento de riscos ajuda as empresas a identificar e prevenir riscos antes que se concretizem. Métodos inovadores de análise de risco, como a análise de explorabilidade ou de contexto de negócios, podem ampliar muito o valor do gerenciamento de riscos para muitas organizações, ajudando os desenvolvedores a identificar e corrigir primeiro as vulnerabilidades mais importantes. Mas, apesar da disponibilidade de novas técnicas avançadas, a maioria das organizações ainda depende muito de métodos tradicionais de análise de risco, como o Common Vulnerability Scoring System (CVSS) e a previsão de exploração. 

Essa lacuna indica dificuldades para avaliar os riscos reais das vulnerabilidades, o que prejudica a capacidade das organizações de priorizar e responder aos riscos com eficiência. Em outras áreas, também fica claro que o gerenciamento de riscos não recebe a prioridade necessária. Por exemplo, menos de 25% das organizações realizam auditorias regulares da cadeia de suprimentos de software.

A confiança nas ferramentas de segurança com IA é alta — talvez alta demais

Quase 80% dos entrevistados acreditam que as ferramentas de programação com IA geram código mais seguro. Apesar de pesquisas indicarem que elas introduzem novas vulnerabilidades, os desenvolvedores tendem a confiar na IA tanto quanto confiam nos próprios colegas. 84% afirmam aplicar o mesmo nível de análise aos pacotes de código aberto sugeridos por IA que aplicariam aos sugeridos por pessoas, o que revela uma dissonância cognitiva preocupante. 

À medida que a dependência da IA na programação aumenta, será fundamental evitar confiar demais nela para a segurança, em particular, a fim de não introduzir riscos ilimitados e garantir um monitoramento completo e bem executado.

Saiba mais no relatório State of Open Source 2024

As práticas de segurança do código aberto ainda têm um longo caminho a percorrer até alcançar a maturidade plena. Neste ano, o crescimento da adoção de práticas e ferramentas de segurança desacelerou. Essa tendência é preocupante diante dos novos níveis de risco para o software, com o aumento das ameaças cibernéticas e a possibilidade de vulnerabilidades introduzidas por IA. 

Por outro lado, a adoção de práticas de segurança mais maduras pode estar avançando devagar, mas está crescendo — e, com ela, a promessa de uma cadeia de suprimentos de software mais segura. 

Para conferir análises mais detalhadas e medidas práticas para proteger sua cadeia de suprimentos de software, leia o relatório completo hoje.

Conheça o cenário atual da segurança de código aberto

Entenda as tendências e abordagens atuais para proteger softwares de código aberto e a cadeia de suprimentos.

Leia mais

Live Stream

Agentes de Remediação, Desmistificados: Por Que Corrigir é Melhor do que Encontrar

Veja como o Remediation Agent da Snyk usa inteligência de segurança, análise de explorabilidade e validação para transformar vulnerabilidades em pull requests prontos para merge.

feature ai ide dark
Blog

Uma primeira visão do Evo Agentic AppSec: remediação agentiva e defesa contra código malicioso

Conheça os primeiros recursos de Agentic AppSec da Snyk: um agente de remediação autônomo que corrige vulnerabilidades e uma defesa contra código malicioso que bloqueia pacotes arriscados antes que sejam lançados.

feature insights context
Blog

Por dentro do comprometimento do keyv npm: malware no preinstall, procedência confiável e hooks de IDE

O keyv 6.0.0 e outras dez versões do npm distribuíram malware executado durante a instalação. Confira as versões afetadas, os hashes, as etapas de detecção e a ordem segura de correção.