What is secrets management?
Secrets management is the practice of securely storing, controlling access to, and managing digital credentials like passwords, API keys, and certificates. This means protecting the sensitive information that applications and services use to authenticate with each other and access resources automatically.
Unlike password management for human users, secrets management focuses on programmatic credentials. These are the API keys, tokens, and certificates that applications, microservices, and automated scripts use to communicate without human intervention. Think of them as the digital keys that let your software talk to databases, cloud services, and other applications.
The shift to cloud-native architectures has made secrets management more complex. Modern applications might use dozens or hundreds of different credentials to connect with various services, databases, and APIs across multiple cloud environments.
Secure Coding Best Practices
Learn how to prevent hardcoded secrets, implement secure authentication patterns, and build security into your development workflow from day one,
Types of secrets and where they live
Secrets come in many forms, and they hide in more places than most teams realize. Understanding what counts as a secret and where to look for them is the first step in building comprehensive protection.
Common secret types include:
API keys and tokens: Third-party service credentials (Stripe, Twilio, SendGrid), internal service authentication tokens, OAuth access and refresh tokens
Cloud access credentials: AWS access keys and secret keys, Azure service principal credentials, GCP service account keys
Database credentials: Connection strings with embedded passwords, database user credentials, Redis/MongoDB authentication tokens
Certificates and keys: TLS/SSL private keys, SSH private keys, code signing certificates, JWT signing keys
Application secrets: Session encryption keys, webhook signing secrets, feature flag service tokens, encryption keys for data at rest
Where secrets typically hide:
Source code repositories: Hardcoded in application code, committed in configuration files, embedded in infrastructure-as-code templates
Container images: Baked into Dockerfiles, stored in environment variable defaults, embedded in application layers
CI/CD systems: Pipeline environment variables, build scripts, deployment configurations, runner secrets
Configuration management: Kubernetes ConfigMaps (often misused for secrets), Ansible playbooks, Terraform state files, Helm chart values
Logs and monitoring: Application logs capturing API responses, build logs showing environment variables, error messages containing connection strings
Documentation and tickets: Wiki pages with setup instructions, Jira tickets with troubleshooting steps, Slack messages with quick fixes
Developer workstations: Local environment files (.env), shell history, IDE configuration files, local credential caches
The challenge isn't just protecting secrets in production—it's tracking them across every stage of development, from a developer's laptop to production runtime.
Why secrets management is critical for cloud security
Secrets are prime targets for attackers because they provide direct access to systems and data. Recent industry reports highlight credential theft as a leading cause of breaches, with compromised API keys, tokens, and passwords frequently involved in successful attacks (for example, see this overview). A single compromised API key can let an attacker move through your cloud environment, escalate their privileges, and reach your most valuable assets.
The biggest challenge today is "secret sprawl." This happens when secrets get scattered across source code repositories, configuration files, container images, and developer tools. Research shows that once secrets leak, they often remain active and exploitable for extended periods—creating persistent security risks (report). When credentials are everywhere, it becomes nearly impossible to track who has access to what.
Many organizations struggle to enable collaboration between security and development teams while maintaining consistent security standards. Without centralized secrets management, security teams lack visibility into what credentials developers are using, and developers face friction when trying to access the secrets they need for their work.
Compliance and regulatory requirements
Effective secrets management isn't just a security best practice—it's a compliance requirement across major frameworks. Proper credential handling, access control, and audit logging provide the evidence auditors need to verify your security controls.
Key compliance framework mappings:
SOC 2 Type II: CC6 (Logical and Physical Access Controls) requires restricting access to sensitive information and credentials; CC7 (System Operations) requires monitoring and logging of access to sensitive data and credentials
ISO 27001:2022: Annex A.9 (Access Control) covers credential management and least privilege; Annex A.10 (Cryptography) requires encryption of sensitive authentication information
PCI DSS 4.0: Requirement 3 (Protect Stored Account Data) includes encryption of authentication credentials; Requirement 7 (Restrict Access) requires least privilege for system credentials; Requirement 8 (Identify Users and Authenticate Access) covers credential management and rotation
HIPAA Security Rule: Requires unique user identification and proper credential management for systems handling protected health information
Common secrets management challenges
Organizations face several obstacles when implementing effective secrets management. These challenges often stem from outdated practices and lack of visibility into where secrets actually live.
Manual secret sharing creates major security risks. When teams share credentials through email, chat apps, or shared documents, there's no audit trail and secrets can be exposed or misused. Common insecure practices include storing secrets in spreadsheets, messaging apps, and shared documents—creating multiple points of exposure (see discussion).
Hardcoded credentials represent one of the most common problems. Developers often embed secrets directly into source code, container images, configuration files, and build or runtime logs. Secrets in logs are particularly dangerous because they're often retained long-term, replicated to multiple systems, and accessible to broad teams. This makes secrets visible to anyone with code access and extremely difficult to change without updating the code.
Static, long-lived secrets increase risk over time. The longer a secret exists unchanged, the more likely it is to be exposed or abused. Long-lived credentials lack scope constraints like IP restrictions or resource scoping, meaning a single compromised key can grant broad access. Research shows that 35% of exposed API keys remain active and vulnerable to exploitation (source).
Visibility gaps plague large, distributed environments. Security teams can't protect what they can't see, and tracking secrets across multiple clouds, applications, and teams becomes nearly impossible without proper tooling.
Tool fragmentation happens when different teams use their own methods for managing secrets. This creates inconsistent policies and security gaps that attackers can exploit.
Secrets management best practices
Building a strong secrets management foundation requires following proven practices that address common vulnerabilities and operational challenges.
Centralize secret storage
Move all secrets into a dedicated secrets management platform instead of leaving them scattered across different systems. This creates a single source of truth where you can enforce consistent policies, monitor all access, and manage the complete lifecycle of your credentials from one location.
Implement least privilege access
Grant applications and users only the minimum permissions they need to function. Use time-bound access that automatically expires after a set period when possible. This principle limits the potential damage if credentials are compromised.
Automate rotation
Set up automated schedules to regularly rotate all types of secrets, from database passwords to API keys, and implement event-driven revocation workflows. When secret scanning detects exposed credentials in repositories, logs, or tickets, automatically revoke them and notify owners. Manual rotation is error-prone and often forgotten, while automation ensures credentials are refreshed consistently and reduces the window for attackers to use stolen credentials.
Remove hardcoded secrets
Actively scan your codebase, configuration files, and container images to find embedded secrets. Replace them with dynamic retrieval mechanisms that fetch credentials from your central vault at runtime. This eliminates one of the most common sources of credential exposure.
CI/CD Pipeline Security Best Practices
Discover how to embed automated security checks, protect secrets, and enforce least privilege in your build systems with our practical guide.
Enable comprehensive auditing
Log every action related to your secrets, including who accessed what, when they accessed it, and what changes were made—but never log the secret values themselves. Implement log redaction and scanning to detect and remove any secrets that appear in logs. These audit trails are essential for security monitoring, incident investigation, and compliance reporting. Configure alerts for anomalous access patterns like unusual source IPs, off-hours access, or bulk secret retrievals.
Encrypt everything
Ensure all secrets are encrypted both at rest and in transit using industry-standard mechanisms. Encrypt secrets at rest using cloud KMS or HSM-backed keys with envelope encryption (encrypt data keys with master keys). Use TLS 1.2 or higher for all secret transmission. Implement automated key rotation policies for your encryption keys, and ensure your vault supports cryptographic key separation (different keys for different secret types or environments).
Use dynamic secrets
Move away from static, long-lived credentials whenever possible. Use short-lived, dynamic secrets that are created on-demand and automatically expire—typically within 1-24 hours depending on the use case. Cloud-native examples include AWS STS temporary credentials, Azure managed identities, GCP Workload Identity Federation, and HashiCorp Vault's dynamic secret engines for databases. For CI/CD pipelines, use OIDC federation (GitHub Actions → AWS, GitLab → GCP) instead of storing long-lived cloud access keys.
Adopt short-lived credentials and workload identity federation
The most secure credential is one that doesn't exist for long. Modern cloud platforms enable workload identity federation, where applications prove their identity through trusted identity providers instead of storing long-lived static keys.
How workload identity federation works:
Your application or CI/CD pipeline obtains a short-lived token from a trusted identity provider (GitHub, GitLab, Kubernetes service account)
It presents this token to the cloud provider (AWS, Azure, GCP)
The cloud provider validates the token and issues temporary cloud credentials (typically valid for 1-12 hours)
The application uses these temporary credentials, which automatically expire
Common implementations:
GitHub Actions → AWS: Use OIDC federation to assume AWS IAM roles without storing AWS access keys in GitHub secrets
GitLab CI → GCP: Configure workload identity federation to access GCP resources using GitLab's JWT tokens
Kubernetes → Cloud APIs: Use AWS IRSA (IAM Roles for Service Accounts), Azure managed identities, or GCP Workload Identity to grant pods cloud access without static credentials
HashiCorp Vault dynamic secrets: Generate temporary database credentials, cloud access keys, or SSH certificates on-demand with automatic expiration
Benefits over static credentials:
Reduced blast radius: Compromised credentials expire automatically, limiting attacker dwell time
Simplified rotation: No manual rotation needed—credentials are always fresh
Audit trail: Each credential issuance is logged with context about the requesting workload
Least privilege: Credentials can be scoped to specific resources and actions for each request
When implementing workload identity, start with CI/CD pipelines (where long-lived keys are commonly stored) and gradually extend to application workloads.
Harden Kubernetes secrets management
Kubernetes Secrets provide basic credential storage, but they require additional hardening to meet production security standards. Default Kubernetes Secrets are only base64-encoded (not encrypted) and stored in etcd, making them vulnerable if the cluster is compromised.
Essential Kubernetes secrets hardening steps:
Enable encryption at rest: Configure a KMS provider (AWS KMS, Azure Key Vault, GCP Cloud KMS) to encrypt secrets in etcd using envelope encryption
Use external secret management: Deploy Secrets Store CSI Driver or External Secrets Operator to inject secrets from external vaults (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) directly into pods without storing them in etcd
Prefer volume mounts over environment variables: Mount secrets as files in volumes rather than exposing them as environment variables, which are visible in pod specs and process listings
Implement RBAC restrictions: Limit which service accounts can read secrets using Kubernetes RBAC; avoid granting broad secrets/get permissions
Use immutable secrets: Set immutable: true on secrets that shouldn't change to prevent accidental or malicious modification
Avoid ConfigMaps for sensitive data: ConfigMaps are designed for non-sensitive configuration and lack the access controls and audit logging of Secrets
Implement admission control: Use OPA Gatekeeper or Kyverno policies to prevent pods from mounting secrets they don't need or running with excessive privileges
Scan container images: Integrate image scanning in CI/CD to detect hardcoded secrets before images reach the cluster; use admission controllers to block images with known secret exposures
Supply chain security for secrets:
Generate and sign SBOMs (Software Bill of Materials) for container images to track which secrets or credentials they require
Use image signing and verification (Sigstore, Notary) to ensure only approved images run in production
Implement network policies to restrict which pods can communicate with secret management services
Kubernetes secrets management requires defense in depth—combine encryption, external vaults, RBAC, and admission control to build a robust posture.
Responding to exposed secrets: A step-by-step runbook
When secrets are exposed—whether discovered in a public repository, leaked in logs, or detected by scanning tools—fast, systematic response is critical. Here's how to contain and remediate the exposure.
1. Detect and confirm the exposure
Identify what secret was exposed (API key, database password, cloud credential)
Determine where it was exposed (public repo, logs, container image, ticket system)
Confirm the secret is still active (test if it works)
Document the exposure time window (when was it first exposed?)
2. Immediately revoke the exposed secret
Disable or delete the credential in the source system (cloud console, API provider, database)
Don't just rotate—revoke first to prevent ongoing abuse
For cloud credentials, check for attached policies or permissions that might have been modified
3. Rotate to a new secret
Generate a new credential with the same permissions
Update all legitimate applications and services to use the new secret
Test that services work with the new credential before completing revocation
4. Assess potential abuse
Search audit logs (CloudTrail, Azure Activity Log, GCP Audit Logs) for unusual activity using the exposed credential
Look for: New source IPs or geographic regions, unusual API calls, resource creation or modification, privilege escalation attempts, data access or exfiltration
Check for lateral movement—did the attacker use the compromised credential to access other systems?
5. Remove the secret from the exposure location
For repositories: Rewrite git history to remove the secret from all commits (use git filter-repo or BFG Repo-Cleaner), force-push the cleaned history, notify all team members to re-clone
For logs: Purge or redact logs containing the secret, update log retention policies to prevent future exposures
For container images: Delete the image from registries, rebuild without the secret, scan the new image before deployment
For tickets/documentation: Edit or delete the content, notify anyone who may have copied the secret
6. Fix the root cause
Implement pre-commit hooks to prevent future commits with secrets
Add CI/CD pipeline scanning to block builds containing secrets
Enable branch protection rules requiring secret scanning checks
Update developer training and documentation
Consider policy-as-code (OPA, Kyverno) to enforce secret management standards
7. Document and notify
Create an incident report documenting the exposure, response actions, and timeline
Notify affected stakeholders (security team, compliance, affected service owners)
If the exposure involved customer data or regulated information, follow breach notification requirements
Update your incident response playbook based on lessons learned
8. Implement monitoring for future exposures
Enable continuous secret scanning across repositories, images, and logs
Set up alerts for new secret exposures with automatic ticket creation
Monitor for use of revoked credentials (indicates attacker persistence)
The faster you move through these steps, the smaller the window for attackers to abuse exposed credentials. Automate as much of this workflow as possible—especially detection, revocation, and notification.
Evaluating secrets management tools and platforms
Choosing the right secrets management solution requires careful consideration of how it will integrate with your existing systems and support your development workflows.
Open source vs commercial solutions
Open source tools like HashiCorp Vault offer flexibility and strong community support but require significant expertise to deploy and maintain at scale. Operational challenges include configuring high-availability clusters across multiple regions, implementing automated unsealing mechanisms, integrating rotation for each secret type (databases, cloud credentials, certificates), managing upgrade cycles, and building custom monitoring and alerting. Plan for dedicated platform engineering resources or consider managed offerings. Commercial solutions often provide streamlined experiences with enterprise support and broader integration capabilities, though they come with licensing costs.
Cloud provider tools
AWS Secrets Manager, Azure Key Vault, and Secret Manager (Google Cloud) integrate seamlessly with their respective cloud ecosystems. These native services offer automatic rotation for supported secret types, IAM-based access control, and audit logging through each cloud's native monitoring (CloudTrail, Azure Monitor, Cloud Audit Logs). They're good starting points but can create vendor lock-in and may lack consistency across multi-cloud environments.
Google Cloud Visibility Best Practices
Strengthen your GCP security posture with our cheat sheet, which offers actionable steps to manage permissions and address critical visibility gaps
Integration requirements
Your secrets management tool should integrate smoothly with existing CI/CD pipelines, container orchestration platforms, and monitoring systems. For Kubernetes, look for support for the Secrets Store CSI Driver or External Secrets Operator, which enable vault-backed secret injection without storing secrets in etcd. Strong API support enables automation of secret injection and rotation within your development workflows.
Key integration capabilities to evaluate:
CI/CD pipeline support: Native plugins for Jenkins, GitLab, GitHub Actions
Container orchestration: Kubernetes operators and Helm charts
Monitoring integration: SIEM and logging platform connectors with automatic secret value redaction, structured audit log export (JSON/CEF formats), and alerting on anomalous secret usage patterns (unusual source IPs, geographic anomalies, bulk retrievals, off-hours access)
Developer tools: IDE plugins and CLI utilities
Scalability considerations
As your environment grows, your secrets management solution must handle increased load without performance degradation. Evaluate high availability architecture, disaster recovery capabilities, and the ability to manage thousands of secrets across distributed systems.
Developer experience
If a tool is difficult to use, developers will find workarounds that compromise security. Look for solutions with clear documentation, intuitive APIs, and command-line interfaces that fit naturally into existing workflows.
How Wiz strengthens secrets management across cloud environments
Wiz provides comprehensive secrets security across your entire cloud-native application lifecycle. The platform combines prevention, detection, and response capabilities to protect credentials from code to runtime.
Wiz Code prevents hardcoded secrets from reaching production through real-time scanning in developer IDEs and automated CI/CD pipeline guardrails. This shift-left approach lets developers fix issues at the source before they become production risks.
The Wiz Security Graph correlates exposed secrets with other risk factors like network exposure, vulnerabilities, and excessive permissions. This reveals toxic combinations that create actual attack paths rather than just isolated findings.
Agentless scanning discovers secrets across all cloud workloads, configurations, container images, and logs without performance impact. When secrets are found, code-to-cloud traceability identifies their exact source—the specific repository, commit, and developer—enabling fast, accountable remediation.
Wiz Defend detects malicious use of compromised secrets in real time by enriching detections with graph context. For example, it flags when a known API key is used from a new source IP or ASN, when access patterns shift to unusual geographic regions, or when API calls deviate from normal behavior. This context reduces false positives and accelerates triage by showing whether secret usage represents actual attacker activity or legitimate operational changes. By unifying secrets detection with cloud security posture management and workload protection, Wiz eliminates tool sprawl while providing complete visibility.
Request a demo to explore how Wiz can secure your cloud environment.
Fix and Find Exposed Secrets
Learn why CISOs at the fastest growing companies rely on Wiz to prevent risks from reaching production.
