10 common myths about secrets management, risks, and best practices

Secrets management keeps evolving, yet many teams still rely on old habits and outdated assumptions. They trust their existing processes to keep credentials safe, but the data tells a different story. In 2024 alone, more than 23 million secrets were exposed, with that number expected to rise in the coming years. And many of these leaks trace back to the same outdated beliefs teams continue to follow.

This article breaks down the most persistent myths in secrets management, why they keep failing, and what modern teams can do instead. You’ll learn how these misconceptions play out in real environments and how to build practical defenses that actually work.

TL;DR

Here’s a snapshot of the ten most common myths in secrets management and what teams should actually do instead.

Together, these myths reveal one core truth: secrets management shouldn't stop at storage. It should be a continuous process of secure delivery, monitoring, rotation, and audit, all handled through automation.

Myth 1: "A secrets vault is enough."

Many teams assume that once their credentials are in a secure vault, their secrets management problem is solved.

The truth

A vault or secrets manager only protects secrets at rest. Once an app retrieves a secret, the vault no longer governs its runtime usage. Secrets can still end up in logs, memory dumps, or config files, entirely outside the vault's control. A vault won't warn you if a CI job echoes a token to the console.

Best practice

A vault provides the foundation for the secure storage of secrets; however, you still need automation, monitoring, and orchestration to manage how those secrets are used and protected after they leave the vault.

• Don't let apps pull and keep secrets indefinitely. Use sidecars, agents, or APIs to inject secrets only when needed, then revoke or expire them immediately.
• Prevent unauthorized access and maintain detailed audit logs for every action.
• Combine your vault with runtime delivery tools and detection systems to ensure secrets remain controlled from creation to retirement.

Following these best practices, your vault remains the secure source of truth, while orchestration, detection, and automation handle everything that happens beyond it.

Myth 2: "Environment variables are fine for secrets."

Many teams still believe that environment variables and .env files are a safe place for secrets.

The truth

Environment variables are convenient, but they're not secure. They're shared across the entire process, persist in memory, and can leak in unexpected ways. Research shows secrets stored in environment variables often end up exposed through runtime logs, crash dumps, or debugging tools. In containerized environments, anyone with access to commands like docker inspect or container logs can easily read them in plaintext.

Best practice

Use environment variables sparingly; they're suitable for non-sensitive data, not for secrets. Instead, handle secrets dynamically, deliver them only when needed, and scrub them after use.

• Fetch secrets from a vault or secrets manager when the app starts, pass them directly to the process that needs them, and clear them immediately after use.
• Don't leave secrets sitting in global .env files or process environments. Use runtime loaders like doppler run or a custom script to inject secrets temporarily for a single session.
• In Docker, mount secrets as temporary files at runtime using bind mounts, or inject them through a secret manager so they never persist in the container's environment.

With the right approach, you can retain the ease of environment variables while preventing your secrets from leaking in memory, logs, or repositories.

Myth 3: "Kubernetes Secrets are encrypted by default."

Another popular misconception is that Kubernetes Secrets are encrypted and safe by default.

The truth

They're not. By default, Kubernetes Secrets are only Base64-encoded, not encrypted. That encoding makes it possible to store binary data. Anyone with access to etcd or the Kubernetes API can decode those secrets in seconds. You must explicitly enable etcd encryption and configure a Key Management Service (KMS) provider. Without it, your secrets sit in plaintext inside etcd.

Even with encryption enabled, weak setups can still leak sensitive information. If the encryption key is stored on the same node as etcd, a compromised host can decrypt all data. And overly broad RBAC rules often let default service accounts(or curious developers) read secrets across the cluster. To make matters worse, many teams expose these secrets as environment variables in pods, reintroducing all the same leakage risks that environment variables pose elsewhere.

Best practice

Don't treat Kubernetes Secrets as a full secret manager.

• Explicitly configure Kubernetes to encrypt Secrets using a KMS provider(like AWS KMS, GCP KMS, or AWS Secrets Manager) to strengthen access control and encryption coverage.
• Ensure proper role-based access control and give access only to the service accounts that truly need it.
• Use in-memory volumes to expose secrets as files, rather than environment variables. This prevents accidental leaks through logs or inspection commands.
• Integrate tools like Doppler to handle dynamic secrets securely at runtime, bypassing etcd altogether.

Base64 is not encryption. Unless you've explicitly enabled encryption and tightened access, assume your Kubernetes Secrets are stored in plaintext.

Myth 4: "Private repos are safe."

Many teams believe it's okay if secrets end up in a private Git repository, since only authorized people can see them.

The truth

Private repositories aren't inherently unsafe; the problem lies in how people use them. Because they feel hidden, developers often let their guard down and commit sensitive files, such as .env files, credentials, API tokens, or test configurations that they would never include in a public repository. Over time, these secrets accumulate quietly across internal projects, CI/CD pipelines, and forks.

The real security risk appears when one trusted entry point is compromised. A stolen Git token, a compromised CI account, or a third-party integration with repo access can expose everything inside. Also, since most organizations monitor private repos less aggressively than open-source ones, these leaks can remain unnoticed for months or even years.

