Security Researcher
Heitor Gouvêa
Em fevereiro de 2026, reportei quatro vulnerabilidades em ferramentas amplamente utilizadas no ecossistema de segurança e infraestrutura, todas descobertas e enviadas na mesma semana. Uma delas, o Syft, já foi corrigida, com CVE registrada e advisory público. As outras três ainda não têm resolução: uma ferramenta de secrets management, um controller de continuous delivery e um aggregator de logs. Os nomes reais desses projetos não serão divulgados neste artigo enquanto as vulnerabilidades permanecem abertas. Os advisories completos, com timelines integrais e identificação dos projetos, serão publicados assim que cada caso tiver encerramento.
Esse processo me levou a revisitar uma premissa comum em programas de vulnerability management: a de que a data de publicação de uma CVE representa o início da exposição. Não representa. E a diferença entre essa data e o momento real de exposição tem implicações diretas sobre como organizações medem e gerenciam risco.
O processo de responsible disclosure e seus estágios
O responsible disclosure segue um fluxo conhecido: descoberta, report privado ao vendor, confirmação, desenvolvimento do fix, release, e publicação coordenada com o registro da CVE. Cada estágio tem seu próprio tempo, e nenhum deles é instantâneo.
O caso do Syft ilustra bem esse fluxo. O Syft é uma ferramenta da Anchore para geração de SBOMs a partir de imagens de container, usada por projetos como Docker, Grafana e Cilium. A vulnerabilidade encontrada é de severidade média e foi reportada via GitHub Security Advisories.
O timeline completo foi:
13 de fevereiro: vulnerabilidade descoberta e reportada à Anchore via GitHub Security Advisories
19 de fevereiro: confirmada pela equipe de segurança
19 de março: fix liberado
20 de março: advisory publicado (GHSA-rjcw-vg7j-m9rc)
26 de março: CVE requisitada automaticamente pelo sistema do GitHub
Do report ao fix: 34 dias. A CVE só foi requisitada 41 dias após o report inicial, pelo sistema automatizado do GitHub, não por ação direta de nenhuma das partes. Durante todo esse período, a vulnerabilidade não tinha identificador público. Scanners apontavam zero CVEs. O ambiente parecia limpo.
Os outros três casos têm dinâmicas distintas que vale registrar, mesmo sem identificar os projetos. A ferramenta de secrets management respondeu ao report inicial e confirmou que vai corrigir, creditando o pesquisador no bulletin. O processo está em andamento. O controller de continuous delivery recebeu o report mas não respondeu ao follow-up subsequente. O caso mais complexo foi o aggregator de logs: a vulnerabilidade é uma RCE, e para chegar a qualquer resposta foi necessário abrir a issue no GitHub, entrar no canal do Slack do projeto, pedir explicitamente que os mantenedores vissem o report, e contatar mantenedores no privado. A resposta final foi que a correção será feita em algum momento futuro, sem data e sem priorização formal.
Um caso de referência: IngressNightmare
O mesmo padrão aparece em escala maior no caso do IngressNightmare, conjunto de vulnerabilidades descoberto pela Wiz no Ingress-NGINX Controller para Kubernetes. As CVEs envolvidas, sendo a principal a CVE-2025-1974 com CVSS 9.8, permitiam execução remota de código não autenticada no controller e acesso a todos os Secrets do cluster em todos os namespaces, com potencial de tomada completa do ambiente. Aproximadamente 43% dos ambientes cloud analisados pela Wiz eram vulneráveis, com mais de 6.500 clusters expondo o admission controller diretamente à internet.
O timeline do processo de disclosure foi:
31 de dezembro de 2024: Wiz reportou CVE-2025-1974 e CVE-2025-24514 ao time de segurança do Kubernetes
20 de janeiro de 2025: as demais CVEs foram reportadas
20 de fevereiro de 2025: Kubernetes confirmou a resolução de CVE-2025-1974
10 de março de 2025: embargo comunicado aos envolvidos
24 de março de 2025: disclosure público e CVEs registradas
Da descoberta ao registro público: 84 dias. Nenhum scanner sinalizava nada porque não havia CVE para sinalizar.
Tentativas de cobrir o gap: monitoramento de commits
O disclosure gap é suficientemente conhecido para que já existam ferramentas tentando cobri-lo de forma automatizada. Um exemplo recente é o vulnerabilityspoileralert.com, criado pelo pesquisador Eugene Lim. A abordagem usa LLMs para monitorar commits e diffs em repositórios open source e identificar se uma mudança representa a correção de uma vulnerabilidade ainda não divulgada publicamente. Em fevereiro de 2026, a ferramenta detectou duas CVEs no Grafana, CVE-2025-41117 (XSS) e CVE-2026-21722 (escalação de privilégios), antes de qualquer publicação oficial, com pelo menos uma hora de antecedência em relação ao disclosure público.
O caso é relevante por dois motivos. Primeiro, confirma empiricamente que o disclosure gap existe e tem tamanho mensurável: commits de segurança ficam visíveis no repositório antes de qualquer CVE ser registrada. Segundo, levanta uma questão sobre o próprio modelo de responsible disclosure: se um sistema automatizado consegue detectar uma correção de segurança a partir do diff público, a janela de coordenação entre pesquisador e vendor passa a ser mais curta do que se assume. O período em que a vulnerabilidade está tecnicamente exposta no código, mas ainda sem identificador público, torna-se um vetor de risco adicional que o processo de disclosure tradicional não endereça diretamente.
Newsletter Quor
O que os SLAs de remediação não medem
Programas de vulnerability management baseados em SLA tipicamente definem prazos a partir da data de publicação da CVE: críticas em 7 dias, high em 30, e assim por diante. Essa estrutura pressupõe que a data de publicação é o momento a partir do qual o risco começa. Não é.
O State of the Software Supply Chain 2026, da Sonatype, documentou que em 2025 o tempo mediano do NVD para atribuir um CVSS score a uma CVE foi de 41 dias, com casos chegando a um ano. Exploits e patches de maintainers costumam aparecer em horas após a descoberta. Isso cria um intervalo em que a vulnerabilidade é tecnicamente conhecida por algumas partes, mas ainda não tem registro formal que acione qualquer processo automatizado de remediação.
Esse intervalo tem relação com um conceito já estabelecido na literatura: o patch gap descreve o tempo entre o fix estar disponível upstream e ele chegar ao ambiente de produção. O que estou descrevendo aqui é a camada anterior: o disclosure gap, o período entre a descoberta e o registro público da CVE. Durante o disclosure gap, scanners não reportam a vulnerabilidade porque não têm base para isso: o identificador público ainda não existe. Isso não é falso positivo nem ruído de configuração, é simplesmente a ausência do dado no sistema. O resultado prático é que auditorias passam sem apontamentos, SLAs de remediação não são ativados, e métricas de mean time to remediate ficam descoladas da exposição real porque o clock começa na publicação da CVE, não na existência da vulnerabilidade.
Implicações para vulnerability management
SLAs baseados em data de publicação continuam sendo úteis como mecanismo operacional. O problema não é o SLA em si, mas a premissa subjacente de que a data de publicação equivale ao início da exposição.
Algumas práticas que endereçam parcialmente esse problema:
Monitorar fontes anteriores ao NVD: o GitHub Security Advisories, o OSV.dev e os security channels dos projetos upstream frequentemente publicam informações antes do NVD processar e atribuir score. Ferramentas que consomem apenas o NVD estão sistematicamente atrasadas em relação a quem monitora o upstream diretamente.
Distinguir ausência de CVE de ausência de risco: a superfície de ataque de um sistema é definida pelo que existe no código, não pelo que os scanners conseguem correlacionar com um banco de dados de vulnerabilidades. Um componente sem CVE registrada pode estar em processo ativo de disclosure ou simplesmente ainda não ter sido auditado.
Medir tempo de exposição a partir do report, não da publicação: o dado relevante para entender exposição real é quando a vulnerabilidade foi reportada ao vendor, não quando a CVE apareceu no NVD. Esse número raramente aparece em dashboards de security posture porque raramente é coletado.
Tratar o processo de responsible disclosure como parte do modelo de risco: se o ecossistema depende de pesquisadores reportando vulnerabilidades privadamente antes de publicar, o tempo de resposta dos vendors e a qualidade desse processo afetam diretamente o tamanho do disclosure gap. Um vendor que demora semanas para confirmar um report está, na prática, estendendo o período de exposição não monitorada. Um projeto que recebe o report de uma RCE e responde sem data de correção está, na prática, escolhendo não reduzir esse intervalo.
Observação sobre os quatro casos
Reportei as quatro vulnerabilidades porque, ao encontrá-las, não faz sentido para mim não reportar. O ecossistema de software é mantido coletivamente, e esse tipo de contribuição é parte disso. A Anchore respondeu no mesmo dia do report, confirmou em seis dias e liberou o fix em 34. O processo funcionou dentro do que se espera de um programa de security disclosure bem estruturado. Os outros três casos estão documentados. Os advisories completos, com identificação dos projetos e timelines detalhadas, serão publicados assim que cada processo tiver encerramento. O objetivo não é pressionar publicamente projetos open source com recursos limitados, mas registrar o estado real do disclosure gap em casos concretos: quanto tempo existe entre a descoberta e qualquer registro público, e o que acontece nos sistemas que dependem dessas ferramentas durante esse intervalo.
Com o Quor, segurança vira vantagem competitiva. Descubra como em uma demo personalizada.