Top 10 Secrets Management Mistakes

Most organisations that lose a secret already own a vault; the failure is in how secrets are created, shared, rotated and revoked around it. API keys, tokens, database passwords, certificates and private keys are the credentials of non-human identities, and attackers go looking for them in code, images, logs and chat because they rarely carry MFA. This list covers the ten common secrets management mistakes and anti-patterns we see most often, from secret handling errors in code to failures in leak response: why each one matters, an incident where it played a part, and the fix. It is for platform, DevOps, application security and identity teams who want to know where their secret handling will fail before an attacker finds out. For the programme view see the Secrets Management Guide.

The Top 10 at a glance

1. Hardcoding secrets in code, images and configuration
2. Letting secrets sprawl outside the manager
3. Long-lived secrets that never expire
4. Manual rotation that nobody trusts
5. Over-shared vaults and broad read access
6. Reusing one secret across environments and services
7. Static cloud keys in CI/CD pipelines
8. Leaking secrets through logs, environment variables and artifacts
9. No owner, no inventory and no access audit
10. Weak leak response: deleting instead of revoking

1. Hardcoding secrets in code, images and configuration

The mistake: credentials written into source code, configuration files, infrastructure templates, mobile app bundles or Dockerfiles, on the assumption that a private repository or a compiled binary keeps them hidden.

Why it matters: this is CWE-798, Use of Hard-coded Credentials, and ATT&CK T1552.001 (Credentials In Files) describes attackers searching for exactly these files. Private is not safe: the Uber 2016 breach began with an AWS key in a private GitHub repository. Container images are a common blind spot, because the OWASP CI/CD Top 10 notes that secrets used only at build time can persist in image layers that anyone who downloads the image can read; the Docker Hub secrets leak found cloud, CI and AI keys in more than 10,000 public images.

The fix: deliver secrets at runtime from a secrets manager or the orchestrator, never through Docker ENV or ARG (OWASP Secrets Management Cheat Sheet, section 5.1). Turn on commit-time blocking, for example GitHub push protection, which stops secrets in command line pushes, web commits, file uploads and REST API calls, but is disabled by default at repository level. See the Guide to the Secret Sprawl Challenge.

2. Letting secrets sprawl outside the manager

The mistake: the vault exists, but copies of the same credentials also live in wikis, tickets, chat threads, spreadsheets, CI variables, local .env files and team password managers, with no record of which copy is current.

Why it matters: every copy is a separate exposure that rotation will miss. ATT&CK lists Chat Messages (T1552.008) as its own credential access sub-technique, and the JSONFormatter and CodeBeautify leak showed secrets pasted into online tools surviving in saved links. Exposed .env files fed the 230 million AWS environments campaign.

The fix: make one manager the system of record per platform and treat any other location as a finding. OWASP advises standardising and centralising "with care", and scanning for many secret types (API keys, connection strings, private keys, session tokens) using more than one detection method. Extend scanning to chat, ticketing, wikis, registries and build logs.

3. Long-lived secrets that never expire

The mistake: API keys, personal access tokens, service account passwords and SSH or deploy keys issued with no expiry, or with an expiry set years ahead.

Why it matters: OWASP NHI7:2025 (Long-Lived Secrets) warns that a leaked long-lived secret gives attackers extended access with no time limit. The Toyota T-Connect key exposure involved an access key that sat on public GitHub for five years. GitHub's own documentation describes deploy keys as "credentials that don't have an expiry date" that stay active after their creator leaves.

The fix: prefer credentials that expire on their own: OWASP says "You should create secrets to expire after a defined time where possible", and recommends dynamic secrets with short leases. Enforce maximum lifetimes in platform policy (GitHub organisations, for example, can block fine-grained tokens that exceed a maximum lifetime) and report every secret older than its rotation period. See the API Key Management Guide.

4. Manual rotation that nobody trusts

The mistake: rotation is a ticket, a runbook and a maintenance window, so it happens late, rarely or never, and every rotation risks an outage because consumers still hold the old value.

