Estado da segurança do código aberto de 2023

Apesar dos sucessivos recordes de número de ataques cibernéticos de um ano para o outro e o crescente número de ataques visando o código aberto, uma grande porcentagem das organizações participantes ainda não usa as duas tecnologias de segurança do supply chain mais básicas: análise de composição de software (SCA, para dependências de código aberto) e testes de segurança de aplicativo estático (SAST, para implementações de código aberto não público e código proprietário). Um número ainda menor adota medidas de segurança nativas de nuvem, como verificações de configuração de ferramentas de infraestrutura como código e verificação de segredos.

A verificação da postura de segurança dos pacotes de código aberto é crucial para manter a segurança do supply chain de software. Sistemas automatizados para verificar a adoção de práticas recomendadas de segurança pelos pacotes, como Snyk Advisor ou OpenSSF Scorecard, são a forma mais confiável para analisar automaticamente os riscos. No entanto, esses sistemas são os menos utilizados para verificar a segurança de pacotes de código aberto. Apenas 40% dos participantes usam o Snyk Advisor e somente 34% usam cartões de pontuação de segurança.

Surpreendentemente, apenas 52% dos participantes verificam se todos os pacotes têm uma política de "divulgações responsáveis", o que deveria ser um cuidado básico em qualquer pacote utilizado.

A segurança desde o início tem sido prioritária para muitas organizações de engenharia que tentam ser proativas no aprimoramento da segurança do código e na redução de vulnerabilidades inseridas involuntariamente durante o desenvolvimento do software. Essa medida aumenta a velocidade e eficiência do SDLC, já que reduz o número de compilações bloqueadas nos testes pré-implantação e devolvidas aos desenvolvedores para correção. Além disso, a adoção da segurança desde o início é um processo ainda não concluído: apenas 40% dos participantes indicaram que a organização implanta ferramentas de segurança nos IDEs e uma porcentagem ainda menor as usa localmente na linha de comando.  As localizações mais comuns do ferramental de segurança são as ferramentas de compilação e os repositórios de código, ambos por volta de 65%.

As respostas da pesquisa sinalizam que a crise de segurança no supply chain de software é real e afeta as organizações de diversas maneiras. A grande maioria dos participantes foi afetada por um ou mais problemas de supply chain no ano anterior. Quando se trata de impactos específicos, 53% precisaram corrigir uma ou mais vulnerabilidades e 61% implementaram novas ferramentas e práticas recomendadas para segurança do código aberto e supply chain, sinalizando que muitos somente tomam medidas depois de serem afetados diretamente por um ataque direcionado ao supply chain. 

A adoção real de práticas recomendadas de segurança do supply chain de software parece ser dispersa. Apenas 53% das organizações contam com um programa formal de segurança do supply chain. Um possível motivo é que a segurança do supply chain de software ainda é considerada como um subconjunto da prática geral de segurança, mas fica a pergunta: a segurança do supply chain ainda vai se tornar um problema crítico para as organizações (ou suficientemente crítico para merecer um programa específico de visualização e planejamento)? Em termos de práticas mais específicas, apenas 42% das organizações usam SBOMs, 58% estão implementando assinatura de código em sua atribuição e 62% estão adotando um processo de garantia de ciclo de vida do software (como SLSA).

O tipo de vulnerabilidades ignoradas pelas organizações oferece informações úteis sobre a superfície de ataque e os riscos aceitos de forma consciente ou subconsciente. De longe, o tipo dominante de ameaça entre as CVEs ignoradas por pelo menos 50 contas foram variações da negação de serviço (DoS). Essas vulnerabilidades foram responsáveis por 31,3% de todas as vulnerabilidades ignoradas. Os ataques de DoS são sérios, mas frequentemente mitigados proativamente em CDNs ou infraestruturas. Portanto, é compreensível que muitas equipes não priorizem essas CVEs. A desserialização de dados não confiáveis correspondeu a 14,3% das CVEs ignoradas por mais de 50 contas. Essa é uma classe relativamente abrangente de vulnerabilidades com possíveis impactos em diversas linguagens. Frequentemente, elas podem ser a primeira etapa de um ataque encadeado ou composto, o que as torna vulnerabilidades sérias. A terceira vulnerabilidade mais comum, poluição de protótipos (com 12,5%), afeta principalmente a comunidade de JavaScript. 

Desde o início do código aberto, há um intenso debate sobre o software de código aberto ser, de fato, mais seguro que o software de código fechado. As vulnerabilidades são publicadas abertamente, assim como as correções correspondentes. Dessa forma, é possível rastrear dados de tempo de correção (TTF) usando bancos de dados de vulnerabilidades. Rastreamos o TTF nos últimos quatro anos completos e constatamos que, desde 2019, o TTF médio dos aplicativos proprietários aumentou de forma consistente, enquanto o de aplicativos de código aberto diminuiu, também de forma consistente. Na verdade, os dois tipos reduziram o TTF em 2021\. No entanto, pela primeira vez desde que rastreamos essa métrica, o TTF dos aplicativos de código aberto foi menor que o dos aplicativos proprietários. Isso implica que o ecossistema de código aberto aprimora a resposta de segurança ao longo do tempo e tende a oferecer melhor segurança que o mundo do código fechado.

Após um grande pico na média de TTF para vulnerabilidades críticas e de alta prioridade, a métrica caiu drasticamente nos últimos dois anos. Esse pico pode indicar que a verificação de código aberto aumentou nesses dois anos, revelando vulnerabilidades previamente não detectadas. De 2021 a 2022, o TTF médio dessas duas designações críticas caiu aproximadamente pela metade: -51% para vulnerabilidades críticas e -49,4% para as de alta prioridade. Pode haver várias explicações para esse declínio constante, como maior adoção de ferramentas de segurança do código aberto (por exemplo, SCA), mais financiamento e pessoal investidos na correção de vulnerabilidades críticas de código aberto e maior reconhecimento de que a segurança é uma prioridade importante nos projetos de código aberto. Seja como for, os sinais são bons e indicam uma forte tendência no rumo correto para o aprimoramento contínuo da segurança de OSS. 

O TTF variou entre os ecossistemas de código aberto e diminui drasticamente para a maioria desses ecossistemas mais importantes rastreados pela Snyk. As maiores reduções do TTF médio ocorreram para Java e Python (50,8% e 43,4%, respectivamente). Todos os cinco ecossistemas que registraram queda alcançaram reduções de dois dígitos. Go e Python apresentaram a maior queda total em termos de dias, com o Go registrando uma redução do TTF médio de 147 dias e o Python de 115 dias. Dois ecossistemas regrediram. Os ecossistemas de C e Ruby mostraram um crescimento de 144,7% e 102,1% no TTF médio em dias, com um aumento do número total de dias de respectivamente 55 e 49 dias. Os ecossistemas de código aberto aprimoram os tempos de respostas de segurança e, consequentemente, fortalecem a segurança do supply chain, reduzindo o intervalo entre a publicação e a correção das vulnerabilidades.