Notifications
Clear all
Topic starter
08/07/2026 6:50 pm
TL;DR: Breaches at Trivy, LiteLLM, Axios, and Vercel show the same pattern: secrets, tokens, and keys were easy to copy and hard to verify after exposure, according to Infisical. The real failure is not developer carelessness but a security model built on static credentials that cannot fail safely.
NHIMG editorial — based on content published by Infisical: Postmortem-Driven Development
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: How should security teams reduce risk from secrets exposed in code and CI/CD pipelines?
A: Security teams should remove reusable secrets from code and CI/CD wherever possible, then replace them with short-lived, scoped credentials issued at runtime.
Q: Why do static credentials create more risk in AI-assisted software delivery?
A: Static credentials create more risk because AI-assisted delivery increases the volume of generated code and the chance that secrets appear in places humans do not fully review.
Q: What do security teams get wrong about secrets rotation?
A: Teams often treat rotation as the primary control, when the bigger issue is whether the secret should exist at all.
Practitioner guidance
- Eliminate static secrets from code paths Inventory repositories, CI/CD variables, and build artefacts for long-lived API keys, tokens, and certificates, then replace them with runtime-issued or federated credentials wherever the platform supports it.
- Shorten credential validity windows Set aggressive TTLs for machine credentials and tie them to task scope so a leaked secret expires before it can be reused across environments.
- Treat leaked secrets as active incidents Automate detection, revocation, and replacement workflows so exposure in code or pipelines triggers containment before attackers can pivot through cloud APIs or registries.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- The article's step-by-step argument for replacing static secrets with identity-based authentication in software delivery.
- The practical rationale for short-lived, scoped access when CI/CD and AI-generated code increase leak frequency.
- The article's security engineering analogy for designing credentials that fail safely instead of assuming perfect prevention.
- The specific examples of leaked secrets in recent breaches that support the article's broader thesis.
👉 Read Infisical's analysis of static secret risk in AI-assisted software delivery →
Static secrets in AI code pipelines: what IAM teams are missing?
Explore further
08/07/2026 7:10 pm
Static secret trust has become a broken premise, not just a weak control. Static credentials were designed for environments where code moved slowly, review was deep, and human operators could keep pace with exposure. That assumption fails when AI accelerates code creation and attackers can search for secrets at machine speed. The implication is that identity programmes need to stop treating leaked credentials as rare exceptions and start treating them as an expected state condition.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable when a leaked API key is reused for broader compromise?
A: Accountability should sit with the team that owns the credential lifecycle, not just the application that used it. That means platform, IAM, and application owners need a shared revocation path, clear ownership for every secret, and evidence that offboarding and replacement happened when the secret’s purpose changed.
👉 Read our full editorial: AI code breaches expose the limits of static secret security