Best practice

Treat private code with the same or even stricter security posture as public code.

• Add pre-commit or CI hooks that block pushes containing secrets, such as AWS keys, .env files, or private certificates.
• Enable GitHub's built-in secret scanning for private repositories, or use tools such as GitGuardian, TruffleHog, or Gitleaks for GitLab and Bitbucket. Make scanning continuous, not occasional.
• Keep CI/CD tokens, deploy keys, and app integrations scoped to only what they truly need. Apply the principle of least privilege across automation, just as you do for humans.
• Build your detection and response processes on the assumption that leaks will occur within your network, and utilize secrets detection tools to identify exposed secrets in commits early.

Private repositories can feel safe, but that safety is an illusion. A secret is still a secret, regardless of its location, and it needs constant monitoring and control.

Myth 5: "CI/CD masking will protect us from exposing sensitive information."

Most CI systems, including GitHub Actions, GitLab CI, Jenkins, and CircleCI, provide masking that replaces secret values in logs with ****. This reduces accidental exposure when viewing logs, but can create a false sense of safety, leading teams to believe that secrets printed in build output are harmless.

The truth

In reality, masking hides known secret values in the interface but does not prevent exposure. It relies on exact string matching, so if a secret is encoded, split, or slightly modified, the mask will not detect it, and attackers are aware of this.

Masking also fails once logs leave the platform. If they are exported to artifact storage or external log aggregators before redaction, the secrets remain intact. It provides no protection for values in memory, in child processes, or on compromised runners. CI masking is only a display filter, not a security control.

Best practice

Don't rely entirely on masking; prevent secrets from being logged at all, and treat it only as a backup.

• Review CI steps and logs to ensure no commands, errors, or debug output echo credentials or tokens. Avoid printing secrets altogether.
• Pull secrets from a vault or secrets management tools right before they're needed, then unset them after use.
• Include a step or lightweight script that scans logs for known patterns (like AKIA for AWS keys) and fails the job if any are found.
• In GitHub Actions, use techniques such as ::add-mask::value for runtime-generated secrets that aren't pre-registered.
• Test your defenses. Periodically inject dummy secrets to see whether your masking and detection rules catch them.

CI/CD platforms masking your secrets do not provide true protection. The actual defense is to keep secrets out of logs completely.

Myth 6: "Scanning tools alone protect secrets."

Some teams treat their secrets scanner as a safety net, believing it will catch every leak and make secrets management foolproof.

The truth

Scanning tools are essential, but they only treat the symptoms rather than the cause. Detection alone does not make systems secure. Scanners also have significant blind spots. They miss secrets that do not match known patterns, and false positives often flood teams until alerts are ignored. They only cover what they are configured to watch. A Git repository scanner will not catch a secret shared in Slack, a build log, or an AI chat. Relying too heavily on scanning creates a false sense of control, while leaks continue to go unnoticed elsewhere.

Best practice

Use scanning as part of a complete detect → contain → revoke → prevent cycle rather than a standalone solution.

• Detect: Continuously scan every surface where secrets might appear, including repositories, CI logs, configuration files, container images, and even chat or ticketing systems. Integrate scans into pull requests and CI pipelines to catch leaks early.
• Contain: When a leak is discovered, stop the spread. Block the merge, halt the build, or quarantine the affected artifact until it is sanitized.
• Revoke and rotate: Immediately revoke exposed credentials. Automate this process using platform APIs, such as AWS or GitHub, to disable keys as soon as they are detected.
• Prevent: Learn from each incident. Add new detection patterns, train developers, enforce the use of vaults, and include pre-commit hooks that block commits containing secrets.

While scanning increases visibility, real security depends on what happens next through containment, automation, and continuous prevention.

Myth 7: "Manual rotation is good enough."

Many teams believe that manually rotating secrets every few months or after an incident is sufficient to maintain security.

The truth

Manual rotation is unreliable, inconsistent, and slow. People forget or delay it when it risks downtime or adds extra work. GitGuardian’s State of Secrets Sprawl 2025 report reveals that many leaked secrets remain valid for years, indicating that they were likely never rotated.

Manual processes depend on discipline, but in real operations, rotation is often postponed in favor of more urgent tasks. This can result in a growing collection of stale and long-lived credentials across systems, which quietly increases the attack surface.

Best practice

Automate rotation through clear security policies and tooling so it happens reliably without human effort.

• Integrate rotation scripts or functions into CI/CD so credentials are replaced and redeployed without manual steps.
• Use safe rotation patterns. Apply double-write or blue-green strategies that generate a new secret, switch traffic to it, and then retire the old one with no downtime.
• Monitor and verify rotation. Track which secrets are rotated, when, and by what system. Alert if a secret exceeds its expected lifetime.

Unlike manual rotation, which relies on human discipline, automated rotation is driven by design. It makes secret updates predictable, auditable, and invisible to developers.

Myth 8: "Local dev isn't part of the attack surface."

Another common misconception is that local environments don't matter to attackers. Teams lock down production but overlook the secrets stored in developers' laptops and .env files.

The truth

Developers are high-value targets. Malware, phishing campaigns, and malicious IDE extensions have been caught stealing API keys, Git tokens, and .env files from local machines. Once an attacker obtains those secrets, they can move into staging or production environments.

Strong secrets management in production means little if a developer reuses credentials locally or keeps them in plaintext on disk. A single compromised workstation can expose the entire system.

Best practice

Include developer environments in your secrets management approach. Local development should be part of your threat model.

• Use separate, scoped development secrets. Developers should only access production credentials when necessary and with strict controls in place. Provide sandbox or test keys with limited privileges and isolated access.
• Adopt on-demand secrets injection. Replace static .env files with tools such as Doppler, 1Password CLI, or Azure Key Vault CLI to load secrets only when needed.
• Build security awareness and help developers understand that local does not mean safe. A lost laptop, an infected dependency, or an accidental commit can expose real production data.

In many security breaches, the weakest link is the developer's desk. If local setups are unprotected, an attacker will skip the vault and steal the keys from whoever already has them.

Myth 9: "Serverless handles access control and secret management for you."

Teams often believe that going serverless means security is handled for them, including the management of secrets. They trust the platform's built-in configuration to keep credentials safe.

The truth

Serverless eliminates server management but not secrets management. Trend Micro’s research shows that even when secrets are stored in encrypted form, such as in Azure configuration, they are decrypted and exposed as plaintext environment variables when the function runs. Those secrets remain in memory until the function is redeployed or restarted.

If a function is compromised through a vulnerability like remote code execution, an attacker can dump environment variables and extract credentials. In one documented case, researchers used a leaked Azure Function storage key to modify the function code and gain deeper access to the cloud environment.

Also, serverless platforms do not automatically rotate secrets. A Lambda function deployed with a database password can run unchanged for months or years. Even if you rotate the secret in your vault, the function continues using the old value until it is redeployed. What starts as convenience often turns into staleness, and staleness turns into risk.

Best practice

Apply the same secrets hygiene standards to serverless environments as you do to any other runtime, especially when it comes to access control and preventing unauthorized access.

• Avoid long-lived secrets in environment variables. Fetch secrets at runtime through the provider's API. Cache them in memory briefly if necessary, but refresh them frequently.
• Use cloud providers' native identity systems, such as AWS IAM roles, Azure Managed Identities, or GCP service accounts, to issue ephemeral credentials.
• Enable automatic rotation in your secrets manager and ensure that serverless functions always retrieve the most recent version on each invocation or on a defined schedule.

Serverless platforms still require the same security discipline. Use ephemeral access, automate rotation, and tightly scope permissions to ensure your functions do not run with static secrets.

Myth 10: "AI agents are not a security risk."

A growing misconception is that AI assistants like ChatGPT or GitHub Copilot are safe spaces for debugging. Developers share configurations, tokens, and logs in chats, assuming the information remains private.

The truth

AI platforms are part of your secrets surface. Shared or public AI conversations can be indexed by search engines, making any pasted API key or log output searchable and accessible to anyone. Integrations make the risk worse. Frameworks such as MCP or plugin-based AI agents often connect directly to APIs, databases, or secrets managers. A crafted prompt injection can trick these integrations into revealing secrets or running unintended commands.

AI can also introduce new security risks and vulnerabilities. Coding assistants often suggest insecure practices like hardcoding secrets or embedding tokens in code, and developers who accept these suggestions without review can accidentally ship leaks to production.

Best practice

Treat AI prompts, chats, and agent integrations as potential sources of security breaches if not appropriately handled.

• Never paste API keys, credentials, or connection strings into AI chats. If the AI needs access to data, use placeholders instead of the actual secret.
• For AI frameworks like MCP or custom plugins, isolate credentials and enforce least privilege. Ensure the model cannot directly read or print environment variables, config files, or system prompts.
• Treat user input as untrusted. Validate or sanitize instructions before the AI agent executes any connected action. Use allowlists for safe operations rather than relying on the model to decide.
• Audit any code or configuration suggested by AI tools. Watch for hardcoded secrets, exposed tokens, or removed authentication steps in model-generated code.

Treat every chat, model, and integration that touches your systems as a potential leak path. Keep secrets out of prompts, monitor what your agents access, and isolate them like any other untrusted component.

We’ve just uncovered the biggest myths and best practices, but how do you actually put them into action and build a mature secrets management workflow?

Secrets management best practices to go from myths to a mature practice

To move from myths to maturity, you need to shift your secrets management practices to be automated and auditable. The table below outlines a practical path toward stronger end-to-end control.

A mature secrets management practice oversees the entire lifecycle of secrets. That includes the complete process, from request to injection, use, revocation, and audit, with automation and visibility at every stage.

Want to see what a mature workflow looks like in practice? Try the Doppler demo to explore how a secrets management solution can automate secret delivery, rotation, and access control without building everything from scratch.