Static Secret

Expanded Definition

A static secret is a credential that stays valid until a person or system changes it manually, such as an API key, token, password, or certificate. In NHI programs, the distinction matters because static secrets create long-lived trust without a built-in expiry signal, unlike dynamic secrets issued for a narrow purpose and time window.

Usage in the industry is still evolving because some vendors bundle static secrets with broader secret management, while others treat them as a separate risk class alongside service account credentials. That is why guidance from the OWASP Non-Human Identity Top 10 focuses less on the label and more on the operational behavior: where the secret lives, who can retrieve it, how often it rotates, and whether it can be revoked quickly after exposure.

The most common misapplication is treating a static secret as if it were a managed identity, which occurs when teams assume periodic review is enough even though the credential can persist across code, CI/CD systems, and infrastructure long after ownership changes.

Examples and Use Cases

Implementing static secret controls rigorously often introduces rotation overhead, requiring organisations to weigh operational simplicity against the risk of persistent compromise.

• A legacy application uses a database password stored in a config file because it cannot yet authenticate with a workload identity. The secret is static, so rotation must be planned and tested, not assumed.
• A build pipeline injects an API key at runtime, but the key is reused for months. The attack path described in the Reviewdog GitHub Action supply chain attack shows how exposed secrets can spread quickly once CI/CD trust is broken.
• A contractor receives a shared service password for testing and leaves the project, but the password remains valid. This is a classic static secret failure because ownership changed while access did not.
• A team uses an application token for SaaS integration instead of short-lived federation, which may be acceptable for compatibility but demands strict vaulting and revocation discipline.
• A multi-environment deployment reuses one credential across dev, staging, and production. That reduces friction, but it also expands blast radius if the secret leaks into source control or logs, a pattern reflected in the Guide to the Secret Sprawl Challenge.

For implementation context, static secrets should be evaluated against the same least-privilege and lifecycle expectations discussed in the OWASP Non-Human Identity Top 10, even when the application cannot yet support dynamic issuance.

Why It Matters in NHI Security

Static secrets are one of the most common ways NHIs become overexposed because they are easy to distribute and hard to track. NHI Mgmt Group research shows that 91.6% of secrets remain valid five days after the targeted organisation is notified, which means remediation often lags behind discovery. That delay turns a simple credential leak into an enduring access problem.

This matters in secret governance, cloud operations, and agentic systems where an AI agent or automation tool may hold enough privilege to move laterally if a static secret is reused. The risk is not only theft, but also the inability to prove that a credential is no longer in circulation. The 52 NHI Breaches Analysis and the Shai Hulud npm malware campaign both reinforce how quickly exposed secrets can be harvested and reused.

Organisations typically encounter the operational cost of static secrets only after a leak, incident response, or audit finding, at which point rotation becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between an identity, a credential, and a secret?
• What is the difference between static and dynamic credentials?
• What is the primary security risk of static credentials?
• How do I migrate from static credentials to dynamic credentials?