Explorabilidade não é a resposta. Facilidade de quebra, sim.

O paradoxo da AppSec: por que não corrigimos mais vulnerabilidades?

Por que os desenvolvedores não corrigem todas as vulnerabilidades de AppSec assim que são encontradas? A resposta mais comum? Tempo. As ferramentas modernas de segurança podem detectar milhares de vulnerabilidades em uma base de código. Corrigir todas elas ocuparia toda a capacidade de uma equipe de desenvolvimento, muitas vezes competindo com o desenvolvimento de recursos e outras prioridades.

Mas o tempo necessário para corrigir vulnerabilidades mudou nos últimos anos. Antes, investigar um achado, entender como corrigi-lo e alterar o código manualmente costumava levar o dia todo. Hoje, ferramentas de automação e assistidas por IA cuidam de boa parte desse trabalho, deixando as alterações de código prontas para serem incorporadas no tempo de fazer um café. Em especial, para vulnerabilidades de SCA, a correção costuma se resumir a atualizar pacotes de versões sabidamente vulneráveis para versões mais recentes que corrigem as CVEs.

Então, se o tempo não é mais o gargalo, o que é? Confiança. Os desenvolvedores não ignoram as correções por não quererem resolver problemas de segurança. Na maioria das vezes, hesitam porque têm medo de quebrar o código.

Conheça Breakability, o elo que faltava na priorização

Para ajudar as equipes a priorizar com mais confiança, estamos lançando um novo recurso para Snyk Open Source: Breakability Risk.

A primeira fase de Breakability se concentrou na pergunta que os desenvolvedores fazem todos os dias: se eu aplicar a correção recomendada pela Snyk, vou quebrar meu aplicativo? Toda atualização de dependência envolve algum nível de risco. Uma atualização “simples” da referência de um pacote pode introduzir mudanças na API que façam o código falhar na compilação. Ou pior: as assinaturas dos métodos da API podem continuar iguais, mas mudanças sutis de comportamento podem fazer com que o código compile e falhe em tempo de execução.

Muitas vezes, duas ou mais dependências diretas compartilham uma dependência transitiva. Quando várias dependências diretas dependem do mesmo pacote subjacente, atualizar uma parte do grafo de dependências para corrigir uma CVE pode criar uma incompatibilidade com outro conjunto de dependências. Esse é o temido problema do “inferno das dependências”.

Breakability Risk identifica quais atualizações podem ser aplicadas com segurança agora e quais exigem uma análise mais aprofundada.

Confiança impulsiona a segurança

Realizamos experimentos com análises de breakability, e os padrões são consistentes. Quando os desenvolvedores entendem que o risco de quebrar seus aplicativos é baixo, a probabilidade de incorporarem uma correção aumenta significativamente. Em nossos experimentos, as atualizações com baixo risco de quebra foram incorporadas a uma taxa quatro vezes maior que as alterações de maior risco.

Nossa análise mostra que cerca de um terço de todas as correções se enquadra na categoria de baixo risco de quebra. Para um cliente médio da Snyk, priorizar essas atualizações de menor risco pode significar corrigir milhares de vulnerabilidades adicionais por ano.

Breakability na prática: risco baixo vs. alto

Agora, a Snyk inclui uma etiqueta de risco de merge diretamente na sua pull request para orientar a priorização e acelerar as correções. Snyk Open Source oferece detalhes, pontuação de risco contextual e recursos educacionais por meio do Snyk Learn para capacitar desenvolvedores.

Cenário 1: “Vitória fácil”

Neste cenário, Snyk Open Source abriu uma pull request para atualizar para uma versão mais recente do [libxmljs2] e corrigir várias vulnerabilidades de negação de serviço por expressão regular (ReDoS).

• Análise: A atualização principalmente deixa de oferecer suporte a versões do Node.js que chegaram ao fim da vida útil

• Breakability Risk: A Snyk classifica como Risco de merge: baixo, pois não há mudanças significativas de comportamento

• Veredito: Clique no botão. Proteja o código. Siga em frente.

Cenário 2: “Prossiga com cautela”

Aqui, uma atualização de [i18n] corrige o prototype pollution, mas introduz uma mudança arquitetural: de um singleton global para uma configuração baseada em instâncias.

• Análise: O padrão fundamental de uso da biblioteca mudou.

• Breakability Risk: A Snyk classifica como Risco de merge: alto devido a mudanças arquiteturais incompatíveis na biblioteca.

• Veredito: Não faça o merge antes de revisar seu próprio código e implementar as alterações necessárias.

Uma nova hierarquia de correção

Acreditamos que a primeira pergunta em qualquer fluxo de correção deve ser simples: posso resolver esse problema com o mínimo de esforço e risco?

Se a resposta for sim, faça a correção. Breakability permite que as equipes priorizem as atualizações de baixo risco, abrindo caminho para corrigir um terço ou até metade do backlog de CVEs com um único clique. Ao eliminar o medo de “quebrar tudo”, as equipes podem reduzir com confiança uma parte significativa do backlog e resolver uma dívida de segurança que afeta equipes de desenvolvimento há anos, diminuindo os riscos sem aumentar a carga de trabalho da engenharia.

A Snyk não está deixando de lado Reachability nem a Risk Score.

Por mais valiosa que seja a capacidade de alcançar uma vulnerabilidade como critério de priorização, existe uma grande diferença entre afirmar “esta vulnerabilidade definitivamente não pode ser alcançada” e “não foi encontrado um caminho alcançável para esta vulnerabilidade”. A segunda situação é muito mais comum que a primeira. Simplesmente, não é seguro presumir que “nenhum caminho alcançável encontrado” significa que não existe um caminho alcançável, especialmente no mundo atual, em que invasores usam ferramentas de hacking com IA para encontrar e explorar vulnerabilidades mais rápido do que nunca. Em vez de aceitar o risco de pacotes com vulnerabilidades potencialmente inalcançáveis, estamos facilitando para você simplesmente corrigir o problema — sem o risco de efeitos colaterais negativos.

Breakability e o AI Security Fabric da Snyk

Esse novo paradigma de correção é essencial para impulsionar o AI Security Fabric. Como descrito no Caminho prescritivo para operacionalizar a segurança de IA, Breakability ajuda você a otimizar a redução de riscos ao gerar confiança nas correções sugeridas, ir além dos critérios de priorização e criar um processo previsível, baseado em confiança, que permite às equipes incorporar mais correções com mais rapidez e menos receio de mudanças incompatíveis.

Comece a usar Breakability

A primeira fase de Breakability já está disponível como recurso Snyk Preview para todos os clientes de Snyk Open Source. Ative o recurso para começar a ver avaliações de risco de mudanças incompatíveis nas pull requests geradas pela Snyk. Adoraríamos que você experimentasse e contasse o que achou!

Repensando como priorizar e corrigir vulnerabilidades com mais confiança? Veja como os insights baseados em IA ajudam as equipes a ir além da detecção e alcançar uma redução de riscos previsível e escalável. Baixe hoje nosso eBook, De Shift Left a Secure at Inception.