When a CVE is published, the vulnerability has already existed for some time. The gap between discovery and public registration—the disclosure gap—is a period when scanners show nothing, SLAs are not triggered, and the environment seems clean. In this article, Heitor Gouvêa documents four real cases of responsible disclosure and what this gap means in practice for those managing risk.
Security Researcher
Heitor Gouvêa
In February 2026, I reported four vulnerabilities in widely used tools within the security and infrastructure ecosystem, all discovered and submitted in the same week. One of them, Syft, has already been fixed, with a registered CVE and public advisory. The other three remain unresolved: a secrets management tool, a continuous delivery controller, and a log aggregator. The actual names of these projects will not be disclosed in this article while the vulnerabilities remain open. The full advisories, with complete timelines and project identification, will be published as soon as each case is resolved.
This process led me to revisit a common assumption in vulnerability management programs: that the publication date of a CVE represents the beginning of the exposure. It does not. And the difference between that date and the actual moment of exposure has direct implications on how organizations measure and manage risk.
The responsible disclosure process and its stages
Responsible disclosure follows a known workflow: discovery, private report to the vendor, confirmation, fix development, release, and coordinated publication with the CVE registration. Each stage takes its own time, and none of them is instantaneous.
The Syft case illustrates this workflow well. Syft is an Anchore tool for generating SBOMs from container images, used by projects like Docker, Grafana, and Cilium. The vulnerability found is of medium severity and was reported via GitHub Security Advisories.
The full timeline was:
February 13: vulnerability discovered and reported to Anchore via GitHub Security Advisories
February 19: confirmed by the security team
March 19: fix released
March 20: advisory published (GHSA-rjcw-vg7j-m9rc)
March 26: CVE automatically requested by GitHub's system
From report to fix: 34 days. The CVE was only requested 41 days after the initial report, by GitHub's automated system, not through the direct action of either party. Throughout this entire period, the vulnerability had no public identifier. Scanners reported zero CVEs. The environment appeared clean.
The other three cases have distinct dynamics worth noting, even without identifying the projects. The secrets management tool responded to the initial report and confirmed they will fix it, crediting the researcher in the bulletin. The process is underway. The continuous delivery controller received the report but did not respond to the subsequent follow-up. The most complex case was the log aggregator: the vulnerability is an RCE, and to get any response it was necessary to open an issue on GitHub, join the project's Slack channel, explicitly ask the maintainers to look at the report, and contact maintainers privately. The final response was that the fix will be made at some point in the future, with no date and no formal prioritization.
A reference case: IngressNightmare
The same pattern appears on a larger scale in the case of IngressNightmare, a set of vulnerabilities discovered by Wiz in the Ingress-NGINX Controller for Kubernetes. The CVEs involved, the primary one being CVE-2025-1974 with a CVSS of 9.8, allowed unauthenticated remote code execution in the controller and access to all cluster Secrets across all namespaces, with the potential of a complete environment takeover. Approximately 43% of cloud environments analyzed by Wiz were vulnerable, with over 6,500 clusters exposing the admission controller directly to the internet.
The timeline of the disclosure process was:
December 31, 2024: Wiz reported CVE-2025-1974 and CVE-2025-24514 to the Kubernetes security team
January 20, 2025: the other CVEs were reported
February 20, 2025: Kubernetes confirmed the resolution of CVE-2025-1974
March 10, 2025: embargo communicated to affected parties
March 24, 2025: public disclosure and CVEs registered
From discovery to public registration: 84 days. No scanner flagged anything because there was no CVE to flag.
Attempts to cover the gap: monitoring commits
The disclosure gap is well-known enough that tools already exist trying to cover it in an automated way. A recent example is vulnerabilityspoileralert.com, created by researcher Eugene Lim. The approach uses LLMs to monitor commits and diffs in open-source repositories and identify if a change represents the fix of a vulnerability not yet publicly disclosed. In February 2026, the tool detected two CVEs in Grafana, CVE-2025-41117 (XSS) and CVE-2026-21722 (privilege escalation), before any official publication, with at least an hour's lead time relative to the public disclosure.
The case is relevant for two reasons. First, it empirically confirms that the disclosure gap exists and has a measurable size: security commits become visible in the repository before any CVE is registered. Second, it raises a question about the responsible disclosure model itself: if an automated system can detect a security fix from the public diff, the coordination window between researcher and vendor becomes shorter than assumed. The period during which the vulnerability is technically exposed in the code, but still without a public identifier, becomes an additional risk vector that the traditional disclosure process does not directly address.
What remediation SLAs do not measure
SLA-based vulnerability management programs typically define deadlines starting from the CVE publication date: critical within 7 days, high within 30, and so on. This structure assumes that the publication date is the moment from which the risk begins. It is not.
Sonatype's State of the Software Supply Chain 2026 documented that in 2025 the median time for the NVD to assign a CVSS score to a CVE was 41 days, with cases reaching up to a year. Exploits and maintainer patches often appear within hours of discovery. This creates a gap where the vulnerability is technically known by some parties, but does not yet have a formal registry to trigger any automated remediation process.
This gap is related to a concept already established in the literature: the patch gap describes the time between the fix being available upstream and it reaching the production environment. What I am describing here is the previous layer: the disclosure gap, the period between discovery and the public registration of the CVE. During the disclosure gap, scanners do not report the vulnerability because they have no basis for doing so: the public identifier does not yet exist. This is neither a false positive nor a configuration noise; it is simply the absence of data in the system. The practical result is that audits pass with no findings, remediation SLAs are not triggered, and mean time to remediate metrics become disconnected from real exposure because the clock starts at the CVE publication, not at the existence of the vulnerability.
Implications for vulnerability management
SLA based on publication date remain useful as an operational mechanism. The problem is not the SLA itself, but the underlying premise that the publication date equates to the beginning of exposure.
Some practices that partially address this issue:
Monitor sources prior to the NVD: GitHub Security Advisories, OSV.dev, and upstream project security channels frequently publish information before the NVD processes and assigns a score. Tools that consume only the NVD are systematically lagging behind those that monitor the upstream directly.
Distinguish between absence of CVE and absence of risk: the attack surface of a system is defined by what exists in the code, not by what scanners can correlate with a vulnerability database. A component without a registered CVE may be in an active disclosure process or simply has not been audited yet.
Measure exposure time from the report, not the publication: the relevant data to understand real exposure is when the vulnerability was reported to the vendor, not when the CVE appeared on the NVD. This number rarely appears on security posture dashboards because it is rarely collected.
Treat the responsible disclosure process as part of the risk model: if the ecosystem relies on researchers reporting vulnerabilities privately before publishing, the response time of vendors and the quality of this process directly affect the size of the disclosure gap. A vendor that takes weeks to confirm a report is, in practice, extending the period of unmonitored exposure. A project that receives a report of an RCE and responds without a fix date is, in practice, choosing not to reduce this gap.
Observation on the four cases
I reported the four vulnerabilities because, upon finding them, it makes no sense to me not to report. The software ecosystem is maintained collectively, and this type of contribution is part of that. Anchore responded on the same day as the report, confirmed in six days, and released the fix in 34. The process worked within what is expected of a well-structured security disclosure program. The other three cases are documented. The full advisories, with project identification and detailed timelines, will be published as soon as each process is closed. The goal is not to publicly pressure resource-constrained open-source projects, but to record the real state of the disclosure gap in concrete cases: how much time exists between discovery and any public record, and what happens in systems that rely on these tools during this interval.
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
