A exploração de vulnerabilidades virou o vetor de acesso nº1: por que mais patches é apenas parte da resposta
Em junho de 2026, a Verizon publicou a 19ª edição do Data Breach Investigations Report (DBIR), construída sobre mais de 22.000 violações confirmadas em 145 países. Entre dezenas de achados, um deles reorganiza a forma como uma organização deveria priorizar seu investimento em segurança: a exploração de vulnerabilidades passou a ser o vetor de acesso inicial mais comum em violações, à frente do abuso de credenciais, que liderava até então. Este artigo discute o que esse dado significa, por que a resposta intuitiva de "corrigir mais rápido" não resolve o problema na raiz, e qual leitura o Quor faz dessa mudança a partir da composição das imagens de container que sustentam as aplicações.
Security Researcher
Heitor Gouvêa
O que é um vetor de acesso inicial
No vocabulário do DBIR, o initial access vector é o mecanismo pelo qual um agente externo obtém o primeiro ponto de apoio dentro do ambiente da vítima, antes de qualquer movimentação lateral, escalonamento de privilégio ou exfiltração. É a porta por onde se entra. Toda violação tem um ponto de entrada.
A relevância prática deste conceito é que ele indica onde o investimento defensivo tem maior retorno marginal. Se a maioria das violações começa com credenciais roubadas, a prioridade racional é autenticação forte, gestão de identidade e MFA. Se a maioria começa com a exploração de uma falha conhecida em um componente de software, a prioridade se desloca para a composição e a integridade daquilo que se executa. São investimentos diferentes, e a distribuição dos vetores é o que diz qual deles paga mais.
Por anos, o abuso de credenciais foi o vetor dominante, e a indústria respondeu na medida certa: a adoção de MFA e a maturidade em gestão de identidade cresceram. O DBIR 2026 mostra o efeito dessa correção e a contrapartida que veio com ela.
A virada: de credenciais para vulnerabilidades
Segundo o DBIR 2026, a exploração de vulnerabilidades subiu para 31% como vetor de acesso inicial, enquanto o abuso de credenciais, líder anterior, recuou para 13%. O material de divulgação que acompanha o relatório registra esse 31% como um salto de 55% em relação ao ano anterior.
O ponto central não é o número isolado de um único ano, e sim a trajetória. A série histórica apresentada na Figura 4 do relatório mostra as duas curvas se cruzando por volta de 2024: o abuso de credenciais em queda consistente, a exploração de vulnerabilidades em ascensão sustentada. Se trata de uma inversão estrutural de tendência. O padrão de System Intrusion, que tem na exploração de vulnerabilidades um de seus principais motores, responde sozinho por 61% das violações no dataset de 2026, contra 53% no ano anterior e 36% dois anos antes.
Fonte: Verizon, 2026 Data Breach Investigations Report.
Para um leitor na América Latina, o dado é ainda mais agudo. Nos recortes regionais do DBIR, a exploração de vulnerabilidades aparece como vetor de acesso inicial em 44% das violações na região da América Latina e Caribe (LAC), bem acima da média global de 31%, com 74% das violações envolvendo terceiros. A porta de entrada que mais cresce no mundo é, na nossa região, ainda mais larga.
Fonte: Verizon, 2026 Data Breach Investigations Report.
Fonte: Verizon, 2026 Data Breach Investigations Report.
Diante de "exploração de vulnerabilidades é o vetor nº1", a reação natural é "então precisamos corrigir as vulnerabilidades mais rápido". O problema é que os dados do próprio DBIR mostram que as organizações já estão tentando isso e estão perdendo.
Três números do relatório descrevem essa derrota com precisão:
Apenas 26% das vulnerabilidades críticas (aquelas presentes no catálogo Known Exploited Vulnerabilities, ou KEV, da CISA, ou seja, falhas com exploração ativa comprovada) foram totalmente remediadas pelas organizações em 2025. No ano anterior, esse número era 38%. A taxa de correção das falhas mais perigosas regrediu.
O tempo mediano para resolução completa subiu para 43 dias, quase duas semanas a mais que os 32 dias do ano anterior. E, no caso mediano, as organizações tinham 50% mais vulnerabilidades críticas para corrigir do que no período anterior.
Coloque os três juntos e o quadro fica evidente: o volume de falhas críticas cresce mais rápido do que a capacidade de corrigi-las, e cada falha leva mais tempo para ser fechada. Essa é a definição de uma corrida que se perde por construção. Adicionar mais esforço de remediação a um fluxo que já não dá conta do volume atual não inverte a curva, apenas adia marginalmente o momento em que a fila transborda.
A pergunta correta, portanto, não é "como corrigir mais rápido", mas "por que existem tantas falhas críticas para corrigir em primeiro lugar".
Newsletter Getup.
Atualizações sobre Kubernetes e Software Supply Chain Security todos os meses.
A origem estrutural do volume
Aqui está a observação que conecta o dado do DBIR à tese do Quor: a maior parte das CVEs que aparecem na fila de remediação de uma equipe não vem do código da aplicação. Vem da imagem base sobre a qual a aplicação roda.
Um exemplo concreto, que detalhamos em artigo anterior desta série: a imagem oficial node:22, alias de node:lts e escolha padrão de milhares de equipes, é construída sobre buildpack-deps, uma imagem de propósito geral. O resultado são cerca de 661 pacotes instalados, incluindo Python, GCC, Make e dezenas de bibliotecas de desenvolvimento, nenhuma delas necessária para executar uma aplicação Node.js em produção. Esses pacotes traduzem-se em aproximadamente 900 CVEs reportadas por scanners. Uma variante distroless equivalente, com menos de 10 pacotes, parte de praticamente zero CVEs reportadas.
A diferença é de uma ordem de grandeza e ela revela a natureza do problema: a fila de remediação está inflada por componentes que nunca deveriam estar na imagem. A equipe gasta seu tempo de patch (os mesmos 43 dias medianos que o DBIR mede) triando e corrigindo vulnerabilidades em código que a aplicação não executa.
Cada componente presente na imagem é um ponto de entrada potencial e, simultaneamente, mais uma linha na fila de remediação. Reduzir a superfície de ataque é a forma estrutural de reduzir o volume de falhas que precisam ser corrigidas. Uma imagem que contém apenas o binário da aplicação e as bibliotecas estritamente necessárias não tem as CVEs "resolvidas": ela simplesmente não contém a maioria dos componentes vulneráveis.
A leitura do Quor: prevenção na base
Se o vetor de acesso que mais cresce é a exploração de falhas conhecidas em componentes de software, e se a capacidade de remediação reativa está estruturalmente atrás do volume, a resposta racional é reduzir o volume na origem e remover o ruído que consome o tempo de quem corrige. O Quor opera sobre três frentes complementares, cada uma endereçando uma parte do problema que o DBIR documenta:
Redução estrutural da superfície de ataque: as imagens partem de bases minimalistas, Alpine e distroless, que removem shells interativos, gerenciadores de pacote e utilitários de sistema. Menos componentes significam, ao mesmo tempo, menos pontos de entrada para exploração e uma fila de remediação ordens de magnitude menor. Como efeito secundário relevante diante de um vetor de acesso via software, a ausência de shell e de package manager limita drasticamente o que um atacante consegue fazer mesmo que explore com sucesso a aplicação.
Fechamento da janela de exposição via build a partir da fonte: mesmo com poucos pacotes, existe um intervalo entre a correção de uma falha no projeto upstream e a chegada dessa correção à imagem em produção, atravessando o empacotamento da distribuição e a reconstrução das imagens intermediárias. Rastreando seis vulnerabilidades de alto impacto entre 2021 e 2024, observamos que, mesmo nos casos de melhor coordenação, as imagens de container permaneceram expostas de uma a quatro semanas. No pior cenário, meses. Compilando diretamente do código fonte upstream, o Quor inclui a correção a partir do commit que já a contém, sem aguardar o ciclo de release da distribuição. Isso ataca diretamente a métrica de tempo que o DBIR mede.
Separação de risco real de ruído via VEX: parte expressiva dos 43 dias medianos de remediação é gasta investigando vulnerabilidades que não são exploráveis no contexto específico do artefato, ou seja, falsos positivos estruturais de scanner. O VEX (Vulnerability Exploitability eXchange) permite declarar formalmente, com justificativa técnica auditável, que determinada CVE não afeta a imagem porque o código vulnerável não está presente ou não é alcançável em runtime. Cada imagem do catálogo é distribuída com seu documento VEX vinculado ao digest, de modo que o pipeline do cliente deixa de ser interrompido por ruído e o tempo de engenharia volta para onde deveria estar.
Conclusão
O dado do DBIR 2026 descreve uma inversão de tendência com consequências diretas para a alocação de recursos de segurança: a principal porta de entrada deixou de ser a credencial roubada e passou a ser a falhas no software/aplicações. E o mesmo relatório mostra que a resposta convencional a essa porta, remediar mais, está perdendo terreno, com a taxa de correção de falhas críticas em queda e o tempo de resolução em alta.
Quando o vetor que mais cresce está na composição daquilo que se executa, a resposta proporcional está na composição: reduzir estruturalmente o número de componentes, compilar a partir da fonte para fechar a janela de exposição e contextualizar vulnerabilidades para eliminar ruído não são otimizações marginais de pipeline.
Referências
2026 Data Breach Investigations Report (DBIR), Verizon. https://www.verizon.com/business/resources/reports/dbir
2026 Breach Impact Study (BIS), Verizon. https://www.verizon.com/business/resources/reports/dbir
CISA Known Exploited Vulnerabilities (KEV) Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
State of the Software Supply Chain 2026, Sonatype.
Como estamos construindo imagens com zero CVEs #1: reduzindo a superfície de ataque (Alpine e distroless). https://quor.dev
Como estamos construindo imagens com zero CVEs #2: compilando da fonte. https://quor.dev
Como estamos construindo imagens com zero CVEs #3: separando vulnerabilidade real de ruído (VEX). https://quor.dev
Operating Kubernetes in production for more than 13 years. With Quor, this experience extends to software supply chain security as well.
GET UP
© Getup · 2026