Why it matters: a secret that cannot be rotated safely cannot be revoked quickly in an incident either. OWASP notes that manual rotation is error-prone and that restarting an application does not revoke stolen credentials: they stay valid until the backing service expires or revokes them.

The fix: automate rotation with an overlap. AWS Secrets Manager supports rotation as often as every four hours with "Single user" and "Alternating users" strategies; the alternating model keeps one credential valid while the other changes. Google Secret Manager advises referencing secrets "by their version number rather than using the latest alias" so a new version can be validated and rolled back, and disabling old versions before destroying them. Azure Key Vault supports autorotation for keys, secrets and certificates. Rehearse rotation on a schedule so the first one is not during a breach.

5. Over-shared vaults and broad read access

The mistake: one vault, project or namespace holds secrets for many applications and environments, and engineers, pipelines and service accounts get read access to all of it.

Why it matters: one compromised identity then reads everything. OWASP is direct: "engineers should not have access to all secrets in the secrets management system" and "Secrets should never be retrievable by everyone and everything." Management-plane roles matter too: the Azure Key Vault Contributor escalation showed how a role described as having no data access could still reach every secret. In Kubernetes, list and watch on Secrets return their values, and Secret data is only base64 encoded, not encrypted, unless encryption at rest is configured.

The fix: scope by application and environment. Microsoft's guidance is "Use one Key Vault per application, region, and environment", with Azure RBAC instead of legacy access policies; Google recommends secret-level IAM bindings when many services share a project, and separate projects for staging and production; AWS recommends least privilege through IAM, resource policies and ABAC, plus the secretsmanager:BlockPublicPolicy condition on PutResourcePolicy. Protect the vault itself with soft delete, purge protection, private endpoints and just-in-time administrator access. See the Secrets Management Buyer's Guide.

6. Reusing one secret across environments and services

The mistake: development, test and production share a database password or API key, or several services authenticate with the same service account credential because it was quicker.

Why it matters: OWASP NHI8:2025 (Environment Isolation) and NHI9:2025 (NHI Reuse) both describe this: a leak from a test system or a low-value service becomes a path into production and every other component that shares the identity. Reuse also destroys attribution and makes revocation all-or-nothing.

The fix: issue a unique credential per workload and per environment, in separate vaults or projects, and block production secrets from non-production identities by policy. The OWASP CI/CD Top 10 (CICD-SEC-6) adds usage conditions, such as source IP or calling identity, so a stolen credential is useless elsewhere. See the Service Account Security Guide.

7. Static cloud keys in CI/CD pipelines

The mistake: pipelines hold long-lived cloud access keys, registry passwords and publishing tokens as repository or organisation secrets, available to every job and often every branch.

Why it matters: a pipeline runs code that many people and dependencies can influence, so one poisoned step can read every secret in scope. The tj-actions/changed-files compromise (CVE-2025-30066) exposed secrets from thousands of repositories, and CISA advised that identified secrets "should be considered compromised". The CircleCI breach put every customer's stored CI secrets at risk at once.

The fix: CICD-SEC-6 says "Prefer using temporary credentials over static credentials." Use OIDC workload identity federation so jobs exchange a short-lived token for cloud access (GitHub lists "No cloud secrets" as the first benefit), bind trust to repository, branch or environment claims, and keep any remaining publishing secrets in protected environments that require approval. See the CI/CD Pipeline Identity Security Guide.

8. Leaking secrets through logs, environment variables and artifacts

The mistake: secrets are passed as environment variables or command line arguments, printed by debug output, captured in crash dumps or uploaded inside build artifacts, on the assumption that log masking will catch them.

Why it matters: OWASP warns that environment variables "may be included in logs or system dumps" and are "not recommended unless the other methods are not possible"; Google Secret Manager guidance also says to avoid passing secrets through the file system or environment variables, preferring the API client libraries. Masking matches exact values only: CISA noted that in the tj-actions incident secrets "may be obfuscated as a double-encoded base64 payload". The ArtiPACKED research found live tokens inside public workflow artifacts.

