Panorama da segurança de código aberto em 2023, da Snyk: segurança da cadeia de suprimentos, IA e muito mais

IA, falsos positivos e a adoção lenta de ferramentas de segurança continuam sendo preocupações, mas correções mais rápidas e avanços na segurança da cadeia de suprimentos são sinais positivos.

O incidente de Log4Shell em 2021 lançou luz sobre a segurança de software de código aberto — e, em especial, sobre a segurança da cadeia de suprimentos. Os 18 meses seguintes ao incidente trouxeram mais atenção à segurança de software de código aberto do que em qualquer outro momento da história. Organizações como a OpenSSF, a AlphaOmega e grandes empresas de tecnologia estão investindo recursos consideráveis em ferramentas e capacitação. Mas a segurança de software de código aberto está realmente melhorando? E em que pontos os esforços ainda deixam a desejar? 

A Snyk buscou responder a essa pergunta em nosso relatório mais recente, o Panorama da segurança de código aberto em 2023. Entrevistamos centenas de profissionais técnicos e analisamos dados anonimizados do uso real de nossa linha de produtos para reunir esses resultados. O relatório busca esclarecer o estado atual e futuro da segurança da cadeia de suprimentos, oferecendo às organizações um caminho a seguir à medida que o setor de cadeia de suprimentos de software cresce. Confira algumas de nossas principais descobertas.

A segurança da cadeia de suprimentos não acompanha o ritmo do desenvolvimento

Muitas organizações enfrentam uma lacuna entre a inovação e a segurança da cadeia de suprimentos. Embora a maioria use tecnologia avançada para a cadeia de suprimentos, descobrimos que a maioria dos entrevistados não protege esses processos com práticas como auditorias contínuas, monitoramento de dependências indiretas ou verificação antecipada das classificações de segurança de pacotes de código aberto durante o desenvolvimento. Um dado significativo: 40% dos entrevistados ainda não usam tecnologias fundamentais de segurança, como análise de composição de software (SCA) e teste estático de segurança de aplicações (SAST). 

À medida que as ferramentas de desenvolvimento de código aberto continuam crescendo e atraindo a atenção de agentes maliciosos, as empresas precisam considerar a adoção de abordagens de segurança da cadeia de suprimentos.

Automação e IA criam novas oportunidades e desafios

O avanço da automação e da IA está claramente impactando o desenvolvimento de aplicações. Estamos vendo grandes avanços no uso dessas tecnologias para a segurança. Mas será que essas tecnologias emergentes estão fortalecendo ou enfraquecendo a postura de segurança? 

Segundo nosso relatório, ainda há hesitação em relação a essas novas tecnologias, e as opiniões sobre se as ferramentas de IA vão melhorar a segurança do código estão divididas. Também vemos resultados variados quanto à eficácia da automação de segurança: 61% dos entrevistados afirmaram que a automação aumentou o número de falsos positivos. 

Apesar dessas opiniões divergentes, a maioria das organizações continua adotando essas novas tecnologias para desenvolvimento e segurança. Só o tempo dirá como a IA e a automação afetarão a segurança da cadeia de suprimentos de software.

A segurança da cadeia de suprimentos ainda não foi deslocada para as etapas iniciais

Um princípio fundamental da segurança da cadeia de suprimentos é capacitar desenvolvedores para detectar vulnerabilidades mais cedo no ciclo de vida de desenvolvimento de software (SDLC). Isso significa oferecer ferramentas e treinamento para que desenvolvam código com mais segurança e façam análises com maior frequência. Essas práticas aumentam a velocidade e a eficiência do SDLC, pois menos builds são bloqueados em testes pré-implantação e enviados de volta aos desenvolvedores para correção. 

Nossa pesquisa revelou que antecipar a segurança para as etapas iniciais ainda é uma tarefa incompleta. Apenas 40% dos entrevistados afirmaram que suas organizações integram ferramentas de segurança aos IDEs dos desenvolvedores, e uma parcela ainda menor as utiliza localmente pela linha de comando. As ferramentas de build e os repositórios de código são os locais mais comuns para ferramentas de segurança — ambos com cerca de 65%. Esse dado mostra que as equipes ainda estão inserindo ferramentas de segurança da cadeia de suprimentos em etapas mais tardias do desenvolvimento, como parte dos processos de build ou de envio de código ao repositório, em vez de adotar uma abordagem contínua para a segurança do código. 

Para concretizar a visão de antecipar a segurança de forma proativa, os desenvolvedores precisam ter acesso às mesmas ferramentas de segurança usadas pelas equipes de DevOps, segurança de aplicações e outras equipes envolvidas nas etapas posteriores. Embora 40% não seja um número ruim, isso significa que as ferramentas de segurança ainda são pouco presentes nas ferramentas de fluxo de trabalho mais importantes dos desenvolvedores.

O número de falsos positivos da automação é inaceitavelmente alto

Muitas organizações implantaram medidas automatizadas de segurança no pipeline de código. Isso aumentou os falsos positivos nos alertas de vulnerabilidade, podendo prejudicar a produtividade. Na pesquisa, 64% das organizações automatizaram a análise de código, 61% automatizaram o gerenciamento de atualizações de software, 59% automatizaram os testes (unitários e de segurança) e 58% automatizaram práticas de codificação segura (linters, formatação etc.). Embora facilite a busca por vulnerabilidades, a automação das ferramentas de segurança também aumentou a proporção de falsos positivos. 60% dos entrevistados afirmaram que a automação aumentou os falsos positivos, enquanto 30% disseram que ela os reduziu. Entre os alertas, os falsos positivos representaram uma parcela considerável: 62% dos entrevistados afirmaram que 25% ou mais dos alertas de vulnerabilidade recebidos eram falsos positivos. 35% relataram que 50% ou mais de seus alertas eram falsos positivos.

Essa alta proporção de falsos positivos gera uma enorme sobrecarga técnica para as equipes de segurança e desenvolvimento e pode comprometer os benefícios da automação. Para realmente melhorar a segurança da cadeia de suprimentos de software, as equipes precisarão se concentrar em reduzir os falsos positivos. 

O aumento da resposta de segurança tem vantagens e desvantagens

Vários ataques de grande repercussão aumentaram o foco na segurança da cadeia de suprimentos. As equipes de engenharia e segurança também sofrem pressão de órgãos governamentais, como a Ordem Executiva dos Estados Unidos sobre o aprimoramento da cibersegurança nacional e a proposta de Lei de Resiliência Cibernética da União Europeia. 

Por conta desses fatores, vários entrevistados aceleraram recentemente suas práticas de segurança. Algumas dessas iniciativas incluem novas ferramentas, aumento da frequência de análise do código e treinamentos.

Mas, apesar da exigência federal de uma lista de materiais de software (SBOM) em 2021, apenas 42% das organizações usam uma SBOM. E quem usa enfrenta uma situação de “Torre de Babel” com suas SBOMs. Nosso relatório revelou que as organizações usam diversas ferramentas de desenvolvimento de software, CI/CD e segurança da cadeia de suprimentos para gerar SBOMs. Como resultado, as SBOMs atuais variam bastante e podem não ser interoperáveis, o que dificulta analisá-las de forma relevante. Assim, embora muitas organizações estejam “marcando a caixa da SBOM”, ainda não aproveitam todo o seu potencial.

A segurança da cadeia de suprimentos está melhorando, mas ainda há trabalho a fazer

De modo geral, o Relatório sobre o panorama da segurança da cadeia de suprimentos de software em 2023 mostra que a segurança da cadeia de suprimentos de software está melhorando, mas ainda há trabalho a fazer. Como sinal de que estamos no caminho certo, nossa pesquisa constatou uma redução no tempo de correção (TTF) em todos os níveis de gravidade e na maioria dos principais ecossistemas de código aberto. Na verdade, o TTF dos componentes de código aberto está atualmente menor do que o tempo de correção em software proprietário. Há algumas explicações possíveis para essas tendências positivas, como a adoção mais ampla de ferramentas de segurança de código aberto, como SCA, mais recursos financeiros e profissionais dedicados à correção de vulnerabilidades críticas de código aberto e maior conscientização sobre segurança em projetos de código aberto. 

Por outro lado, também observamos que a superfície de ataque de código aberto continua muito ampla, com muitas organizações ignorando vulnerabilidades em grandes ecossistemas como JavaScript, Java e Debian. Por exemplo, a vulnerabilidade Log4Shell continua sem correção em inúmeras organizações, mesmo 18 meses após sua divulgação.

Nossas descobertas também indicam que estamos em um período de transição — deixando abordagens antigas para adotar métodos e tecnologias mais recentes. Em suma, estamos no caminho certo, mas precisamos seguir em frente e inovar para reduzir os riscos do código aberto no futuro.

Leia o relatório completo ou confira hoje mesmo os destaques em nossa página interativa.