Notifications
Clear all
Topic starter
12/06/2026 12:31 am
TL;DR: Static API key leaks keep recurring because developers still treat secrets as reusable configuration, while cloud-native systems expose them across code, environment variables, sidecars, and shared services, according to Riptides and reporting cited by the article. The real failure is not leakage alone but an identity model that assumes credentials live long enough to be safely distributed and reviewed.
NHIMG editorial — based on content published by Riptides: The API Key Leaks Keep Coming
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams reduce risk from static API keys in cloud-native environments?
A: Security teams should inventory every long-lived key, assign ownership, and replace broad reuse with task-scoped identity wherever possible.
Q: Why do static secrets increase lateral movement risk?
A: Static secrets increase lateral movement risk because the same credential is often valid across multiple services, environments, or teams.
Q: What do organisations get wrong about secrets managers?
A: Many organisations assume a secrets manager solves the problem once the credential is stored centrally.
Practitioner guidance
- Map every static credential to an owner and expiry condition Build an inventory of API keys, tokens, certificates, and shared secrets across code, CI/CD, secrets stores, and runtime environments.
- Replace reusable secrets with task-scoped workload identity Where workloads call other services, move toward ephemeral certificates or tokens issued from live runtime context rather than copied into config files or environment variables.
- Treat sidecars and secret brokers as trust boundaries Review whether sidecars, agents, or local brokers have become a new extraction point for credentials.
What's in the full article
Riptides' full article covers the operational detail this post intentionally leaves for the source:
- Kernel-native identity flow details showing how live process context is used before issuance
- The telemetry and enforcement model behind runtime credential monitoring
- Examples of how the architecture handles X.509 certificates, JWTs, and destination validation
- The vendor's implementation claims around eliminating persistent secrets from disk and environment variables
👉 Read Riptides' analysis of why API key leaks keep recurring in cloud-native systems →
Static API keys and shared secrets: what IAM teams are missing?
Explore further
12/06/2026 9:47 am
Static secrets are a standing privilege problem, not just a leakage problem. The issue is not only where the key is stored, but that the same credential can authenticate many actions long after the original use case has passed. That creates an identity object with no natural expiry in operational practice. The practitioner conclusion is simple: if the key can outlive the task, it can outlive governance.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to Guide to the Secret Sprawl Challenge.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: When should teams move from static credentials to ephemeral identity?
A: Teams should move when the workload is short-lived, distributed, or exposed to multiple operators and systems. Those conditions make persistent secrets easier to leak and harder to govern. Ephemeral identity becomes the better fit when the credential should exist only for the live task it enables.
👉 Read our full editorial: API key leaks expose the limits of static workload identity
