Secrets Management: Why Passwords in Code Are Risky

Secrets are database passwords, API keys, tokens, private keys and certificates. When they live in code, configuration files or CI variables, any leak of a repository becomes a leak of access to the infrastructure. The right approach is a single store, identity-based access, least privilege, short-lived credentials and auditing.

Where secrets usually live

• Directly in source code and git history: even a deleted secret remains in the commit history
• In configuration files and Docker images (OWASP specifically warns against secrets in Dockerfile ENV and ARG instructions)
• In CI/CD variables accessible to too wide a circle of people
• In messengers, wikis and spreadsheets

This phenomenon is called secret sprawl. The more copies there are, the harder it is to know who has access, and the more expensive rotation becomes.

Why this is dangerous in practice

A secret in code is visible to everyone with access to the repository: developers, contractors, and CI service accounts. If the repository reaches the outside world, an attacker gets working credentials without breaking into anything. Reverting a commit does not help, because the secret stays in the history, so a discovered secret must be treated as compromised and replaced. An additional problem is long-lived passwords: a stolen permanent password works until someone notices the leak.

Principles of proper secrets management

These principles match the recommendations of the OWASP Secrets Management Cheat Sheet:

1. Centralization. One protected solution instead of dozens of places, so teams know what each secret is for and where it is stored.
2. Identity-based access and least privilege. Access is granted to specific secrets, not to the whole store; CI service accounts receive only what their tasks require.
3. Short-lived credentials. Instead of a permanent password, a temporary one is issued for a limited time and revoked after use.
4. Automatic rotation. Regularly changing secrets limits how long stolen data stays useful.
5. Auditing. The log records who requested a secret and when, whether it was approved, and which attempts failed.

How HashiCorp Vault addresses this

HashiCorp Vault is one of the most widely used secrets management solutions:

• Secrets: centralized storage and programmatic issuance of secrets through an API.
• Dynamic secrets: Vault attaches a lease with a time to live (TTL) to each dynamic secret; when the lease expires or is revoked, the secret stops working. For example, the database secrets engine creates a user according to a role and revokes it when the lease expires (by default 1 hour according to the documentation, with a maximum of 24 hours).
• Static roles with rotation: for existing accounts, Vault can store the password and change it on a schedule.
• Certificates: issuance, rotation and revocation of certificates on demand.
• Encryption as a service: encrypting data without storing keys in the application.
• Integrations with Kubernetes, CI/CD, cloud platforms and LDAP/AD.

Dynamic secrets have a notable advantage for investigations: each service instance receives its own credentials, so a suspicious database request can be traced to a specific instance. If you are choosing between Vault and alternatives, read the comparison of HashiCorp Vault, CyberArk Conjur and cloud KMS.

Where to start

1. Scan repositories for secrets (SAST-class tools such as DerScanner find hardcoded passwords and keys). OWASP recommends using several secrets-detection tools and comparing their results, and running checks at the developer level (pre-commit, IDE) and in CI.
2. Rotate the secrets you found: treat them as compromised.
3. Deploy the store and move the most critical systems to it first.
4. Add a CI/CD check that prohibits new secrets in code. Technical details are in SAST and SCA in GitLab CI.
5. Set up logging of access and alerts for suspicious requests.

Secrets management is one step in the overall secure development roadmap; the other steps are described in DevSecOps: where to start.

Secrets in CI/CD and containers

Build pipelines are one of the most vulnerable points. CI service accounts often have broad permissions, and environment variables are visible to everyone who can modify job configuration. OWASP recommendations for CI/CD: limit service account permissions to only the secrets they need, alert on secret extraction, and do not allow secrets to be inherited by repository forks. CI/CD logs can also expose secrets if the tool prints variables, so they must be reviewed and stored with access control.

In containers, the main risk is "baking" a secret into the image. Anything passed via ENV or ARG in a Dockerfile stays in the image layers and is available to anyone who obtains the image. Instead, secrets should be issued to the application at startup from the store, keeping the image clean.

Common mistakes

• One shared password for everyone. It is impossible to tell who did what, and rotation affects everyone at once.
• A store with no access restrictions. If any engineer can read all secrets, you have only moved the problem elsewhere.
• No rotation plan. A secret that cannot be replaced painlessly is effectively permanent.
• No auditing. Without an access log, incident investigation turns into guesswork.
• A single root key in plain text. The store's own root credentials must also be protected in a secondary system.

How to migrate without stopping development

It is better to migrate application by application rather than in a "big bang". For each application, the sequence is roughly: inventory the secrets, create access policies in the store, move the secrets, change the code or configuration to fetch secrets at runtime, verify, and only then delete the old copies and rotate. Start with the systems where a leak would have the most severe consequences: databases with personal and payment data, cloud accounts, and signing keys. After migration, old values must be replaced, otherwise they continue to live in repository history and backups.

How a secrets store differs from a password manager

A password manager is designed for people: it helps store personal and shared passwords and fill them into forms. A secrets store such as Vault is designed for machines and automation: applications, services and pipelines authenticate with their own identity, retrieve secrets through an API, and policies define exactly what each of them can access. Beyond storage, such a solution can issue dynamic credentials, rotate them, encrypt data as a service and keep a detailed log. That is why a password manager cannot replace a secrets store, although it remains useful for employees' personal needs.

Roles and processes around the store

The store alone does not solve the problem without roles and procedures. Define who administers the store, who approves access policies, who is responsible for rotation and who responds to incidents. Separate responsibilities: the platform administrator does not need access to the contents of all secrets. Describe the emergency access and recovery procedure in advance, so that losing one key or one employee does not stop all systems.

How to verify that everything works

After deployment, regularly ask yourself several questions and check the answers in practice:

• Can you find at least one working secret in the repositories or images? If so, the process is not complete.
• How long would it take to replace a compromised key, and how many systems would need to be restarted?
• Who among the employees and services can read the most sensitive secrets, and do they really need to?
• What happens if an employee with broad access leaves the company or their account is compromised?
• Do you see unusual access in the log: new addresses, atypical times, repeated failures?

If the answers are hard to give, it is a signal to refine access and rotation policies. Regular exercises, such as simulating a key leak and replacing the key in production, show how ready the process really is, rather than how well it is described in the procedures.

Frequently asked questions

Sources

• OWASP Secrets Management Cheat Sheet
• HashiCorp Vault: Lease, Renew, and Revoke
• HashiCorp Vault: Database secrets engine