Topic starter
30/09/2026 4:59 pm
TL;DR: GitGuardian says leaked secrets are often reported by outsiders, but only about half of those disclosures end in proper remediation because the warning fails to reach someone with authority to revoke the credential. The real control gap is a disclosure path that can convert a report into revocation, not just intake.
Editorial analysis by NHI Mgmt Group, based on content published by GitGuardian: “Vulnerability Disclosure Policy Template and Setup Guide”.
By the numbers:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
Key questions
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 need a disclosure path, not just a reporting inbox?
A: Because a reporting inbox only receives information, while a disclosure path connects that information to action.
Q: How should security teams route out-of-scope secret disclosures?
A: They should route them into security review and revocation workflows instead of treating scope as a reason to close the report.
Practitioner guidance
- Build a revocation-first disclosure playbook Document the exact internal steps from first report to credential invalidation, including who can revoke service accounts, tokens, or API keys.
- Publish monitored disclosure entry points Maintain a monitored security@ address and a security.txt file so outside reporters can reach the security function directly.
- Separate bounty eligibility from security action Route out-of-scope and anonymous leaked-secret reports into security review instead of closing them at the first triage gate.
Bottom line: Leaked-secret handling fails when the report is accepted but not delivered to someone who can revoke the credential.
What's in the full article
GitGuardian's full guide covers the operational detail this post intentionally leaves for the source:
- The six-step secrets-leak playbook for building a disclosure path that can actually revoke credentials
- The role of security.txt, monitored security@ mailboxes, and safe-harbor disclosure policy language
- How to route out-of-scope and anonymous leaked-secret reports without losing containment
- The end-to-end test method for proving that a disclosure reaches the team that can act
👉 Read GitGuardian's guide on building a revocation path for leaked secrets →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/09/2026 5:00 pm
Disclosure workflows are now part of NHI control design, not a side process. If a leaked credential can be found but not routed to someone who can revoke it, the organisation has discovery without containment. That is a governance failure, not a tooling issue. The control boundary now extends from external reporting into internal ownership, which means security teams need a revocation path as deliberately as they need a detection path.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should teams test in a leaked-secret disclosure process?
A: They should test the full handoff from report intake to secret invalidation. The useful question is not whether a message arrives, but whether it reaches a responder with authority to revoke the credential and confirm the fix. If that chain fails, the disclosure process is not operationally complete.
👉 Read our full editorial: Disclosure channels for leaked secrets need a revocation path