Como enfrentar os desafios de cibersegurança em software de código aberto com a Linux Foundation

A Snyk se uniu recentemente à Linux Foundation para produzir um relatório sobre o cenário da segurança no universo do software de código aberto (OSS). O relatório se baseia em mais de 550 respostas a uma pesquisa e 15 entrevistas com especialistas em manutenção de projetos OSS e cibersegurança.

Após a publicação do relatório, especialistas da Snyk participaram de um webinar com a Linux Foundation para discutir algumas das principais descobertas: Enfrentando os desafios de cibersegurança em software de código aberto: painel de especialistas. Participaram do webinar Mic McCully (estrategista de campo, Snyk), Matt Jarvis (diretor de relações com desenvolvedores, Snyk) e Steve Hendrick (vice-presidente de pesquisa, Linux Foundation).

Continue lendo para saber mais sobre como melhorar a segurança e a sustentabilidade do software de código aberto.

Vulnerabilidades na cadeia de suprimentos de software

À medida que as cadeias de suprimentos de software se tornam mais complexas, a segurança do código aberto ganha cada vez mais importância. Hoje, por exemplo, a maioria dos softwares tem muitas dependências indiretas ou transitivas, que são difíceis de visualizar e avaliar do ponto de vista da segurança de aplicações.

Quando os desenvolvedores adicionam um pacote de código aberto, muitas vezes esse pacote faz referência a outros projetos de código aberto. Isso cria uma hierarquia, em que os pacotes de níveis mais baixos são chamados de dependências indiretas ou transitivas.

De acordo com o relatório recente, cada projeto OSS tem, em média, 49 vulnerabilidades distribuídas por 79 dependências diretas. Esse número varia conforme o ecossistema: os projetos JavaScript têm muito mais vulnerabilidades do que os projetos Python, Go, Java e .NET.

Outro dado revelador é a localização dessas vulnerabilidades nos pacotes. O relatório mostrou que mais de 40% desses problemas de segurança estão em dependências indiretas. Isso significa que muitas vezes as equipes de desenvolvimento não sabem que estão incluindo código vulnerável em seus projetos.

Como vimos na Snyk, essas vulnerabilidades podem estar muito profundamente aninhadas. Alguns desses problemas na cadeia de suprimentos de software podem vir de dependências que estão quatro ou cinco níveis abaixo.

A necessidade de SBOMs e políticas de segurança para OSS

Como os problemas de segurança costumam ficar ocultos em árvores de dependências complexas, a ideia

de criar uma lista de materiais de software (SBOM) vem ganhando popularidade. SBOMs são registros formais dos componentes de um software e das relações na cadeia de suprimentos, criados para aumentar a transparência.

A realidade é que precisamos saber o que há em um componente. Precisamos entender o quanto ele é utilizável e se podemos confiar nele. Quando há dependências transitivas, pode ser muito difícil obter essas informações.

Um dos motivos pelos quais muitas empresas não estão criando SBOMs é a falta generalizada de segurança no código aberto. De fato, os resultados da pesquisa do relatório revelaram que apenas 49% das organizações têm uma política de segurança que contempla o código aberto.

Sem uma política para software de código aberto, você não consegue gerenciar os riscos com eficácia. Não sabe ao certo como agir diante de vulnerabilidades, e sua postura de segurança fica comprometida.

Como as organizações verificam a segurança dos pacotes OSS?

Embora o relatório tenha constatado que 44% das empresas contam com desenvolvedores para examinar o código-fonte em busca de vulnerabilidades, elas usam quase uma dúzia de tipos diferentes de ferramentas para isso. Duas das mais populares são o teste estático de segurança de aplicações (SAST) e a análise de composição de software (SCA).

Outra forma comum de as organizações verificarem a segurança dos pacotes OSS é avaliá-los antes de adotá-los. Elas procuram projetos OSS bem avaliados, com uma comunidade ativa que lança mudanças de código com frequência e uma política de segurança divulgada publicamente. Ainda assim, esses componentes podem conter vulnerabilidades em dependências transitivas se os responsáveis pela manutenção do projeto não adotarem medidas proativas para garantir a segurança do OSS.

O que estamos começando a ver em todo o setor são novas formas de fornecer informações sobre segurança e confiabilidade para quem usa software de código aberto. Começamos com as estrelas do GitHub, mas agora temos o OpenSSF Scorecards e outras fontes de informações detalhadas.

O impacto do Log4Shell na comunidade Java

O relatório também revelou dados interessantes sobre a ampla vulnerabilidade Log4Shell na comunidade Java. Um dos principais destaques é que 79% dos projetos afetados pelo Log4Shell têm mais de uma vulnerabilidade Log4Shell na base de código, e 60% dos casos foram encontrados em dependências indiretas.

O Log4Shell realmente mostrou como projetos de código aberto podem se tornar vítimas do próprio sucesso. Quando uma biblioteca de código aberto, como o Log4j, é usada em tantos projetos diferentes, o impacto de problemas de segurança pode ser gigantesco. Isso colocou em evidência a necessidade de scanners de SCA.

As vulnerabilidades de código aberto estão cada vez mais difíceis de corrigir

As cadeias de suprimentos de software estão ficando mais complexas, e muitas organizações enfrentam desafios cada vez maiores para ter visibilidade da segurança. Como resultado, também está ficando mais difícil corrigir vulnerabilidades de código aberto. O tempo para corrigir vulnerabilidades, por exemplo, aumentou de 49 dias em 2018 para 110 dias em 2021.

Em três anos, o tempo para corrigir mais que dobrou. Ao mesmo tempo, outras duas coisas aconteceram: 1) o uso e o desenvolvimento de software cresceram em um ritmo acelerado; 2) estamos dedicando muito mais tempo e atenção à segurança.

Outro desafio que as organizações enfrentam com o aumento do tempo de correção é a falta de recursos. Algumas empresas estão, de fato, corrigindo problemas críticos mais rápido do que antes, mas as vulnerabilidades de baixa prioridade demoram demais para ser tratadas devido à falta de recursos de segurança de aplicações. Por isso, SAST e SCA são as duas principais formas que as empresas apontam para lidar com questões de segurança.

As ferramentas de análise SAST e SCA podem ser integradas aos pipelines de CI/CD e ao processo de desenvolvimento para automatizar a detecção e a correção de muitas vulnerabilidades de código aberto. Isso ajuda as organizações a superar alguns dos desafios de recursos de segurança de aplicações.

Há uma forte correlação entre a automação do pipeline de implantação e o tempo necessário para corrigir problemas de segurança. Com um CI/CD totalmente automatizado, você tem vários pontos de integração para incluir verificações de segurança.

O cenário da segurança de código aberto em 2022

Esta conversa entre a Snyk e a Linux Foundation abordou algumas das principais descobertas do relatório, mas ainda há muito a explorar. Baixe o relatório completo para saber mais sobre a complexidade e os riscos do cenário atual da cadeia de suprimentos de software: State of Open Source Security 2022.