Bug bounty programs can hide secret leak reports and delay response

At a glance

What this is: This analysis argues that bug bounty programs are useful only as a supplement, and that they become counterproductive when they replace a public vulnerability disclosure policy for secret leak reporting.

Why it matters: For IAM and NHI practitioners, the issue is whether leaked credentials, certificates, and tokens can reach the right responders quickly enough to enable revocation before exposure becomes compromise.

By the numbers:

• In GitGuardian's 2025 research, 28.65 million new hardcoded secrets were detected in public GitHub commits, a 34% year-over-year increase and the largest single-year jump ever recorded.
• GitGuardian found that 64% of valid secrets leaked in 2022 are still valid and exploitable today.
• GitGuardian also reported that AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read GitGuardian's analysis of bug bounty blind spots for secret leak reporting

Context

Bug bounty programs are often treated as a security control, but they are really a reporting mechanism. The governance problem appears when the mechanism is narrowed until it filters out exactly the kind of report that matters most for NHI security: leaked secrets, private keys, tokens, and certificates that can be weaponized immediately.

For IAM and NHI teams, the operational question is not whether to use bug bounty at all. It is whether there is an open, visible, and direct route for responsible disclosure when a valid credential is found outside the program’s scope or cannot be safely demonstrated through a proof of concept.

This matters even more in environments where the first sign of exposure is a credential leak rather than an exploit chain. That is typical, not exceptional, for modern NHI risk.

Key questions

Q: Should organisations use bug bounty programs as their only vulnerability disclosure channel?

A: No. Bug bounty programs are useful for additional coverage, but they should never be the only disclosure channel. A public vulnerability disclosure policy is still needed so researchers can report issues safely, quickly, and without being blocked by scope rules, platform access, or eligibility requirements.

Q: How should security teams handle leaked credentials reported outside bug bounty scope?

A: They should accept the report, validate whether the secret is live, and move immediately to revocation or blacklist actions. If the source of the leak is unclear, ask for disclosure context, not exploit proof. The goal is to reduce exposure time, not to negotiate program eligibility.

Q: What is the difference between a bug bounty program and a vulnerability disclosure policy?

A: A bug bounty program rewards selected reports under defined scope and process rules. A vulnerability disclosure policy is broader and exists to provide a safe reporting path for anyone, including anonymous reporters, regardless of whether the issue qualifies for payment.

Q: Why do leaked secrets need a different reporting path than ordinary software bugs?

A: Because leaked secrets are often already valid and usable when discovered. That makes them an identity and access problem, not just a code defect. The response must focus on containment, revocation, and investigation, while ordinary bugs often need reproduction and prioritisation first.

Technical breakdown

Why disclosure channels fail for secret leak reports

A vulnerability disclosure policy is meant to create a path from discovery to remediation. Bug bounty platforms add triage, eligibility rules, and scope filters on top of that path. When those filters become the only route, they can block reports that are valid but inconvenient, especially when the issue is a leaked secret rather than a conventional software flaw. For NHI exposure, the core technical problem is that a stolen token, private key, or certificate may already be active when the report is filed. If the channel cannot carry the report to the security team quickly, the security control has failed at the point that matters most.

Practical implication: Practitioners should separate reporting intake from bounty eligibility so critical secret leaks can reach internal responders immediately.

Why proof of concept can be the wrong requirement

Proof-of-concept requests make sense when exploitability is uncertain, but they can become unsafe when the issue is a valid credential or private key. Demonstrating impact may require actions that cross the line from validation into unauthorized access, such as decrypting traffic or impersonating a live service. That is not a disclosure standard, it is an attack surface test imposed on the reporter. In NHI terms, the existence of a working secret is already evidence of material risk. The question is no longer whether the credential works. The question is how fast the organization can revoke, rotate, and investigate it before it is used.

Practical implication: Set handling rules that accept evidence of validity without demanding risky exploitation from the reporter.

Why out-of-scope secret reports create a governance gap

Out-of-scope designations are useful for reducing noise, but they become dangerous when they exclude leaked credentials entirely. A valid secret found in public code, logs, or collaboration tools is not a theoretical issue. It is an access path with immediate identity implications. If the program excludes it, the organization loses visibility into a class of NHI events that can lead directly to unauthorized access. The right control is not exclusion, it is source transparency. Security teams need to know where the credential came from so they can investigate origin, exposure path, and whether the secret is still live.

Practical implication: Include leaked secrets in scope, then require source-of-discovery details and a revocation workflow.

Threat narrative

Attacker objective: The attacker aims to turn a leaked non-human credential into authenticated access before the organization can revoke it.

1. Entry occurs when an attacker or researcher finds a leaked API key, token, or X.509 private key in public code, logs, or a misrouted disclosure channel.
2. Escalation happens when the valid secret is ignored, triaged away, or left outside the reporting workflow long enough to remain usable.
3. Impact follows when the secret is used to impersonate a service, access protected assets, or enable man-in-the-middle interception against public-facing systems.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Bug bounty is a supplement, not a disclosure strategy. The security value of bounty programs disappears when they become the only intake channel for secret leaks. In that configuration, scope rules and platform friction can filter out the most time-sensitive NHI incidents. Practitioners should treat bounty as one route inside a broader disclosure architecture, not the architecture itself.

Secret leak handling is an IAM and NHI lifecycle problem, not just a vulnerability management problem. A leaked key or certificate is an identity event because it creates standing access until revoked. That means the organization needs intake, validation, revocation, and post-incident review as one continuous workflow. If any step depends on a bounty platform decision, governance becomes inconsistent.

Source transparency is the right control for leaked credentials. Excluding secret reports from scope does not remove risk. It moves risk into shadow channels where the security team sees less and learns later. A disciplined program should accept the report, ask where the secret was found, and then route the issue to the team that can revoke or blacklist the credential.

Privacy in disclosure is not a courtesy, it is part of the control model. Requiring registration, tax paperwork, or platform accounts for every reporter narrows who can safely disclose. That is especially problematic for researchers who want to remain anonymous or who discover issues outside their normal workflow. A public VDP with direct escalation protects both the reporter and the organization.

Closed reports are not the same as resolved incidents. The most dangerous failure mode in bounty-only disclosure is false closure, where a report is marked informative while the credential remains active. In NHI governance terms, that is unresolved privilege exposure. Practitioners should measure success by revocation time and remediation completion, not by triage closure volume.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• That same research found that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For teams building a better intake model, the NHI Lifecycle Management Guide shows how to connect discovery, rotation, and offboarding into one operational workflow.

What this signals

Bug bounty is a useful signal source, but it is not a control plane for NHI risk. When disclosure is filtered through platform eligibility, organizations lose the ability to treat leaked secrets as time-sensitive identity events. That is why the governance question should shift from reward design to revocation speed and intake reach.

Disclosure-path debt: when the reporting route is harder than the remediation route, teams accumulate hidden exposure. In practice, this means security programs should keep a direct, public path for secret leaks and reserve bounty rules for compensation, not for access to the security team.

The practical signal for IAM and NHI owners is to align disclosure handling with access lifecycle controls, not ticketing convenience. If a secret can be found in public code or a collaboration tool, the response should start with containment and ownership assignment, then move through rotation, blacklisting, and retrospective review.

For practitioners

• Implement a public vulnerability disclosure policy Create an always-visible VDP that accepts reports outside bounty scope, defines escalation paths, and gives reporters a direct security contact for urgent credential exposure.
• Include leaked secrets in bounty scope Do not exclude credentials, tokens, or private keys by default. Require reporters to state where the secret was found, then route the case to internal teams for validation and revocation.
• Separate intake from reward eligibility Allow security@ and web forms to feed the same internal case queue, even when the reporter is not eligible for payout or the finding is outside the bounty program.
• Measure disclosure by revocation speed Track time to acknowledge, time to validate, and time to revoke or blacklist the credential. Closure without revocation should not count as remediation.

Key takeaways

• Bug bounty programs add value only when they complement a public disclosure policy that can receive secret leak reports without friction.
• Leaked credentials are identity incidents, so the response must prioritize containment, revocation, and source transparency over proof-of-concept demands.
• If the only reporting path is restrictive, the organisation may see fewer submissions but miss the incidents that carry the highest access risk.

Key terms

• Vulnerability Disclosure Policy: A vulnerability disclosure policy is the public process for receiving security reports from anyone who finds a problem. It sets expectations for safe reporting, response timing, and escalation, so researchers can disclose issues without guessing where or how to send them.
• Bug Bounty Program: A bug bounty program is a controlled reporting and reward model for security findings. It can help broaden coverage, but it is selective by design, with scope, eligibility, and triage rules that can exclude reports if it is treated as the only intake path.
• Secret Leak: A secret leak is the exposure of a credential such as an API key, token, certificate, or private key. In NHI terms, it is an access event because the leaked secret may already be valid and usable, making rapid revocation more important than post hoc analysis.
• Disclosure Path Friction: Disclosure path friction is the delay or failure introduced when a reporter must navigate multiple systems, registrations, or gatekeepers before a security team sees the issue. High friction reduces reporting quality and increases the chance that a live credential remains active too long.

What's in the full article

GitGuardian's full article covers the operational detail this post intentionally leaves for the source:

• Examples of real triage failures involving leaked keys, private keys, and certificates that were closed without remediation.
• The practical differences between public and private bug bounty programs when the report is a valid secret leak.
• Why some programs exclude leaked credentials from scope and how that affects investigation of the leak source.
• How direct reporting, security@ intake, and security.txt can reduce disclosure-path friction.

👉 GitGuardian's full post covers disclosure failures, triager friction, and why VDPs need direct escalation paths.

Deepen your knowledge

Bug bounty governance and NHI disclosure handling are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is building a reporting path for leaked secrets, it is worth exploring.