Software

Security teams shorten patch windows as software supply-chain risk rises

Buyers are rewriting procurement contracts and vendors are compressing disclosure timelines as exploited vulnerabilities in third-party components become the dominant breach vector.

Written by Iris Vale · Bureau Tech · May 30, 2026

The most surprising shift: buyers are now setting patch deadlines

For most of the past decade, vulnerability response timelines were set by vendors. That is changing. Enterprise procurement teams—particularly in financial services, healthcare, and critical infrastructure—are inserting patch-response service-level agreements (SLAs) directly into software contracts, requiring vendors to issue fixes for critical Common Vulnerabilities and Exposures (CVEs) within 14 days or fewer.

A CVE is a standardized identifier assigned to a publicly disclosed security flaw. Critical CVEs carry a CVSS (Common Vulnerability Scoring System) score of 9.0 or above, indicating high exploitability and potential impact.

This buyer-driven pressure is a structural response to a documented pattern: attackers are increasingly targeting the software supply chain—the libraries, build pipelines, and third-party components that ship inside products—rather than attacking end organizations directly.

What the supply-chain threat model actually looks like

A software supply-chain attack works by compromising something upstream. The attacker may inject malicious code into an open-source library, compromise a vendor's build system, or exploit a vulnerability in a widely used component before the vendor patches it. Every organization that ships or runs software containing that component becomes a potential victim.

The 2020 SolarWinds breach, in which attackers inserted a backdoor into a network-monitoring software update, demonstrated the scale of this vector: roughly 18,000 organizations downloaded the compromised update. The 2024 XZ Utils incident showed the same logic applied to open-source infrastructure: a malicious contributor spent nearly two years gaining trust in a compression library used across Linux distributions before inserting a backdoor.

Neither attack required breaking into the ultimate targets directly.

SBOMs: the inventory requirement gaining traction

A software bill of materials (SBOM) is a machine-readable list of every component, library, and dependency included in a software product, along with version numbers and known vulnerabilities. The concept is analogous to an ingredient list on packaged food.

U.S. Executive Order 14028, signed in May 2021, directed federal agencies to require SBOMs from software vendors as a condition of procurement. The Cybersecurity and Infrastructure Security Agency (CISA) subsequently published minimum SBOM elements and has tracked voluntary adoption across sectors.

Private-sector adoption is uneven. Large enterprises with dedicated security teams are beginning to require SBOMs in vendor contracts. Smaller buyers often lack the tooling to ingest and act on SBOM data even when they receive it—a gap that limits the practical value of the requirement.

The patch-gap problem

Faster disclosure is not straightforwardly safer. Security researchers use the term 'patch gap' to describe the window between public disclosure of a vulnerability and the availability of a working fix. If a vendor discloses a critical CVE before a patch exists—whether due to regulatory pressure, coordinated disclosure timelines, or a leak—attackers can begin exploiting it immediately.

The tension is real: the 90-day coordinated disclosure standard popularized by Google Project Zero was designed to pressure vendors into patching while giving them time to do so before details became public. Compressing that window further, as some buyers now demand, may accelerate exploitation of vulnerabilities that vendors have not yet fixed.

What is not yet established in published research is whether organizations that achieve shorter MTTP targets experience statistically fewer successful breaches, or whether the relationship is confounded by attacker behavior—specifically, a shift toward zero-day exploits for which no patch exists at the time of attack.

What vendors are changing

Several large software vendors have published updated vulnerability disclosure policies in the past two years, shortening their internal triage-to-patch targets and expanding their bug bounty programs to cover supply-chain components. Some have begun publishing SBOMs for major products voluntarily, ahead of regulatory requirements.

Smaller vendors, particularly those supplying specialized enterprise software, face a harder tradeoff: faster patch cycles require engineering resources that may not be available, and contractual patch SLAs can create legal liability if timelines slip.

What remains unknown

Several important questions do not yet have clear answers in the public record:

