Durante anos, a evolução de AppSec foi guiada por uma lógica clara: encontrar mais vulnerabilidades, mais cedo.
- Ferramentas melhoraram.
- Cobertura aumentou.
- Os times passaram a enxergar mais.
- E, ainda assim, o risco cresceu.
Não porque estamos vendo menos, mas porque não estamos conseguindo agir rápido o suficiente sobre o que vemos.
A matemática que não fecha
O relatório State of Software Security 2026 escancara essa contradição.
Os números são difíceis de ignorar:
- 82% das organizações já carregam security debt
- 60% convivem com dívida crítica (alta severidade + explorabilidade)
- 49% das aplicações têm vulnerabilidades com mais de 1 ano
- 36% de aumento nas vulnerabilidades realmente exploráveis
- 243 dias é o tempo médio para corrigir metade dos problemas
E talvez o dado mais importante:
👉 a maioria das equipes corrige cerca de 10% dos problemas por mês
Enquanto isso, novos continuam entrando.
O resultado não é um backlog grande. É um backlog estrutural.
O erro não está na ferramenta. Está no modelo
A maioria dos fluxos de desenvolvimento ainda opera assim:
- Encontra vulnerabilidades;
- Classifica por severidade;
- Joga na fila;
Tenta resolver conforme capacidade.
O problema é que esse modelo foi pensado para um mundo onde o volume era menor, o ciclo era mais lento e a complexidade era mais controlada.
Nada disso é verdade hoje.
Com CI/CD, microserviços, APIs e código gerado por IA, o fluxo virou contínuo, mas o modelo de correção continua discreto.
E isso cria uma distorção perigosa:
- Nem toda vulnerabilidade que você corrige reduz o risco.
- Nem toda vulnerabilidade que você ignora é irrelevante.
O atacante não vê CVSS
Enquanto o time prioriza por score, o atacante prioriza por viabilidade.
Ele não pergunta se é 7.5 ou 9.8.
Ele pergunta:
- Isso está exposto?
- Consigo encadear isso?
- Tem caminho até execução?
E age.
Isso explica por que vemos:
- Ambientes com “boa postura” sendo comprometidos;
- Falhas “menores” virando incidentes;
- Vulnerabilidades antigas sendo exploradas.
O problema não é a falta de correção. É uma correção desalinhada com risco real.
A dívida de segurança deixou de ser técnica
O conceito de security debt mudou.
Antes, era backlog. Hoje, é uma exposição acumulada.
E essa dívida tem três origens claras:
1. Velocidade maior que capacidade
Você produz mais código do que consegue revisar e corrigir.
2. Complexidade crescente
Dependências, integrações, serviços distribuídos.
No próprio relatório, 66% da dívida crítica vem de código de terceiros.
E a correção aqui é mais lenta: 358 dias de half-life, em média.
3. IA acelerando tudo
Código é gerado mais rápido, e com falhas.
Em testes citados no relatório, 86% do código gerado por IA falhou em testes de XSS.
O ponto de ruptura: você não vai corrigir tudo
Essa talvez seja a conclusão mais importante, e mais desconfortável. Corrigir todas as vulnerabilidades não é mais um objetivo viável
E insistir nisso gera:
- Overload no time;
- Backlog infinito;
- Perda de confiança nos alertas;
- Priorização baseada em urgência, não em impacto.
A mudança necessária não é de ferramenta. É de lógica.
O novo modelo: priorizar, proteger, provar
O próprio relatório propõe um caminho, e ele faz sentido para quem está no dia a dia do código.
Priorizar
Nem tudo tem o mesmo peso.
Você precisa saber:
- Quais apps são críticos;
- Quais falhas são exploráveis;
- Onde está o impacto real.
Sem isso, tudo vira urgente e nada é resolvido direito.
Proteger
Segurança não pode ser uma etapa.
Precisa estar no fluxo:
- No IDE;
- No commit;
- No pipeline.
Quanto mais cedo a correção acontece, menor o custo e maior a chance de acontecer.
Provar
Corrigir não é suficiente.
Você precisa saber:
- Isso resolveu o problema?
- O risco realmente caiu?
- Existe evidência disso?
Sem prova, a operação vira fé.
Onde entra a Veracode nesse cenário
O ponto mais interessante do relatório é que ele não fala só do problema, ele descreve exatamente o tipo de solução que começa a ganhar relevância.
Plataformas como a Veracode atuam justamente na interseção desses três pontos.
Não apenas encontrando vulnerabilidades, mas ajudando a:
- Priorizar com base em risco real, não só severidade;
- Integrar segurança ao fluxo de desenvolvimento;
- Acelerar correção com apoio de IA (como o Veracode Fix);
- Gerenciar dependências e supply chain com SCA e controles de entrada;
- Centralizar contexto com ASPM (Application Security Posture Management).
Isso muda o papel da segurança para o dev.
De algo externo e reativo, para algo integrado e acionável.
O impacto real para quem desenvolve
No fim, tudo isso converge para uma mudança prática:
- Menos tempo lidando com alertas irrelevantes;
- Mais foco no que realmente importa;
- Menos retrabalho;
- Mais previsibilidade no fluxo.
E, principalmente: menos sensação de que segurança é um problema sem fim
O que muda a partir daqui
A próxima fase do AppSec não será sobre encontrar mais. Será sobre decidir melhor.
E isso exige três coisas dos times de desenvolvimento:
- Contexto;
- Integração;
- Capacidade de agir rápido.
Porque, no ritmo atual, o risco não vem daquilo que você não viu.
Vem daquilo que você viu…e não conseguiu resolver a tempo.
Fontes
Veracode. 2026 State of Software Security: Prioritize, Protect, Prove.
Veracode. Disponível em: https://www.veracode.com/
Veracode. Veracode Fix. Disponível em: https://www.veracode.com/products/fix/
Veracode. Veracode Risk Manager. Disponível em: https://www.veracode.com/risk-manager/
Veracode. Software Composition Analysis. Disponível em: https://www.veracode.com/products/software-composition-analysis/
Veracode. Veracode Package Firewall. Disponível em: https://www.veracode.com/products/veracode-package-firewall/
CISA. Known Exploited Vulnerabilities Catalog. Disponível em: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Posts recentes
