Topic starter
30/09/2026 4:59 pm
TL;DR: Leaked secrets often reach organisations before the right responder does, and GitGuardian says only about half of those disclosures end in proper remediation because reporting paths break before revocation can happen. The governance gap is not detection alone but a reliable authority chain that can act on a credential fast enough to remove exposure.
NHIMG editorial: based on content published by GitGuardian: How to Set Up a Vulnerability Disclosure Program
Questions worth separating out
Q: What breaks when a leaked secret report cannot reach someone who can revoke it?
A: The disclosure process fails at the only point that matters: containment.
Q: Why do leaked secrets remain dangerous after they are detected?
A: They remain dangerous because discovery does not automatically invalidate authentication.
Q: What are the best practices for handling leaked-secret reports?
A: Use a dedicated intake path, accept anonymous and out-of-scope reports, define a revocation-capable owner, and test the full handoff from report to credential invalidation.
Practitioner guidance
- Create a leaked-secret playbook Define who receives reports, who can revoke credentials, and how the response is escalated when a secret is confirmed.
- Publish a monitored security intake path Maintain a visible security.txt file and a monitored security@ mailbox so outside reporters can reach the security team directly.
- Update bug bounty triage rules Route out-of-scope and anonymous leaked-secret reports to security rather than closing them at the first triage checkpoint.
What's in the full article
GitGuardian's full guide covers the operational detail this post intentionally leaves for the source:
- Six-step leaked-secret playbook structure with each control point spelled out
- Policy language for safe-harbor reporting and anonymous disclosure acceptance
- How to route ineligible bounty submissions without losing secrets reports
- Suggested tests for proving the disclosure path reaches revocation
👉 Read GitGuardian's guide to building a vulnerability disclosure program for leaked secrets →
Leaked secrets: do your disclosure channels reach the right owner?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
30/09/2026 5:00 pm
Leaked-secret governance fails when disclosure is treated as intake instead of containment. The article describes a common operational weakness: reports arrive, but the path to revocation is unclear or missing. That means the control gap is not awareness, but authority routing. For NHI programmes, the real governance unit is the time between discovery and credential invalidation, not the existence of a reporting form.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
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.
👉 Read our full editorial: Disclosure channels for leaked secrets need a revocation path
