The standard security playbook for a new CVE looks something like this: the CVE is published, your environment is assessed, and the results are reviewed. This playbook assumes there is adequate time between disclosure and exploitation, which is increasingly less guaranteed.  

Why zero-day exploitation now outpaces vulnerability scanning

Google Cloud’s threat intelligence team, Mandiant, tracks this shift directly in its M-Trends 2026 report. The estimated mean time to exploit a vulnerability is now negative seven (-7) days. That’s not a typo–on average, exploitation is now happening before a patch is even released, let alone before a scan finds it. CrowdStrike’s 2026 Global Threat Report reports that 42% of vulnerabilities were exploited before public disclosure. In combination, these two reports describe the same shift from two different vantage points–the time between “a vulnerability exists” and “a vulnerability is being exploited” has shrunk to nothing, and in a lot of cases it’s become negative.

A recent, live example solidifies the reality. On July 14, 2026, Microsoft shipped a Patch Tuesday fix for CVE-2026-58644, a critical (CVSS 9.8) deserialization vulnerability in on-premises SharePoint Server. CISA added it to the Known Exploited Vulnerabilities catalog on July 16 (just 2 days later), after Microsoft confirmed it had already been exploited in the wild as a zero-day. This means attackers were exploiting the vulnerability before the fix even shipped. Even Federal agencies had until July 19 to patch. Organizations using on-premises SharePoint needed exposure confirmed in hours, well ahead of typical patch timelines.

That is where on-demand scanning falls short. If finding answers depends on running a new scan, the window for timely remediation has already passed.

Querying your SBOM inventory for a zero-day CVE

The solution isn’t faster scanning–it’s eliminating the need to trigger a fresh scan altogether. If you’re generating and storing SBOMs continuously, like we explain in the first two posts in this series, the vulnerability data already exists. The zero-day workflow in Anchore Enterprise is about querying that inventory, not rescanning it.

The first step is critical–before you trust any result, confirm your vulnerability feed is current by checking the “Data Service Build Time” field in your list of feeds.

anchorectl feed list

Queries mean nothing if the underlying data is old. If your vulnerability feed isn’t synced, your results are already obsolete.

If a CVE record already exists, the fastest path is searching by vulnerability ID through Anchore Enterprise’s reporting. The documentation’s own worked example is CVE-2025-1974, the “IngressNightmare” vulnerability in ingress-nginx, a Kubernetes admission controller used widely enough that the CVE carried real urgency the moment it was disclosed. You can search by the CVE ID directly, or by its GitHub Security Advisory identifier (GHSA-mgvx-rpfc-9mpv), which matters because during a genuine zero-day, the CVE record itself may lag behind other advisory sources.

CVE_ID="CVE-2025-1974"
curl -X 'GET' -H 'accept: application/json' \
"https://my-anchore.example.com/v2/query/vulnerabilities?id=$CVE_ID"

But a real zero-day sometimes has no vulnerability record at all yet, only a known-bad package and version. That’s the case the Query API is built for–searching by package name and version instead of waiting for an identifier to exist.

PACKAGE='ingress-nginx'
VERSION='1.11.4'
curl -X 'GET' -H 'accept: application/json' \
"https://my-anchore.example.com/v2/query/images/by-package?name=$PACKAGE&version=$VERSION"

Searching by package catches what CVE searches miss—exposure to malicious code before an official vulnerability record is logged. In order to automate this process, check out our post on chasing zero-day vulnerabilities via the Anchore Enterprise API. It details how to map a CVE ID to every affected image in your fleet using just a few API calls. 

Furthermore, scope is flexible. You can query against a single account or across every account in the deployment. This can determine if only a single team is affected, or if the vulnerability is more widespread. This is the advantage of using a single Anchore Enterprise deployment across multiple business units. And because new images are constantly being built, reports can be saved and scheduled for continuous monitoring rather than relying on a single point-in-time query.

The outcome: zero-day exposure answered in minutes, not a scan cycle

To recap, scanning after CVE disclosure relies on a grace period that no longer exists. The SharePoint example above had that window measured in days, and Mandiant’s data suggests the average case is now measured in negative days.

The technical benefit is turning “are we affected” into a query against data you already have, answered in the time it takes to run a report rather than the time it takes to complete a scan. The business benefit is being able to give a specific, confident answer during the exact window when a zero-day is most dangerous, instead of joining a multi-day queue of teams still waiting on scan results.

We help many organizations prepare for zero-days, but one Log4j story stands out. As Josh Bressers, Anchore’s VP of Security, explained it during a webinar on rapid incident response to zero-day vulnerabilities–one Anchore Enterprise customer already had their entire infrastructure represented as stored SBOMs when Log4j hit. Instead of a manual, fleet-wide audit, their team ran a single query against existing data and had their answer in the time it takes to run a report, not the days or weeks an initial audit typically takes.

This is the same workflow Anchore Enterprise users rely on once a new CVE lands. Our zero-day quickstart covers both search methods—by vulnerability ID and package version—plus query scoping and automated reporting. Evaluating your zero-day readiness? Request a demo and bring your last significant CVE response to the conversation.

This is the third post in this series. Post 2 covered what your registry scan misses once images reach your Kubernetes cluster. Next up: how the same SBOM, runtime, and vulnerability data map onto the controls needed for a federal Authority to Operate.