Notifications
Clear all
Topic starter
04/06/2026 3:03 pm
TL;DR: Secret scanners can now find exposed API keys and tokens quickly, but most organisations still stall on remediation because the alert does not reveal whether a secret is live, what it can reach, or how to retire it safely, according to Oasis Security. The real control gap is identity context, not detection speed.
NHIMG editorial — based on content published by Oasis Security: Identity-aware secret scanning: From “Found” to “Fixed”
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: How should security teams handle exposed secrets without breaking production?
A: Security teams should first map the secret to its owning non-human identity, then confirm whether it is live, what it can access, and whether dependent systems can tolerate revocation.
Q: Why do leaked API keys and tokens remain a governance problem after detection?
A: Detection only proves that a secret exists in a risky place.
Q: What do organisations get wrong about secret rotation in NHI programmes?
A: They often treat rotation as a universal fix, even when they cannot confirm which systems depend on the credential.
Practitioner guidance
- Map exposed secrets to owning identities Link every scanner finding to the service account, API key, token, or certificate that actually uses it.
- Require blast-radius checks before revocation Verify what the credential can access, which production systems depend on it, and whether the secret is still live before disabling it.
- Build a safe rotation path for live credentials Use a rotation workflow that updates consumers, validates application health, and retires the old secret only after the new one is confirmed.
What's in the full article
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- The step-by-step flow from raw scanner alert to identity correlation and safe remediation.
- The specific ownership and usage data fields needed to determine whether a secret is live.
- The example remediation path for a credential embedded in a Teams message or similar collaboration tool.
- The practical differences between immediate revocation and orchestrated rotation for active production identities.
👉 Read Oasis Security's analysis of identity-aware secret scanning and remediation →
Identity-aware secret scanning: what teams need to fix faster?
Explore further
04/06/2026 3:17 pm
Identity-aware secret scanning is a governance model, not a detection feature. The industry has spent years improving the speed of secret discovery, but discovery does not equal control. What matters is whether the secret can be tied to an identity, an owner, and a safe remediation path. Practitioners should stop measuring success by alert volume alone and start measuring how quickly they can move from finding to fixing.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to The State of Secrets Sprawl 2026.
A question worth separating out:
Q: How do teams know if identity-aware secret scanning is actually working?
A: It is working when findings are routed to clear owners, live credentials are resolved quickly, and revocation or rotation happens without production instability. Good programmes shorten the time from discovery to safe remediation and reduce the number of alerts that require manual reverse engineering.
👉 Read our full editorial: Identity-aware secret scanning closes the remediation gap
