The Complete Guide
How organizations protect the API keys, passwords, tokens, certificates, and credentials that hold their infrastructure together.
Definition
Secrets management is the set of practices, tools, and policies used to securely store, access, distribute, and rotate sensitive credentials throughout the software development lifecycle.
A "secret" is any piece of data that grants access to a system or data. This includes API keys, database passwords, encryption keys, OAuth tokens, TLS certificates, SSH keys, and service account credentials. Without proper management, these secrets become the weakest link in your security posture.
Modern secrets management solutions provide a centralized, encrypted vault with fine-grained access control, audit logging, automatic rotation, and programmatic access via APIs - replacing the old pattern of hardcoding credentials in config files, environment variables, or source code.
Motivation
Exposed credentials are the #1 cause of cloud breaches. Centralized secrets management eliminates hardcoded credentials and secrets sprawl.
SOC 2, PCI DSS, HIPAA, and ISO 27001 all require controlled access to credentials with audit trails and regular rotation.
Microservices, containers, and CI/CD pipelines multiply the number of secrets. Manual management doesn't scale.
Automated rotation limits the window of exposure if a secret is compromised, reducing risk without manual intervention.
Taxonomy
Every credential that grants access to a system, dataset, or service is a secret that needs to be managed.
Authentication tokens for third-party services, cloud providers, and internal APIs. Often the most commonly leaked secret type.
Usernames, passwords, and connection strings for databases. Compromise means direct access to your data.
Private keys and certificates for encrypted communications. Expired or stolen certs can enable man-in-the-middle attacks.
Key pairs for server access and Git operations. Unmanaged SSH keys are a common vector for lateral movement.
Symmetric and asymmetric keys used for data encryption at rest and in transit. Loss means data is unrecoverable; theft means data is exposed.
OAuth tokens, JWTs, and service credentials used for machine-to-machine authentication in automated workflows.
Lifecycle
Secrets are created using cryptographically secure random generators or issued by identity providers. Strong entropy and appropriate length are enforced by policy.
Secrets are encrypted at rest in a centralized vault. Access is gated by identity-based policies, never stored in plaintext in code, config files, or environment variables.
Applications retrieve secrets at runtime via APIs or sidecars. Secrets are injected into workloads dynamically, never baked into images or artifacts.
Secrets are automatically rotated on a schedule or in response to events. Dynamic secrets with short TTLs are preferred, as they minimize the blast radius of a compromise.
Compromised secrets are revoked instantly. Every access is logged for compliance and forensic analysis. Alerts fire on anomalous access patterns.
Ecosystem
The landscape spans open-source vaults, cloud-native services, and enterprise platforms.
Open Source / Enterprise
The most widely adopted secrets manager. Supports dynamic secrets, encryption as a service, identity-based access, and over 100 integrations. Available self-hosted or as HCP Vault.
Open Source / Enterprise
Purpose-built for machine identity and DevOps secrets. Policy-as-code access control, native Kubernetes integration, and strong enterprise audit capabilities.
SaaS / Enterprise
Cloud-native SaaS vault with patented Distributed Fragments Cryptography. Zero-knowledge architecture, automatic rotation, and unified secrets management across hybrid environments.
Open Source / SaaS
Developer-friendly secrets management platform with end-to-end encryption, native integrations for CI/CD and cloud platforms, and an intuitive dashboard for teams.
SaaS
Universal secrets platform that syncs secrets across environments and services. Strong developer experience with CLI tools, integrations, and automatic secret rotation.
SaaS
Extends 1Password to infrastructure. Connect Server provides secrets to CI/CD pipelines and applications via SDKs and a REST API with fine-grained access control.
Self-Hosted
Distributed secrets management that splits credentials across multiple devices so no single device ever holds the full secret. Self-custody architecture with built-in audit logging and zero vendor access to your secrets.
Cloud Native
Native AWS service with automatic rotation for RDS, Redshift, and DocumentDB credentials. Deep IAM integration and cross-account secret sharing via resource policies.
Cloud Native
Manages secrets, keys, and certificates for Azure workloads. HSM-backed key storage, RBAC with Azure AD, and integration with Azure DevOps and App Service.
Cloud Native
GCP-native secret storage with automatic replication, IAM-based access, and versioning. Integrates with Cloud Run, GKE, and Cloud Functions for seamless secret injection.
CI/CD
Encrypted secrets for GitHub Actions workflows. Scoped to organizations, repositories, or environments. Secrets are masked in logs and never exposed in pull requests from forks.
CI/CD
Protected and masked variables for GitLab pipelines. Can be scoped to environments and protected branches. Integrates with external secret managers via native connectors.
Open Source
Encrypts values in YAML, JSON, ENV, and INI files while leaving keys in plaintext. Supports AWS KMS, GCP KMS, Azure Key Vault, and PGP for key management.
Open Source
Scans git repositories for hardcoded secrets using regex and entropy analysis. Runs as a pre-commit hook or in CI/CD pipelines to prevent secrets from being committed.
Open Source / Enterprise
Deep scanning of git history, filesystems, and S3 buckets for secrets. Verifies discovered credentials against live services to prioritize real exposures.
Platform Feature
Automatically detects tokens from 200+ service providers in public and private repos. Push protection blocks commits containing known secret patterns before they land.
Guidance
Principles for building a mature secrets management program.
No secrets in source code, config files, container images, or CI/CD scripts. Use environment injection or runtime API calls to retrieve secrets from a vault.
Grant access to specific secrets, not entire vaults. Use role-based or attribute-based access control. Every service gets only the credentials it needs.
Set rotation schedules and automate the process. Prefer short-lived dynamic secrets over long-lived static credentials whenever the downstream system supports it.
Log who accessed which secret, when, and from where. Feed logs into your SIEM for anomaly detection. This is essential for compliance and incident response.
Use AES-256 or equivalent for storage. All API calls to the secrets manager must use TLS. Consider envelope encryption where the vault manages the data encryption key.
Run secret scanning tools in CI/CD and as pre-commit hooks. Monitor public repositories and paste sites for your organization's credentials. Treat any detected leak as a security incident.
Generate unique, short-lived credentials per session or request. If a dynamic secret is compromised, it expires before an attacker can exploit it.
Consolidate secrets into a single platform. Secrets sprawled across .env files, CI tools, wikis, and spreadsheets are impossible to govern and audit.
Know how to revoke and rotate all secrets quickly. Practice incident response runbooks. Identify which secrets are most critical and prioritize their recovery procedures.
Development, staging, and production should each have their own set of secrets. Never reuse production credentials in lower environments.
Risks
Understanding how secrets get compromised helps you build better defenses.
| Threat | Description | Mitigation |
|---|---|---|
| Secrets in source code | Credentials committed to Git repositories, including in history | Pre-commit hooks, secret scanning, .gitignore |
| Secrets sprawl | Secrets duplicated across config files, CI tools, wikis, and Slack | Centralized vault, secret references instead of values |
| Overprivileged access | Services or users with access to more secrets than needed | Least-privilege policies, regular access reviews |
| Stale credentials | Long-lived secrets that haven't been rotated in months or years | Automatic rotation, short TTLs, dynamic secrets |
| Insider threats | Employees or contractors misusing credential access | Audit logging, access reviews, just-in-time access |
| Supply chain attacks | Compromised dependencies or build tools exfiltrating secrets | Isolated build environments, minimal secret exposure |
| Log exposure | Secrets accidentally printed in application logs or error messages | Log scrubbing, secret masking, structured logging |
Example
The difference between hardcoding a secret and retrieving it from a vault at runtime.
Hardcoded secret - don't do this
Retrieved from a vault at runtime