The coordinated vulnerability disclosure model depends on a simple bargain: researchers report vulnerabilities privately, vendors fix them, and the public benefits. But what happens when the vendor doesn’t hold up their end? On most bug bounty platforms, the answer is: nothing. The researcher is bound to silence, and the vulnerability stays hidden — not because it’s been fixed, but because the vendor doesn’t want it known.

This post examines the disclosure policies of five major bug bounty platforms — HackerOne, Bugcrowd, Intigriti, YesWeHack, and Zerocopter — and compares them to established independent CVD standards. The picture that emerges is troubling: platforms have built systems that protect vendors at the expense of the public interest they claim to serve.

The Independent CVD Baseline#

Before examining platforms, it’s worth establishing what coordinated disclosure looks like without a platform intermediary.

Google Project Zero operates on a 90+30 policy: vendors get 90 days to patch, then details go public 30 days after the patch (or at day 90 if unpatched). For actively exploited vulnerabilities, the deadline drops to 7 days. This is non-negotiable.

CERT/CC uses a 45-day deadline:

“Vulnerabilities reported to the CERT/CC will be disclosed to the public 45 days after the initial report, regardless of the existence or availability of patches or workarounds from affected vendors.”

— CERT/CC Disclosure Policy

ZDI (Trend Micro) allows 120 days, with tiered grace periods, but is explicit that suppression is not an option:

“In no cases will an acquired vulnerability be ‘kept quiet’ because a product vendor does not wish to address it.”

The Dutch NCSC targets 60 days. The EU NIS2 Directive (Article 12) requires Member States to designate CSIRTs as CVD coordinators who negotiate timelines — but at least acknowledges that disclosure must eventually happen.

The common thread: every independent CVD framework includes a deadline after which the researcher may disclose, regardless of vendor action. The researcher retains agency. The vendor has a finite window to act, after which the public’s right to know takes precedence.

Bug bounty platforms break this model.

HackerOne: The Best of a Bad Lot#

HackerOne offers the most researcher-friendly disclosure policy among the four platforms, but it’s riddled with opt-outs that let vendors maintain indefinite silence.

HackerOne programs choose one of three disclosure settings:

Standard Disclosure (the default) auto-discloses resolved reports after 30 days if neither party objects. HackerOne’s Disclosure Guidelines (v1.2, July 2019) include a last-resort clause:

“If 180 days have elapsed with the Security Team being unable or unwilling to provide a vulnerability disclosure timeline, the contents of the Report may be publicly disclosed by the Finder.”

— HackerOne Disclosure Guidelines v1.2

This is the only explicit unilateral disclosure right granted to researchers on any major platform. But there are significant caveats.

Mutual Agreement Required removes the auto-disclosure. If the vendor ignores the disclosure request, the report stays private forever:

“If the security team doesn’t take any action, the contents of the report will remain private.”

— HackerOne Disclosure Documentation

Private programs go further. From HackerOne’s FAQ:

“My report has been labeled as Informative or N/A. Can I make the report information public, or do a write-up about it without checking in with the program? No.”

— HackerOne FAQ

And:

“To accept a private program invitation, all Hackers agree to never disclose any bugs that are submitted to that private program.”

The confidentiality obligation survives account termination. From the Code of Conduct (v3.1, December 2024):

“The obligation to protect confidential information does not end when your relationship with HackerOne is terminated.”

— HackerOne Code of Conduct PDF

Penalties: first offense for unauthorized disclosure is a Final Warning; second offense is a permanent platform ban.

Net assessment: HackerOne’s 180-day clause is meaningful, but only applies to Standard Disclosure programs that haven’t resolved the report into a non-Resolved state. A vendor who closes a report as “Informative” or “Not Applicable” — thereby claiming it’s not a real vulnerability — may effectively sidestep the 180-day clock. The FAQ’s blanket “No” on disclosing N/A and Informative reports suggests the 180-day clause doesn’t apply to reports the vendor has actively dismissed.

Bugcrowd: You Don’t Even Own Your Report#

Bugcrowd’s Standard Disclosure Terms contain an IP assignment clause that goes beyond confidentiality:

“You hereby assign to Bugcrowd and agree to assign to Bugcrowd any and all of your Testing Results and rights thereto.”

— Bugcrowd Standard Disclosure Terms

This means Bugcrowd — and through them, the vendor — owns the vulnerability report. The researcher doesn’t just promise not to disclose; they transfer legal ownership of their work product.

On confidentiality:

“ALL SUBMISSIONS ARE CONFIDENTIAL INFORMATION OF THE PROGRAM OWNER UNLESS OTHERWISE STATED IN THE BOUNTY BRIEF. This means no submissions may be publicly disclosed at any time unless the Program Owner has otherwise consented to disclosure.”

— Bugcrowd Standard Disclosure Terms

From the Code of Conduct:

“Private program customers are private, and no submitted vulnerability (including duplicates, Out of Scope, Not Applicable, etc.) may be disclosed without explicit customer permission.”

— Bugcrowd Code of Conduct

Bugcrowd does offer a “Coordinated Disclosure” model where researchers can request permission to disclose, but:

  • The program owner can simply deny the request
  • There is no documented deadline for the program owner to respond
  • There is no escalation mechanism when a vendor denies disclosure
  • There is no unilateral disclosure right at any time horizon

For programs using the “Nondisclosure” model (default for On-Demand and Pen Test MAX):

“No submissions may be publicly disclosed at any time.”

— Bugcrowd Public Disclosure Policy

Penalties for unauthorized disclosure are severe. From the Platform Behavior Standards:

Violation Severity Points
Program Disclosure (exposing a private program exists) 2
Disclosure Threat 3
Unauthorized Disclosure 4

At 4 accumulated points, the researcher faces a temporary suspension. At 5+, a platform ban. The standards note that “4- and 5-mark incidents never expire.”

Net assessment: Bugcrowd is the most restrictive platform. The IP assignment clause means that even if you wanted to challenge the confidentiality obligation legally, you’d be arguing about someone else’s intellectual property. There is no disclosure timeline, no escalation path, and no researcher recourse. The vendor has absolute veto power over disclosure, forever.

Intigriti: Dual Approval, No Deadline#

Intigriti’s Researcher Terms & Conditions (Article 9) establish a dual-approval requirement:

“Public disclosure is only allowed if both parties (the Company and you) expressly agree (through the Platform or otherwise in writing) that information about a Vulnerability can be shared.”

— Intigriti Researcher Terms & Conditions

Unlike HackerOne’s 180-day escape hatch, Intigriti has no automated or time-based disclosure mechanism. From their knowledge base:

“Prior to written approval from the Intigriti team and the company, it is not allowed to disclose any information related to your submission. This also includes report titles, vulnerability types, endpoints, comments, bounty amounts or the company name.”

— Intigriti: Public Disclosure of Submissions

Note: disclosure requires approval from both Intigriti and the company. Even a willing vendor can’t grant disclosure unilaterally — the platform must also agree.

There is no policy addressing what happens when a vendor refuses to fix or acknowledge a vulnerability. The researcher’s only option is to request disclosure via a comment on the report and wait.

Penalties include civil liability:

“You will be liable for any damages that could be attributed to an infringement of the confidentiality obligations hereunder.”

— Intigriti Researcher T&C, Article 9.3

And potential identity disclosure:

Intigriti will disclose your real identity when there are “reasonable ground(s) to believe you do not operate in good faith.”

— Intigriti Researcher T&C, Article 9.4

Disputes are governed by Belgian law with Antwerp courts holding exclusive jurisdiction.

Net assessment: Intigriti’s dual-approval model means even a vendor sympathetic to disclosure can’t act without platform consent. There is no timeline, no escalation, no last-resort clause. The confidentiality obligation has no expiration.

Zerocopter: The Dutch Exception (Sort Of)#

Zerocopter, headquartered in Amsterdam, is the one platform with a finite confidentiality period — but it still falls far short of independent CVD standards.

The Terms and Conditions (Article 7.1, July 2024) include an actual expiration:

“Neither Party shall at any time during the term of this Agreement and for a period of five (5) years after termination or expiration of this Agreement disclose any information marked as confidential or that a reasonable person should understand to be confidential.”

— Zerocopter Terms and Conditions, Article 7.1

Five years. That’s a defined horizon — the only one among all five platforms — but it’s five years, not 90 or 180 days. For context, Google Project Zero’s entire disclosure timeline is 90 days. CERT/CC’s is 45 days. Zerocopter’s is 1,825 days.

On the positive side, IP ownership stays with Zerocopter — not the vendor. The customer receives only a non-exclusive, non-transferable license:

“All right, title, and interest in and to the Intellectual Property Rights relating to […] the Deliverables […] are and will remain the exclusive property of Zerocopter or its licensors.”

— Zerocopter Terms and Conditions, Article 6.1

