Vendor Security Disclosure Programmes

Vendor security disclosure programmes , commonly called vulnerability disclosure programmes (VDP) or bug bounty programmes , are the mechanisms through which external security researchers and customers report discovered vulnerabilities to software vendors. A mature, well-run disclosure programme provides early warning of vulnerabilities before public disclosure, an organised remediation process that produces patches within the coordinated disclosure timeline, and communication to affected customers that enables them to implement workarounds or plan for patch deployment before the vulnerability is publicly known. A nominal disclosure programme that acknowledges reports but does not remediate within the coordinated disclosure timeline provides researchers, customers, and eventually attackers with a published critical vulnerability and no patch.

The coordinated disclosure timeline is the industry norm that governs the relationship between security researchers and vendors. The dominant norm , established by Google Project Zero and broadly adopted , is 90 days from private notification to public disclosure, after which the researcher may publish regardless of patch availability. Some researchers allow extensions for complex vulnerabilities. The vendor who receives a critical vulnerability report has approximately 90 days to develop and release a patch before the vulnerability is published to the security community , including to threat actors who monitor vulnerability disclosures. A vendor who cannot remediate critical vulnerabilities within 90 days is a vendor who will regularly deliver unpatched critical vulnerabilities to customers at the point of public disclosure.

The customer notification gap is the operational failure in the hook scenario. Even vendors who patch within the coordinated disclosure timeline frequently fail to notify enterprise customers in advance of public disclosure , providing customers no opportunity to apply workarounds or prepare for emergency patch deployment before the vulnerability becomes publicly known. Advance customer notification , alerting affected customers to the vulnerability and available patch before public disclosure , is the practice that gives enterprise security teams the preparation time that simultaneous public disclosure does not.

Why this matters

Vendor security disclosure programmes matter for TPRM because they determine how quickly vulnerabilities in vendor software are discovered, remediated, and communicated to customers. A vendor with a mature, well-executed disclosure programme provides better supply chain security than one with a nominal programme that fails to execute , regardless of their respective marketing claims about security programme maturity.

• Disclosure programme existence accepted without quality assessment
• Patch timeline adherence not assessed , does vendor patch within 90 days
• Advance customer notification not included in vendor assessment
• Coordinated disclosure timeline compliance not tracked
• Bug bounty scope not assessed , what vulnerability categories are covered

What good looks like

Mature vendor disclosure programme assessments ask about patch timeline adherence , what percentage of critical vulnerabilities are patched within the coordinated disclosure window , and advance customer notification practices , do customers receive advance notice before public disclosure?

• Patch timeline adherence data , percentage of critical CVEs patched within 90 days
• Advance customer notification , do enterprise customers receive pre-disclosure notice
• Programme scope , what vulnerability categories are in scope
• Researcher participation metrics , programme health indicator
• Historical disclosure timeline analysis , how has the vendor performed historically

Tooling

Disclosure Programme Assessment , Disclose.io for programme standards; HackerOne, Bugcrowd for programme quality signals

Security researcher community reputations for vendor disclosure programmes , how quickly vendors respond, whether they patch within timelines, and whether they communicate appropriately , provide programme quality signals that published policies do not. Checking researcher community feedback on major bug bounty platforms provides supplementary quality assessment alongside official programme documentation.

Governance challenges

The governance challenge with disclosure programme assessment is the empirical data availability. Historical patch timeline compliance , how the vendor has actually performed on disclosed vulnerabilities , requires analysing past CVE disclosures against patch release dates, which is feasible but labour-intensive. The governance resolution is focusing historical analysis on the vendor's most critical vulnerabilities and supplementing with programme quality indicators from the researcher community.

• Ask about patch timeline adherence , percentage of critical CVEs patched within 90 days
• Ask about advance customer notification practice
• Review historical disclosure timeline for notable critical vulnerabilities
• Include disclosure programme maturity in vendor software security assessment
• Require advance notification commitment for critical vulnerability disclosures in vendor contract

If you are a small team

For your three most critical software vendors, look up their last three publicly disclosed critical vulnerabilities. Note when each was reported (if public), when the patch was released, and when the vulnerability was publicly disclosed. Calculate the patch timeline for each. If the vendor consistently patches within the 90-day coordinated disclosure window, their disclosure programme is functioning. If they regularly miss the window, researchers will increasingly bypass the programme and publish unpatched vulnerabilities , which is the scenario that exposes your enterprise without advance notice.

• Look up last three critical CVEs for top software vendors , patch timeline analysis
• Ask about advance customer notification for critical disclosures
• Require advance notification commitment in vendor contracts
• Include disclosure programme adherence in vendor reassessment

What to require

Ask directly:

"What percentage of critical vulnerability reports submitted to your disclosure programme are patched within the coordinated disclosure timeline , and do you provide advance notification to enterprise customers before a critical vulnerability is publicly disclosed?"

Expect as evidence

• Patch timeline adherence data for critical disclosures
• Advance customer notification process and timeline
• Disclosure programme scope and contact information
• Most recent critical disclosure handling as case study

A vendor who confirms a security disclosure programme should be asked about patch timeline adherence and advance customer notification. Programme existence is the starting point. Patch timeline adherence and advance notification determine whether the programme delivers the supply chain security value it is supposed to provide.

How to evidence it

• Disclosure programme quality assessment records
• Historical patch timeline analysis
• Advance notification requirement in vendor contract
• Disclosure programme assessment in vendor review

Key Takeaway

Disclosure programme: published and confirmed. Report submitted. Acknowledged. 7 months: vulnerability published publicly, no patch. Enterprise customers: zero advance notice. The programme existed. The process inside it failed the coordinated disclosure timeline. Researchers publish when the timeline passes , they have no alternative. Enterprises get the vulnerability published simultaneously with the full security community including threat actors. Patch timeline adherence data tells you whether the vendor's programme delivers or just exists. Advance notification commitment gives enterprise customers the preparation window that simultaneous public disclosure eliminates.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security