Topic starter
30/09/2026 4:59 pm
TL;DR: Only about half of leaked-secret disclosures end in proper remediation, GitGuardian reports, when the warning never reaches someone with authority to revoke the credential. Disclosure routing has to end in invalidation, or the secret can stay live after 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: 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.
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.
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.
Glossary terms: Revocation Path, Disclosure Channel, Security.txt, Safe-harbor language
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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