This means the vendor cannot independently claim ownership of vulnerability reports, unlike Bugcrowd’s full IP assignment or YesWeHack’s transfer-on-payment model.

The Code of Conduct (July 2024) mirrors other platforms on day-to-day confidentiality:

“Don’t share confidential vulnerability or user information. Bug bounty programs are private, and no submitted vulnerability (including duplicates, Out of Scope, Not Applicable, etc.) may be disclosed without explicit permission.”

— Zerocopter Code of Conduct

The sanctions table is straightforward:

Violation Sanction
Disclosure of bug bounty program information Suspension
Disclosure of report information without permission Suspension
Extortion and blackmail Platform ban

There is no public disclosure mechanism, no request process, and no documented escalation path when a vendor refuses to act. The only meaningful difference from the other four platforms is the 5-year expiration and the Dutch law governing jurisdiction (Amsterdam courts), which at least places the relationship under the Netherlands’ relatively researcher-friendly legal framework.

Net assessment: Zerocopter is the only platform with a finite confidentiality period, which is structurally better than the indefinite obligations of all other platforms. But five years is still far longer than any independent CVD standard. There is no disclosure mechanism, no escalation path, and no timeline pressure on vendors. The Dutch legal context is a mild positive, but it doesn’t create a disclosure right that the contract denies.

YesWeHack: The Most Explicit Indefinite Silence#

YesWeHack’s General Conditions of Use (GCU v7.0, February 2025) contain the most explicit indefinite confidentiality clause of any platform:

“Users have an obligation to keep confidential all information (i) to which they have access, (ii) brought to their knowledge, or (iii) which they possess in the context of the Services, whether in oral or written form and whatever the medium, irrespective of whether it is explicitly indicated to be confidential or not. Users shall not disclose or make available such information to any third-party for any reason whatsoever.”

— YesWeHack GCU v7.0, Article 7

The Platform Code of Conduct specifies that confidentiality covers vulnerability reports “whatever the status” — including reports closed as Informative, Duplicate, or rejected.

Unlike HackerOne, Bugcrowd, or Intigriti, YesWeHack has no public disclosure mechanism of any kind. There is no feature to request disclosure, no dual-approval process, no disclosure setting that programs can opt into. The concept of public disclosure simply does not exist in their policy framework.

The GCU further requires researchers to delete all data when a program ends:

“At the end of a Program, Security Researchers will delete from their systems all Customer’s information and data of any kind, including Personal Data and Vulnerability Reports they created.”

— YesWeHack GCU v7.0, Article 4.2

And a survival clause ensures the confidentiality obligation outlives everything:

“In the event of termination or early termination of these GCU for any reason […] any provision or condition of these GCU intended to survive such termination shall survive […] including […] ‘Confidentiality’.”

— YesWeHack GCU v7.0, Article 13

The vendor holds sole discretion over report validity:

“The Customer User will determine whether Vulnerabilities are valid and their severity level.”

— YesWeHack GCU v7.0, Article 4.3

YesWeHack disclaims all responsibility for vendor behavior:

“The Company shall under no circumstance be liable for […] Customer User’s failure in the definition and management of the Program.”

— YesWeHack GCU v7.0, Article 9

IP transfers to the vendor upon reward payment:

“Upon submitting Vulnerability Reports to the Customer and receiving payment of the Reward, the Security Researcher agrees to transfer full and exclusive ownership of the material property rights in the Vulnerability Reports to the relevant Customer.”

— YesWeHack GCU v7.0, Article 4.4

Penalties are structured through an ethical points system. Every researcher starts with 7 points:

Violation Points Deducted
Unauthorized disclosure of program info 4
Unauthorized confidential information disclosure 5
Extortion/threats 7 (instant ban)

At 2 remaining points, the researcher faces a 1-month suspension. At 1 point, 3 months. At 0, a permanent ban.

Governed by French law, Paris courts.

Net assessment: YesWeHack is the most restrictive platform by a significant margin. There is no disclosure mechanism at all — not even a request process. The vendor has unilateral, indefinite, and absolute suppression power. Researchers must delete their own work product. The confidentiality obligation survives termination, the IP transfers to the vendor, and the only recourse is mediation through YesWeHack support — which is not documented in any policy.

The Comparison Table#