The fix: deliver secrets through mounted files with tight permissions or direct API retrieval, never on the command line. Register any derived value (a decoded or concatenated secret) as a secret so it is redacted. Scan build logs, artifacts, images and Helm charts as well as code, as CICD-SEC-6 recommends, and have a process for purging secrets from logs without breaking log integrity (OWASP section 9.2).

9. No owner, no inventory and no access audit

The mistake: nobody can list the organisation's secrets, say who owns each one, or show who read it last week; offboarding removes the person but not the keys they created.

Why it matters: an unowned secret is never rotated, never reviewed and never revoked. OWASP NHI1:2025 (Improper Offboarding) covers credentials that outlive their purpose: in the Coupang breach a former engineer's unrevoked signing key exposed 33.7 million accounts.

The fix: give every secret an owner, purpose, consumer list and rotation date as metadata. Turn on access logging: Google recommends Data Access logs for AccessSecretVersion; AWS records Secrets Manager calls such as GetSecretValue in CloudTrail; Azure Key Vault audit logging records vault operations. OWASP asks for tamper-resistant audit of who requested a secret, when it was used and rotated, and authentication or authorisation errors. Alert on reads from new identities, networks or volumes. See the NHI Ownership Guide.

10. Weak leak response: deleting instead of revoking

The mistake: when a secret is found in a commit, the team deletes the file or rewrites history and considers the matter closed, or tracks the finding for weeks before rotating.

Why it matters: GitHub states that you must first "revoke and/or rotate that secret", and that "You cannot remove sensitive data from other users' clones of your repository"; the commit can also remain reachable in forks and cached views. Slow response is common: the Home Depot token exposure left internal systems open for more than a year, and in the Internet Archive breach unrotated keys led to a second breach within a month.

The fix: follow OWASP section 9.2: revoke immediately, issue the replacement (ideally by automation), then remove the secret from the exposed system. Check provider logs for use of the old credential during the exposure window, review push protection bypasses (reasons such as "I'll fix it later" create open alerts), and document who is alerted when a secret is detected. See the Leaked Credential Response Playbook.

Mapping to OWASP

CICD-SEC-2 is Inadequate Identity and Access Management, CICD-SEC-4 Poisoned Pipeline Execution, CICD-SEC-5 Insufficient PBAC (Pipeline-Based Access Controls), CICD-SEC-6 Insufficient Credential Hygiene and CICD-SEC-10 Insufficient Logging and Visibility. In NIST SP 800-53 the closest controls are IA-5 Authenticator Management (with enhancement IA-5(7), no embedded unencrypted static authenticators), AC-6 Least Privilege and AU-6 Audit Record Review.

Where to start

These secrets management pitfalls compound, and the top secrets management risks are rarely a single error: a hardcoded, long-lived, widely shared key with no owner is the common thread in most of the incidents above. If you can do only three things this quarter: turn on commit-time blocking and scan repositories, images and build logs (mistakes 1 and 8), replace static cloud keys in pipelines with OIDC federation (mistake 7), and rehearse revoke-and-rotate for your ten most powerful secrets (mistakes 4 and 10). Track five numbers monthly: secrets older than their rotation period, secrets without a named owner, new secrets detected outside the manager (and median time to revoke them), pipelines still holding static cloud keys, and identities with read access to more than one application's secrets.

Standards and references

• OWASP: Secrets Management Cheat Sheet
• OWASP: Non-Human Identities Top 10 (2025)
• OWASP: CICD-SEC-6 Insufficient Credential Hygiene
• MITRE: CWE-798 Use of Hard-coded Credentials
• MITRE ATT&CK: T1552.001 Credentials In Files
• CISA: Supply Chain Compromise of Third-Party GitHub Action (CVE-2025-30066)
• GitHub Docs: Removing sensitive data from a repository
• GitHub Docs: About push protection
• Microsoft Learn: Best practices for using Azure Key Vault
• AWS: Secrets Manager best practices
• Google Cloud: Secret Manager best practices

Related NHI Mgmt Group resources: Secrets Management Guide · Top 10 NHI Issues · Leaked Credential Response Playbook · Guide to the Secret Sprawl Challenge