- Whether SBOM requirements at scale reduce breach rates, or primarily shift liability. - Whether compressed patch windows reduce attacker success or accelerate exploitation of disclosed-but-unpatched vulnerabilities. - How open-source maintainers—often unpaid volunteers—are expected to meet commercial patch-response SLAs imposed by downstream buyers. - Whether the XZ Utils-style long-term infiltration of open-source projects can be detected systematically, or whether it represents a threat model that SBOM and patch-window requirements do not address.

The structural shift in how buyers and vendors negotiate vulnerability response is real and documented. Whether it produces measurable security improvement is a question the industry has not yet answered.

Key takeaways

Mean-time-to-patch (MTTP) targets at large enterprises have compressed from 30–60 days to under 14 days for critical CVEs, according to multiple published incident-response benchmarks.
Software bills of materials (SBOMs)—machine-readable inventories of every component in a software product—are now required in U.S. federal procurement under a 2021 executive order and are spreading into private-sector contracts.
Supply-chain attacks, which compromise a vendor or dependency rather than the target directly, accounted for a significant share of high-impact breaches in recent years, including the SolarWinds and XZ Utils incidents.
Vendors face competing pressures: faster disclosure satisfies buyers and regulators but can expose customers before patches are ready, a tension security researchers call the 'patch gap.'
Unknown: whether compressed patch windows meaningfully reduce breach rates, or whether attackers simply pivot to zero-day exploits that no patch window can address.

FAQ

What is a software bill of materials (SBOM) and why does it matter for security?

An SBOM is a machine-readable inventory of every component, library, and dependency in a software product, including version numbers. It matters for security because it allows buyers to check whether a product contains components with known vulnerabilities (CVEs) and to assess supply-chain risk before purchasing or deploying software. U.S. federal procurement now requires SBOMs from software vendors under Executive Order 14028.

What is a software supply-chain attack?

A supply-chain attack targets something upstream of the ultimate victim—a shared library, a build tool, a vendor's update mechanism—rather than attacking the target organization directly. Because many organizations use the same components, a single compromise can affect thousands of downstream users simultaneously. The SolarWinds and XZ Utils incidents are widely cited examples.

What is the 'patch gap' and why is faster disclosure not always safer?

The patch gap is the period between public disclosure of a vulnerability and the availability of a working fix. If a vulnerability is disclosed before a patch exists, attackers can begin exploiting it immediately. Regulatory and contractual pressure to disclose faster can widen this gap if vendors cannot develop fixes quickly enough, potentially increasing short-term risk even as it improves long-term accountability.

What is a CVE and how is severity measured?

CVE stands for Common Vulnerabilities and Exposures—a standardized identifier assigned to publicly disclosed security flaws. Severity is measured using the CVSS (Common Vulnerability Scoring System), which scores vulnerabilities from 0 to 10. Scores of 9.0 and above are classified as critical, indicating high exploitability and potential for significant damage.

Are open-source maintainers required to meet commercial patch-response SLAs?

Not formally. Open-source maintainers are typically volunteers with no contractual relationship with downstream commercial buyers. When enterprises insert patch-response SLAs into vendor contracts, those obligations fall on the commercial vendor, not the upstream open-source project. How vendors manage that gap—whether by funding maintainers, forking projects, or accepting liability—is an unresolved structural question in the industry.

Citations

Executive Order 14028 on Improving the Nation's CybersecurityU.S. federal agencies are directed to require software bills of materials (SBOMs) from software vendors as a condition of procurement.
CISA SBOM Resources and Minimum Elements GuidanceCISA published minimum SBOM elements and tracks voluntary adoption of SBOM practices across sectors.
Google Project Zero: Rethinking the 90-Day Disclosure DeadlineThe 90-day coordinated disclosure standard is designed to pressure vendors into patching while giving them time to develop fixes before vulnerability details become public.
CISA Advisory: SolarWinds Orion Supply Chain CompromiseThe SolarWinds breach involved a backdoor inserted into a software update, affecting approximately 18,000 organizations that downloaded the compromised build.
XZ Utils Backdoor: Technical Analysis and Timeline (Openwall)The XZ Utils incident involved a malicious contributor spending nearly two years gaining trust in an open-source compression library before inserting a backdoor targeting Linux distributions.