HackerOne Bugcrowd Intigriti Zerocopter YesWeHack Independent CVD
Disclosure mechanism Built-in (3 modes) Request-based Request-based (comment) None None Researcher decides
Unilateral disclosure right 180 days (Standard only) No No No No 45-120 days
Auto-disclosure 30 days (Resolved, Standard) No No No No At deadline
Vendor can block disclosure Yes (Mutual mode) Yes (deny request) Yes (withhold approval) Yes (no mechanism) Yes (no mechanism exists) No (deadline is firm)
Confidentiality duration Indefinite Indefinite Indefinite 5 years post-termination Indefinite 45-120 days
Confidentiality survives termination Yes (explicit) Yes (no expiry) Yes (no expiry) Yes (5 years) Yes (explicit + data deletion) N/A
IP ownership Researcher Bugcrowd/vendor Researcher Zerocopter Vendor (on payment) Researcher
Top disclosure penalty Permanent ban Permanent ban Civil liability + ban Suspension 5 ethical points + ban Legal risk (varies)
Governing law California, US California, US Belgian Dutch French Varies

The Core Problem#

The fundamental issue is an asymmetry of power that platforms have institutionalized:

  1. The vendor decides if a vulnerability is valid. If they close it as Informative, there is no appeal mechanism that leads to disclosure on any platform.

  2. The vendor decides if disclosure happens. On every platform except HackerOne Standard, the vendor has absolute veto power. Even on HackerOne Standard, the 180-day clause may not apply to vendor-dismissed reports.

  3. The researcher bears all the risk. Unauthorized disclosure results in platform bans, forfeiture of all rewards, civil liability (Intigriti), and potential legal action under the governing jurisdiction. The vendor faces no consequences for ignoring, misclassifying, or suppressing legitimate vulnerabilities.

  4. The platform is not a neutral party. Platforms are paid by vendors, not researchers. Their business model depends on vendor retention. There is no economic incentive to side with a researcher in a disclosure dispute.

  5. Once submitted, there is no exit. A researcher cannot withdraw a submission and pursue independent CVD instead. The report is now platform property (or vendor property), and the confidentiality obligation is irrevocable.

This creates a perverse incentive: the more serious a vulnerability, the more a vendor might want to suppress it, and the less recourse the researcher has. A vendor can acknowledge a critical finding, close it as “Informative” with a dubious justification, and the researcher is legally bound to silence while the vulnerability persists in the wild.

What Should Change#

The fix doesn’t require dismantling the bug bounty model. It requires adopting what independent CVD has known for decades: disclosure deadlines are non-negotiable.

Platforms should:

  1. Mandate a maximum confidentiality period (e.g., 180 days from submission) after which the researcher regains the right to disclose, regardless of report status. This aligns with HackerOne’s existing Standard Disclosure clause — it just needs to be universal and non-optional.

  2. Prohibit vendors from using status changes to suppress disclosure. Closing a report as “Informative” or “Not Applicable” should not restart or eliminate the disclosure clock.

  3. Establish independent review for contested reports. When a researcher disputes a triage decision, the platform (not the vendor) should make the final call — with public disclosure as the default outcome if neither party can demonstrate the report is invalid.

  4. Stop transferring IP to vendors. Researchers should retain ownership of their work product. The vendor gets a license to use the report for remediation. The researcher retains the right to publish after the confidentiality period.

  5. Publish transparency reports. How many reports are suppressed? How many vendors block disclosure? How many valid findings are closed as Informative? The public deserves to know.

Until these changes happen, researchers face a choice: submit through platforms and accept indefinite silence, or work independently with a fixed disclosure deadline and full agency. For vulnerabilities that affect public safety — in IoT devices, medical systems, critical infrastructure — the second option may be the more responsible one.

Conclusion#

Bug bounty platforms were built on the promise that they make coordinated disclosure work. In many cases, they do. But the disclosure policies of every major platform are structurally weighted toward vendor interests. Researchers who discover that a vendor is suppressing a legitimate vulnerability have no recourse through the platform, no timeline to wait out, and no right to inform the public.

The industry standard outside of platforms — from Google Project Zero’s 90 days to CERT/CC’s 45 — exists because the security community learned, over decades of experience, that vendors will not reliably fix vulnerabilities without the pressure of a deadline. Bug bounty platforms have rolled back that lesson, replacing firm deadlines with vendor discretion and researcher silence.

The researchers who participate in these programs are doing critical work for public safety. The policies governing their work should reflect that, not treat them as a liability to be managed.

The author is an independent security researcher participating in multiple bug bounty programs across all five platforms discussed. All policy quotes are sourced from publicly available terms of service, codes of conduct, and help center documentation as of March 2026. This post does not disclose any confidential vulnerability information or identify any specific program.

Sources: