A vulnerability disclosure program is a practical signal that a vendor expects unknown weaknesses to be discovered and has a safe process for receiving them. For TPRM, the important question is not whether a “Report a vulnerability” link exists. It is whether the vendor can intake, validate, prioritize, remediate, and communicate about reports without losing them in a support queue.
This guide explains how to assess vulnerability disclosure programs during vendor due diligence, which evidence matters, how VDPs differ from bug bounties, and what weak or missing practices mean for the risk decision.
Why vulnerability disclosure belongs in vendor due diligence
Software testing cannot find every defect before release. Researchers, customers, partners, and users may discover weaknesses after deployment. A VDP creates a clear path for good-faith reporting and reduces the chance that important information is ignored, mishandled, or disclosed chaotically.
NIST’s Secure Software Development Framework places vulnerability response in the software lifecycle. Practice RV.1.3 calls for a policy addressing vulnerability disclosure and remediation, supported by roles, responsibilities, and processes. CISA’s vulnerability disclosure guidance similarly emphasizes a public policy and operational capability, not merely a mailbox.
VDP, coordinated disclosure, and bug bounty are different
A vulnerability disclosure policy tells researchers what systems are in scope, how to report, what testing is permitted, what information to include, and what the organization commits to do. Coordinated disclosure is the process of working with the reporter on validation, remediation, and public communication. A bug bounty adds rewards under specified rules.
A vendor does not need a public bounty to demonstrate maturity. Many responsible programs begin with a clear VDP, security contact, triage process, and documented response targets. TPRM should avoid scoring a vendor poorly simply because it does not pay researchers. The control objective is reliable vulnerability intake and response.
Start with discoverability and safe reporting
A researcher should be able to find the reporting channel without guessing. Look for a security page, disclosure policy, dedicated form or monitored address, and a security.txt file where appropriate. RFC 9116 defines security.txt as a machine-readable way to publish security contact and policy information.
The policy should explain scope, prohibited actions, data-handling expectations, report content, communication methods, and good-faith assurances. It should not threaten researchers for accidental, non-destructive activity that follows the policy. Safe-harbor language should be reviewed by the vendor’s legal team and align with applicable law.
Useful public-policy elements
- Clear contact method and optional encrypted channel.
- In-scope products, domains, applications, and services.
- Out-of-scope systems and prohibited testing methods.
- Rules for protecting customer data and avoiding service disruption.
- Information needed to reproduce and validate a report.
- Acknowledgement and status-update expectations.
- Coordinated disclosure and publication approach.
- Good-faith or safe-harbor commitments.
Assess the process behind the public page
A good-looking policy is design evidence. TPRM also needs operating evidence. Ask who monitors the channel, how reports enter the case-management system, how duplicates and spam are handled, which team validates findings, and how product owners are engaged. Confirm there is backup coverage and an escalation route for actively exploited or critical vulnerabilities.
Look for response targets that reflect severity rather than one generic service level. The vendor should acknowledge reports, assess reproducibility and impact, assign ownership, track remediation, test the fix, and communicate with the reporter. Targets are useful only when performance is measured and overdue cases receive attention.
Review scope across the product portfolio
Compare VDP scope with the product your organization buys. Vendors may exclude recently acquired products, hosted services, APIs, mobile applications, open-source components, or customer-managed deployments. An enterprise-wide policy can still contain product-level exceptions, so do not assume the corporate page covers every service.
For vendors that depend on cloud providers and software components, ask how they route findings that originate in third-party code. The vendor should be able to coordinate with maintainers, hosting providers, and downstream customers while controlling sensitive details. This is especially important when one report affects multiple products or tenants.
Understand triage and prioritization
Triage should evaluate reproducibility, affected versions, exploit prerequisites, data exposure, tenant impact, privilege gained, attack complexity, availability impact, and evidence of exploitation. CVSS can support consistency, but business context and affected-customer exposure still matter. A report should not be dismissed merely because it arrived without a perfect score.
Ask how the vendor distinguishes a vulnerability from a support issue, privacy concern, abuse report, or incident. There should be handoffs between product security, engineering, privacy, fraud, incident response, and customer communications. Reports that indicate active compromise must move into incident response rather than waiting in a normal remediation queue.
A practical VDP due-diligence workflow
- Locate the channel. Find the public policy, security.txt record, form, address, and encryption option.
- Map scope. Confirm that the purchased product, APIs, domains, and deployment model are covered.
- Review policy quality. Check permitted testing, prohibited actions, data safeguards, safe harbor, and disclosure expectations.
- Validate operations. Identify intake ownership, case management, triage, escalation, engineering handoff, and backup coverage.
- Assess response targets. Review acknowledgement, validation, remediation, reporter updates, and overdue-case escalation.
- Examine outcomes. Ask for aggregate volume, severity, time-to-triage, time-to-remediate, reopened cases, and lessons learned.
- Connect to your contract. Ensure material vulnerabilities and exploitation affecting your service trigger appropriate customer notification and remediation duties.
- Document limitations. Record excluded products, weak response commitments, open material reports, and compensating controls.
Evidence that the program actually operates
Useful evidence includes an anonymized workflow, roles and escalation matrix, sample case records, response metrics, recent policy review, tabletop or exercise results, and examples of product changes driven by reports. Do not request reporter identities, exploit details, or active vulnerability information unless strictly necessary and securely handled.
Aggregate metrics are most useful when accompanied by definitions. “Average remediation time” can hide aged critical issues or exclude disputed reports. Ask for severity bands, median and tail performance, open backlog age, and how the vendor treats duplicate, informative, and invalid submissions.
Connect disclosure to remediation and prevention
A mature program does more than close individual tickets. NIST SSDF recommends analyzing vulnerabilities to identify root causes and prevent recurrence. Ask whether confirmed reports produce secure-coding updates, new automated tests, architecture changes, dependency controls, threat-model revisions, or developer training.
The vendor should also consider whether a report affects customers, downstream integrators, or shared components. Coordinated advisories, CVE assignment where appropriate, patches, mitigations, and customer guidance should follow a controlled communications plan. Silence can be a risk when customers need action.
Red flags during a VDP review
- The only reporting path is a general support queue with no security routing.
- The public policy is outdated, broken, or excludes the purchased product without an alternative.
- Researchers receive no acknowledgement or are discouraged by threatening language.
- No team owns validation, severity decisions, or escalation.
- Critical reports follow the same timeline as low-impact issues.
- The vendor cannot provide aggregate performance or backlog information.
- Fixes are deployed without validation or root-cause analysis.
- Customer notification depends entirely on the reporter publishing first.
How to treat a vendor without a formal VDP
Absence of a public VDP is not automatically disqualifying, particularly for a small non-software supplier with little internet-facing attack surface. Evaluate proportionality. A SaaS platform, security product, identity provider, API service, or managed technology vendor should generally have a credible vulnerability reporting and response route.
If the vendor lacks a public program, ask for the internal process, security contact, escalation commitment, and roadmap. Consider contractual requirements, a named reporting channel, customer notification duties, and tighter monitoring. For a critical technology dependency, persistent inability to receive and respond to reports is a material governance gap.
Common mistakes TPRM teams should avoid
Scoring the web page instead of the process. Confirm operations and outcomes. Equating bounty size with maturity. Rewards do not guarantee effective remediation. Ignoring portfolio gaps. Check the exact product and acquired entities. Collecting sensitive cases. Use aggregate or redacted evidence. Separating VDP from incident response. Active exploitation requires urgent escalation. Failing to contract for notice. Disclosure to a researcher does not replace notice to affected customers.
Analyst takeaway
A strong VDP shows that the vendor can learn from people outside its own security team. TPRM should evaluate the full chain: discoverability, safe reporting, triage, ownership, remediation, validation, communication, and prevention. The best evidence is not the existence of a policy; it is a consistently operated response process.
Document which product and reporting channel were reviewed, the evidence date, material scope exclusions, response commitments, operating metrics, and contractual follow-up. Set a reassessment trigger for acquisitions, product launches, major incidents, or repeated overdue reports. A concise decision record helps future analysts distinguish a functioning disclosure capability from a policy that has not been tested in practice.
Frequently asked questions
What is a vulnerability disclosure program?
A vulnerability disclosure program gives external researchers a defined, good-faith channel to report suspected security weaknesses and gives the vendor a process to receive, validate, prioritize, remediate, and communicate about those reports.
Is a bug bounty the same as a vulnerability disclosure program?
No. A VDP establishes reporting and safe-harbor expectations. A bug bounty adds financial rewards and usually narrower eligibility and severity rules. A vendor can operate a credible VDP without paying bounties.
Should every software vendor publish a security.txt file?
A security.txt file is a useful standardized discovery mechanism for reporting contacts and policy information. Its absence is not conclusive, but for an internet-facing software provider it is a practical maturity signal worth asking about.
What evidence should a TPRM analyst request for a VDP?
Request the public policy or reporting page, scope, reporting channels, acknowledgement targets, triage ownership, escalation paths, remediation tracking, disclosure coordination, and metrics or examples that show the process operates.
Does a VDP prove that a vendor develops secure software?
No. It shows a mechanism for learning about residual vulnerabilities. TPRM should also evaluate secure development, testing, dependency management, incident response, patching, and root-cause prevention.
Sources
- NIST SP 800-218: Secure Software Development Framework Version 1.1
- CISA: Vulnerability Disclosure Policy Guidance
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure
