Zero-day vulnerability response when the vulnerable code isn't yours
Geert WarmenbolApril 29, 2026
Key takeaways
67% of zero-day incidents Vulnox responded to in 2024 involved a component the organization could not patch unilaterally — vendor-managed software, SaaS platforms, or open source libraries embedded in third-party products. Standard incident response playbooks assume the organization controls the fix timeline. They do not account for waiting on a vendor.
The median time from zero-day public disclosure to vendor patch availability for SaaS-hosted software was 9 days in 2024. The median time from patch availability to organization-side mitigation was 6 days. The 15-day combined window is where most post-disclosure exploitation occurs (Vulnox incident response data, 2024).
Organizations that had documented compensating controls for their top 10 third-party software dependencies contained zero-day incidents 3.2x faster than those that relied on vendor patch timelines alone (Vulnox assessment data, 2024).
93% of intrusions Vulnox investigated leveraged known vulnerabilities — meaning only 7% required a true zero-day exploit. For most organizations, third-party zero-day exposure is a lower-probability risk than unpatched known CVEs in the same dependency chain (Vulnox assessment data, 2024).
Network segmentation is the single compensating control that most consistently limits zero-day blast radius when patching is not available. In 71% of Vulnox-assessed environments, segmentation gaps allowed lateral movement from an initial zero-day compromise to systems the zero-day did not affect.
TL;DR
Zero-day response advice assumes you can patch the vulnerable system. Most of the time, in a modern environment, you cannot — because the vulnerable code lives in a SaaS platform, a vendor product, or a transitive dependency three layers deep in your open source stack. The organizations that handle zero-days better are not the ones with better detection tooling. They are the ones that mapped their third-party dependencies before an incident started and knew what compensating controls to activate while they waited for someone else to ship a fix.
The incident where the patch never came from our side
A 180-person professional services firm running a major legal document management platform discovers anomalous API call patterns in their SIEM at 11pm on a Tuesday. The pattern matches early indicators of exploitation against a zero-day in the platform's underlying document parsing library — a vulnerability disclosed publicly six hours earlier. The firm's security team pulls up their incident response playbook. Step one: isolate the affected system. Step two: apply the vendor patch. The vendor's status page shows the patch is in development. Estimated availability: 72 hours. The firm has no compensating controls documented for this platform. It processes every client matter file in the organization. Isolating it stops business operations. Not isolating it means 72 hours of exposure on a system that processes privileged legal documents for 40 active client matters.
The incident response playbook was built for a world where the organization controls the patch timeline. At 11pm on a Tuesday, with a 72-hour vendor patch window and a system they could not take offline, the playbook was useless from step two onward. They had never mapped what they could do while waiting for someone else to fix the problem.
First-party zero-day response vs third-party zero-day response: different problem, different playbook
First-party zero-day (you control the vulnerable code)
The organization controls the patch timeline, the deployment process, and the ability to take the system offline for remediation. Compensating controls can include disabling the vulnerable feature, blocking the attack vector at the network layer, or deploying a hotfix before a full patch is available. Forensic access to the vulnerable system is direct — you can pull memory, inspect processes, review logs without vendor involvement. Containment decisions are made internally.
Standard zero-day response playbooks work here. Isolate, investigate, patch, restore. The bottleneck is internal execution speed, not external dependency. Organizations with mature patch management and incident response capabilities handle these well. The failure mode is process delay, not jurisdictional constraint.
Third-party zero-day (vendor, SaaS, or open source dependency controls the vulnerable code)
The organization cannot patch unilaterally. Patch timeline is controlled by a vendor whose incident response process, engineering capacity, and communication practices are outside the organization's control. Forensic access to the vulnerable system may be limited or unavailable — SaaS vendors do not typically provide memory access or detailed process logs during an incident. The organization can implement network-layer controls and disable integrations, but cannot modify the vulnerable code. Compensating controls must be pre-planned because there is no time to design them during the incident.
Standard zero-day response playbooks fail at step two. The organization is in a holding pattern between disclosure and patch availability, with limited visibility into what the vendor is doing and limited ability to contain exploitation without taking business-critical systems offline. Organizations that survive this window without significant impact had pre-mapped their compensating controls before the incident. Organizations that hadn't are negotiating business continuity while the vendor's engineering team works.
The numbers that change how you think about zero-day risk
67%
Percentage of zero-day incidents Vulnox responded to in 2024 where the exploited component was third-party software the organization could not patch unilaterally. The split was roughly even between vendor-managed on-premises software (28%), SaaS platforms (22%), and open source libraries embedded in third-party products (17%). In none of these cases did the organization's standard incident response playbook have a documented path for managing the vendor patch wait window (Vulnox incident response data, 2024).
15 days median combined exposure window
9 days median from zero-day public disclosure to vendor patch availability for SaaS-hosted software, plus 6 days median from patch availability to organization-side mitigation. This 15-day window is where post-disclosure exploitation concentrates. Organizations with pre-planned compensating controls reduced their effective exposure window to a median of 4 days by implementing network-layer controls within hours of disclosure, before the vendor patch was available (Vulnox incident response data, 2024).
3.2x faster containment
Organizations that had documented compensating controls for their top 10 third-party software dependencies achieved containment 3.2x faster than those relying on vendor patch timelines during zero-day incidents. The compensating controls were not sophisticated — they were primarily network segmentation rules, integration disablement procedures, and monitoring signatures specific to the vendor product. The advantage was not tooling; it was preparation (Vulnox assessment data, 2024).
7%
Percentage of intrusions Vulnox investigated that required a true zero-day exploit to succeed. 93% leveraged known, often patched, vulnerabilities. This matters for risk prioritization: third-party zero-day exposure is real but lower-probability than known CVE exposure in the same dependency chain. Organizations that obsess over zero-day detection while running 60-day patch cycles for known critical CVEs have inverted the risk priority (Vulnox assessment data, 2024).
214 days
Age of the oldest open critical CVE in a third-party component found in a Vulnox assessment of an organization that had purchased a dedicated zero-day detection platform 8 months earlier. The platform was scanning for novel exploit patterns. It had not been configured to alert on known CVEs in third-party dependencies. The oldest unpatched known vulnerability in their environment was older than the zero-day detection tool.
Why the jurisdiction gap makes standard response fail
Zero-day response has four phases: detect, contain, eradicate, recover. In first-party scenarios, all four phases are within the organization's control. In third-party scenarios, eradication — removing the vulnerable code — requires the vendor. This creates a structural problem: the organization is executing phases one and two (detect and contain) while waiting indefinitely for phase three. Contain means either taking the system offline, which has business impact, or leaving it running with compensating controls that reduce but do not eliminate exploitation risk. Neither is a good option. Both require decisions that standard playbooks don't provide guidance for.
Example
The SaaS case is the clearest illustration. An organization discovers that a SaaS platform they use for HR data processing has a zero-day in its API authentication layer. Exploitation could expose employee PII for 3,000 staff. The vendor confirms the vulnerability and estimates a 5-day patch window. The organization's options: disable the integration entirely, which stops payroll processing two days before pay day; leave it running with enhanced monitoring, accepting the risk; or attempt to restrict API access at the network layer, which requires mapping which systems legitimately call the API and blocking everything else. The third option is the right one. It takes 4 hours if you have a current integration map. It takes 2 days if you don't. Most organizations don't.
The integration map problem is why third-party zero-day preparedness starts with dependency documentation, not with detection tooling. An organization that knows exactly which internal systems call a given SaaS platform's API can implement network-layer blocks in hours. An organization that has to discover this during an incident while the clock runs on a disclosure window is in a fundamentally different position. Detection finds the problem. Documentation determines how fast you can contain it.
What incident response data shows that gap analysis data doesn't
Assessment base: Vulnox incident response engagements and gap analysis data, 2023-2024, across 83 client environments in professional services, fintech, healthcare, and SaaS companies.
Organizations with zero-day detection tooling had longer dwell times than those without, in third-party scenarios
In 12 of 19 third-party zero-day incidents Vulnox responded to, the organization had purchased dedicated zero-day or unknown-threat detection tooling. In 9 of those 12 cases, the tooling either did not cover the third-party platform or generated alerts that were not acted on within the critical window. Mean dwell time in organizations with the tooling: 11 days. Mean dwell time in organizations without the tooling but with documented compensating controls: 4 days.
Zero-day detection tools are built for environments where the organization controls the endpoint — where an EDR agent can be deployed, where process behavior can be observed. SaaS platforms and vendor-managed software do not support agent deployment. The tooling coverage gap is structural. Organizations buying detection tooling to solve third-party zero-day risk are solving for the wrong attack surface.
Open source dependency zero-days are the least-monitored and fastest-growing exposure category
In gap assessments of 64 organizations with software development functions, 51 had no systematic process for monitoring CVEs in open source dependencies embedded in third-party vendor products they used. They monitored their own code dependencies. They did not monitor dependencies introduced by their vendors. In 2024, 34% of significant zero-days disclosed affected open source components embedded in commercial software products, meaning the vendor's patch timeline depended on an upstream open source maintainer's release cycle (Vulnox assessment data, 2024; CVE tracking, 2024).
Software composition analysis for your own code does not cover open source components in your vendor's product. A vendor product built on a vulnerable version of a widely-used parsing library has a zero-day exposure that neither your SCA tooling nor your vendor's communication will surface until after public disclosure. The exposure exists in a jurisdiction neither party fully controls.
Segmentation is the only compensating control that consistently works while waiting for a third-party patch
Across all third-party zero-day incidents Vulnox responded to, network segmentation was the compensating control that most consistently limited blast radius during the vendor patch window. In environments with effective segmentation, exploitation of the zero-day did not reach adjacent systems in 78% of cases. In environments without effective segmentation, lateral movement from the initial compromise reached at least one unrelated system in 71% of cases — regardless of whether the zero-day itself was on a critical system.
Segmentation is the compensating control you deploy before you know the zero-day exists. It limits blast radius for every class of incident, not just zero-days. Organizations that defer segmentation because it is complex are accepting unlimited lateral movement as a consequence of every future third-party compromise. The complexity argument is real. The risk trade-off is rarely articulated clearly enough for leadership to understand what they are accepting.
What organizations say when third-party zero-day response fails
'We have an EDR on every endpoint. We should have caught this.'
Root cause:EDR agents run on systems you control. SaaS platforms, vendor-managed applications, and cloud services are not your endpoints. An EDR deployment that covers 100% of your managed devices covers 0% of your SaaS-hosted attack surface. The zero-day in the document management platform, the HR system, the collaboration tool — none of those generate EDR telemetry on your side. You see the network traffic. You do not see the process behavior. Organizations that measure EDR coverage as a percentage of managed devices and call it done have not assessed their actual detection coverage.
'We're a small company. We're not the target for zero-day attacks.'
Root cause:This is accurate and irrelevant simultaneously. You are not the target. The SaaS platform 40,000 companies use, including you, is the target. A zero-day in a widely-used HR platform is not directed at any specific company — it is directed at the platform. Every organization using that platform is exposed regardless of size, industry, or threat profile. Small companies that share SaaS infrastructure with large enterprises inherit the same third-party zero-day exposure with fewer resources to respond.
'Our vendor told us they had no evidence of exploitation. We assumed we were fine.'
Root cause:Vendors disclose what they can observe from their side. A SaaS vendor monitoring their infrastructure for exploitation indicators will detect exploitation patterns they are looking for — known attack signatures, anomalous API patterns in aggregate. They will not detect targeted exploitation of a single customer tenant using a novel technique that hasn't generated a detectable pattern at scale. 'No evidence of exploitation' means the vendor saw nothing. It does not mean nothing happened. Organizations that treated vendor reassurance as investigation closure and did not review their own logs from the disclosure window had no basis for that conclusion.
The third-party zero-day exposures that almost no one maps before an incident
Transitive open source dependencies in vendor products
Your SCA tooling scans your code. It does not scan the code inside vendor products you run. A commercial application built on a vulnerable version of a widely-used parsing library, JSON processor, or authentication library has a zero-day exposure that your tooling will not surface and your vendor may not communicate until public disclosure forces their hand. The Log4Shell incident in 2021 demonstrated this at scale — organizations discovered they were exposed through vendor products they had not audited for Log4j dependency. The next one will follow the same pattern. The organizations that respond faster will be those that had already asked their top 20 vendors for software bills of materials.
API integration maps
When a SaaS platform has a zero-day in its API layer, the fastest compensating control is restricting which internal systems can reach that API. This requires knowing which internal systems legitimately call it. Most organizations do not have a current integration map for their SaaS stack — they know which platforms they subscribe to, not which internal systems call which external APIs and on what schedule. Building this map during an incident takes days. Having it before the incident takes hours to implement network-layer blocks. This is purely a documentation problem, not a tooling problem.
Vendor incident response SLAs
Organizations negotiate SLAs for uptime and support response. Almost none negotiate SLAs for security incident communication and patch timelines. When a zero-day affects a vendor product, the organization learns about it when the vendor publishes a security advisory — which may be after public disclosure, may lack technical detail, and will not include a committed patch timeline. Organizations that have never asked their top vendors what their security incident communication process looks like will find out for the first time during an incident. Ask before you need the answer.
Forensic access rights in SaaS contracts
When a SaaS platform is the scene of a potential zero-day exploitation, the organization needs logs — API access logs, authentication logs, data access records for the disclosure window. Most SaaS contracts do not grant the customer the right to request logs for a specific investigation window on a defined timeline. Some vendors provide logs on request. Some provide partial logs. Some provide nothing beyond what is available in the standard admin console. Organizations that have not reviewed what forensic access their contracts allow will negotiate this during an incident, with a vendor whose legal team is simultaneously managing disclosure liability.
Backup integrity in the post-zero-day window
Restoring from backup after a zero-day incident requires confidence that the backup predates the exploitation. The restoration window depends on knowing when exploitation started — which requires log data from the affected system. For SaaS platforms, this means knowing what logs are available and what they show, before you need to make a restoration decision. Organizations that discover during recovery that their SaaS vendor retains logs for 30 days and their incident started 31 days ago have no verified clean restore point. Backup retention and log retention for third-party systems should be assessed together, not separately.
What to build before the next third-party zero-day disclosure
Requesting SBOMs from vendors. Organizations assume vendors will not provide them or that the request signals distrust. In practice, enterprise vendors with mature security programs provide SBOMs under customer request with less friction than expected, and the component data surfaces known CVE risk that is more immediately actionable than any zero-day preparation. The step is skipped because it requires procurement involvement and feels like a vendor management problem rather than a security problem. It is both.
- 1Security and procurement teams jointly
Build a tiered inventory of third-party software dependencies ranked by data sensitivity and integration depth. Tier 1: platforms with access to sensitive data and deep API integration. Tier 2: platforms with limited data access or shallow integration. For Tier 1 platforms, document what compensating controls exist if the platform is unavailable or must be isolated — which internal systems call it, what breaks if the integration is disabled, who makes the isolation decision and on what authority.
Expected outcomeA dependency map that tells your incident response team, at 11pm on the night of a disclosure, exactly what they can do without the vendor's involvement. This document has to exist before the incident.
- 2Security team
Request software bills of materials from your top 10 third-party software vendors. Frame it as a supply chain security requirement — many enterprise vendors now provide SBOMs under customer request. Cross-reference the component list against the NVD for known CVEs. Any vendor running a component with an unpatched critical CVE in their product is a known risk today, before any zero-day is involved.
Expected outcomeA vendor component risk register that surfaces known exposure in your third-party stack. The known CVE risk in vendor components is almost always larger than the zero-day risk. Fix the known problem first; it is also the foundation for monitoring the unknown one.
- 3Network and security teams
Implement egress filtering that documents and enforces which internal systems are permitted to reach which external SaaS endpoints. This is the technical implementation of the integration map. It serves two functions: it is the control you activate to restrict a compromised SaaS platform's reach, and it is the monitoring baseline that surfaces anomalous API call patterns before a disclosure event.
Expected outcomeNetwork-layer enforcement of your integration map that can be modified to restrict a specific external endpoint within hours of a disclosure. Without this, blocking a compromised SaaS integration requires ad hoc firewall rule creation during an incident — slower, error-prone, and incomplete.
- 4Legal and security teams
Review contracts with Tier 1 vendors for forensic access rights, security incident notification timelines, and log retention periods. Document what each contract provides and what it does not. Where contracts lack forensic access provisions, assess whether this is negotiable at next renewal. Where log retention is shorter than your incident discovery window, implement log forwarding from the vendor platform to organization-controlled storage — most enterprise SaaS platforms support SIEM integration that forwards logs in real time.
Expected outcomeA forensic readiness register for third-party platforms that tells your incident response team, before an incident, what evidence they can obtain and on what timeline. The worst moment to discover a contract does not provide log access is during active investigation.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisNVD Vulnerabilities Database
National Vulnerability DatabaseNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionCyber Threat Intelligence
cyber threat intelligence
Frequently Asked Questions
What do I do when a zero-day affects a SaaS platform I can't patch myself?
Your options depend on preparation. If you have a current integration map showing which internal systems call the platform's API, you can implement network-layer restrictions within hours that limit exploitation reach while you wait for the vendor patch. If you do not have this map, you are building it during the incident — which takes days, not hours. The immediate steps: review your own logs for anomalous API call patterns from the disclosure window; contact the vendor for their incident communication and ask specifically what logs they can provide and on what timeline; assess whether the platform can be operated in a restricted mode that disables the vulnerable feature; and document the business impact of full isolation so leadership can make an informed decision if the vendor patch window extends. Do not rely on vendor assurances of 'no evidence of exploitation' as a substitute for reviewing your own logs.
How do I detect zero-day exploitation in third-party software I don't control?
You cannot detect zero-day exploitation at the code level in software you don't control — no EDR agent, no process monitoring, no memory analysis. What you can observe is behavioral: anomalous API call patterns from the platform to external endpoints, unexpected data egress volumes, authentication events outside normal patterns, and internal systems receiving unexpected connections from the platform. This requires that you have a behavioral baseline for normal platform activity before the incident. Organizations that have not baselined their SaaS platform behavior have no reference point for anomalous behavior during a zero-day window. Network-level monitoring of SaaS egress and API call volumes, combined with SIEM alerts on deviation from baseline, is the detection layer available to you.
How long does it typically take to get a patch for a zero-day in vendor software?
Median time from public disclosure to patch availability for SaaS-hosted software was 9 days in 2024, based on Vulnox incident response data. For on-premises vendor software, patch availability varies significantly — some vendors ship emergency patches within 48 hours, others require a full release cycle that can run 30 days or longer. The variance is driven by vendor engineering capacity, the complexity of the fix, and whether the vulnerability affects a component the vendor controls or an upstream open source dependency. Organizations should ask their top vendors, before an incident, what their security patch release process looks like and what the fastest they have shipped an emergency patch is. This is a procurement question that most organizations have never asked.
What is a software bill of materials and why does it matter for zero-day risk?
A software bill of materials (SBOM) is a structured list of all components in a software product — libraries, frameworks, dependencies, and their versions. For zero-day risk, the SBOM tells you whether a disclosed vulnerability in an open source component affects a vendor product you run. Without the SBOM, you learn about this exposure when the vendor publishes a security advisory, which may be days after public disclosure. With the SBOM, you can cross-reference new CVE disclosures against your vendor components in near-real time. Requesting SBOMs from your top 10 vendors is the single highest-leverage preparatory action for third-party zero-day risk. Enterprise vendors with mature security programs provide them under customer request. The request is a supply chain security standard, not an unusual ask.
Why did my zero-day detection tool miss the exploitation?
Three common reasons. First, the tool had no coverage of the exploited platform — EDR agents and endpoint-focused detection tools do not cover SaaS platforms or vendor-managed software. Second, the tool detected anomalous behavior but generated an alert that was not reviewed within the critical window — in Vulnox incident response engagements, alert fatigue from untuned detection tools contributed to missed exploitation signals in the majority of cases where tooling was present. Third, the exploitation technique was novel enough that existing detection signatures did not match. The third reason gets the most attention and is the least common. The first two are operational failures, not detection capability failures.
What compensating controls work when I can't patch a zero-day immediately?
The controls that consistently limit blast radius during an unpatched zero-day window: network segmentation that prevents lateral movement from the compromised system to adjacent systems; egress filtering that restricts the compromised platform's ability to reach external endpoints used for data exfiltration; disabling specific integrations or API connections that use the vulnerable feature while leaving the platform partially operational; and enhanced monitoring on the compromised system's network behavior during the patch window. Web application firewalls with virtual patching capabilities can block known exploit patterns for some vulnerability classes before the vendor ships a fix — but this works only when the exploit technique is known, which is not always true at the time of disclosure.
How do I prioritize zero-day risk against other security investments?
Start with the base rate: 93% of intrusions leverage known vulnerabilities, not zero-days. An organization with a 60-day patch cycle for critical known CVEs has a larger, more certain exposure than its third-party zero-day risk. Fix the known problem first. For zero-day preparedness specifically, the highest-ROI investments are not detection tooling — they are dependency documentation (knowing what third-party software you run and what components it contains), integration mapping (knowing which internal systems talk to which external platforms), and network segmentation (limiting blast radius for any exploit class, not just zero-days). These investments serve every incident type. Zero-day-specific detection tooling serves one scenario and is often the most expensive option on the list.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.