Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Secrets sprawl and credential leaks: what IAM teams need to do


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9773
Topic starter  

TL;DR: Secrets management failures keep turning convenience shortcuts into breach paths and operational outages, with exposed credentials, hardcoded keys, and leaked tokens still common in modern development and cloud workflows, according to Infisical’s guide. The governance gap is not awareness but control over where secrets live, who can fetch them, and how quickly exposure is neutralised.

NHIMG editorial — based on content published by Infisical: Secrets Management: The Complete Guide to Protecting API Keys, Credentials & Certificates

By the numbers:

Questions worth separating out

Q: How should security teams handle leaked secrets in cloud and CI/CD environments?

A: Treat every leaked secret as a live identity problem, not just a code cleanup task.

Q: Why do long-lived service credentials increase breach risk?

A: Long-lived credentials create standing privilege, which gives attackers time to find, reuse, and move through systems after a leak.

Q: What do teams get wrong about secret rotation?

A: Many teams rotate secrets but leave the surrounding entitlement model unchanged.

Practitioner guidance

  • Inventory every secret class Build a single inventory for API keys, tokens, certificates, cloud access keys, and signing material.
  • Replace static secrets with short-lived credentials Use workload identity or dynamic secrets wherever the platform supports them, especially for CI/CD jobs and service-to-service access.
  • Reduce blast radius through least privilege Give each workload only the specific secret scope it requires, and separate production from development and staging.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

  • Concrete rotation patterns for database, cloud, API, and certificate secrets across development and production.
  • Implementation detail for vault-backed workflows, including access policies, lease handling, and audit logging.
  • Product-specific guidance on CI/CD integrations, secrets scanning, and developer handoff flows.
  • Decision criteria for when to use dynamic secrets, workload identity, or short-lived tokens in practice.

👉 Read Infisical's guide to protecting API keys, credentials, and certificates →

Secrets sprawl and credential leaks: what IAM teams need to do?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 9257
 

Secret sprawl is no longer a secrets hygiene issue, it is an identity governance failure. Once credentials are scattered across code, chat, contractors, and cloud services, no team can reliably prove ownership, scope, or revocation state. That is an NHI control problem because every secret behaves like an identity with a lifecycle, not like inert configuration. Practitioners should treat credential inventory and entitlement tracking as part of identity governance, not an adjacent DevOps task.

A few things that frame the scale:

  • Hardcoded secrets on GitHub roughly doubled in 2025 and more than 90% of those secrets remained valid and exploitable five days after disclosure, according to The State of Secrets Sprawl 2026.
  • GitGuardian also found: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows how quickly new AI-connected surfaces become credential leakage points.

A question worth separating out:

Q: How do identity teams know whether secrets management is actually working?

A: Look for fewer static credentials, faster revocation after exposure, clear ownership for each secret, and audit logs that show who or what accessed each value. If teams still rely on spreadsheets, shared .env files, or manual handoffs, the programme is not controlling secrets lifecycle risk yet.

👉 Read our full editorial: Secrets management failures are still driving breach and outage risk



   
ReplyQuote
Share: