Vendor Patch Cadence Reality

Vendor patch cadence , the speed at which a software vendor identifies, develops, and releases patches for known vulnerabilities in their software , is one of the most important but least rigorously assessed dimensions of software supply chain security. TPRM questionnaires routinely ask vendors to state their patching SLAs: how quickly they commit to patching critical, high, medium, and low-severity vulnerabilities. Vendors routinely provide policy-level responses that describe their aspirational or stated commitment. What is rarely assessed is whether that stated commitment is actually met , whether the average time from vulnerability publication to patch release aligns with the policy, and whether all critical vulnerabilities are eventually patched.

The policy-versus-adherence gap is the core problem. A vendor who states a 30-day critical vulnerability patch SLA and achieves a 73-day average is not meeting their stated policy , but this will not be visible in a questionnaire that asks about the policy rather than measuring the adherence. The measurement requires looking at the vendor's actual release history and correlating it against published CVE timelines: when was the vulnerability published, when was the patch available, and is this consistent across the population of published vulnerabilities? This analysis is possible using public data , NVD publication dates, vendor release notes, and CVE tracking , but it requires effort that a standard questionnaire does not.

The unpatched vulnerability problem is the specific TPRM exposure. Critical vulnerabilities that are never patched represent a permanent risk for every enterprise running the affected software version. The vendor's 30-day patch policy does not address vulnerabilities that are not patched at all , it describes only the intended timeline for patches that are produced. Four of the vendor's fourteen critical vulnerabilities from the past year remain unpatched after the stated 30-day window. For the enterprises running those software versions, the vulnerability is not a 30-day or 73-day risk , it is a persistent risk with no scheduled remediation.

Why this matters

Patch cadence reality matters because the software your enterprise deploys continues to accumulate vulnerability risk between your initial assessment and your next planned vendor review. A vendor who patches slowly or incompletely is a vendor whose software becomes progressively more vulnerable over time. The enterprise that confirmed the vendor's 30-day patch policy without measuring its adherence is running software that is significantly more vulnerable than the policy confirmation implies.

• Patch policy confirmed without adherence measurement
• Average patch time not calculated from historical release and CVE data
• Unpatched vulnerabilities not identified , policy asks about SLA, not coverage
• Continuous patch monitoring absent , point-in-time policy confirmation only
• Deployed software version currency not tracked against latest patched release

What good looks like

Mature vendor patch cadence programmes measure actual patch adherence from historical data , calculating average time from CVE publication to patch release for the vendor's software, identifying unpatched vulnerabilities, and tracking the currency of the enterprise's deployed version against the latest patched release.

• Historical patch adherence analysis , CVE publication vs patch release timeline
• Unpatched vulnerability identification , CVEs for software with no patch
• Deployed version currency tracking , current version vs latest patched version
• Continuous patch monitoring , CVE monitoring for deployed software
• Patch SLA adherence metric , policy versus actual in vendor assessments

Tooling

Patch Monitoring , Vulncheck, Recorded Future for CVE publication and patch timeline analysis; Snyk for continuous deployed software monitoring

Vulnerability intelligence platforms provide CVE publication timelines and vendor patch release tracking , enabling calculation of patch cadence adherence from public data. For TPRM practitioners, calculating the average time from CVE publication to vendor patch release for a software product over the past twelve months is a specific, objective patch cadence measurement that policy statements cannot substitute for.

Governance challenges

The governance challenge with patch cadence assessment is the data collection effort. Calculating actual patch adherence from CVE and release data requires looking up historical CVE publication dates, finding the vendor's release notes that address each CVE, and calculating the delta. This is feasible for critical CVEs but labour-intensive for comprehensive analysis. The governance resolution is prioritising actual patch adherence analysis for critical software vendors and using automated vulnerability monitoring for continuous deployed software coverage.

• Calculate actual patch adherence for critical software vendors , not just policy
• Identify unpatched critical CVEs for deployed software
• Track deployed version currency , current deployment vs latest patched release
• Implement continuous CVE monitoring for deployed software
• Include patch adherence data in vendor reassessment alongside policy

If you are a small team

For your three most critical software vendors, look up the CVEs published for their software in the last twelve months and the patch release dates that addressed them. Calculate the average time between CVE publication and patch availability. Then check whether any critical CVEs have not been patched in a released version. That analysis , using NVD, MITRE CVE, and the vendor's release notes , will tell you whether the 30-day patch SLA is a description of practice or a statement of aspiration.

• Look up CVEs for top three software vendors in last 12 months
• Calculate average CVE publication to patch release timeline
• Identify unpatched critical CVEs
• Track deployed version currency against latest patched release

What to require

Ask directly:

"What was your average time from critical CVE publication to patch release in the last twelve months , and are there any critical CVEs published in the last twelve months for your software that have not yet been addressed in a released patch?"

Expect as evidence

• Historical patch timeline data , CVE publication vs patch release
• List of unpatched critical CVEs with remediation timeline
• Average patch cadence by severity
• Deployed version patch currency confirmation

A vendor who confirms a 30-day patch SLA should be asked for their actual patch adherence data. The policy describes the commitment. The historical data describes the performance. Both are needed to assess the actual risk of running that vendor's software.

How to evidence it

• Historical patch adherence analysis records
• Unpatched CVE tracking
• Deployed version currency monitoring
• Patch SLA adherence in vendor assessment

Key Takeaway

30-day patch SLA: confirmed. Average actual patch time: 73 days. Unpatched critical CVEs: 4 of 14. The policy was real. The adherence was not. The questionnaire asked about the policy. The patch timeline data revealed the adherence gap. Policy confirmation describes what the vendor intends. Historical adherence data describes what they deliver. For software supply chain risk, what they deliver determines the actual vulnerability exposure of the enterprise running their software , not what they intend to deliver.

More on Third-party oversight

• Build Pipeline Integrity
• Artifact Registry Security
• Supply Chain Attack Detection