Secrets management
Secrets management is where identity and data risk converge: every API key, database password, service-account token, TLS private key, and OAuth client secret is a live credential that grants access to something. In modern cloud estates these secrets multiply and scatter — into environment variables, CI/CD variables, container image layers, Terraform state files, parameter stores, and forgotten config files — far faster than anyone tracks them. A secret is only as safe as the weakest place it is stored and the broadest identity that can read it, so the discipline is not just "use a vault" but proving that secrets are encrypted, tightly scoped, rotated, and audited everywhere they live. This sub-topic looks specifically at how secrets are stored, distributed to workloads, rotated, and monitored across AWS, Azure, and Google Cloud — the plumbing underneath the roles and policies covered elsewhere in identity and access.
Overview
What this check looks like in practice
Secrets sprawl — in environment variables, parameter stores, repos, and images — is where identity and data risk meet. Unmanaged secrets are credentials waiting to leak.
Why it matters
A leaked secret is the most direct compromise there is: no exploit chain, no privilege escalation, just valid credentials used as intended. Attackers and automated bots scan public and private repositories, build logs, and cloud metadata endpoints continuously, because a single hardcoded key can hand over a database, a payment processor, or an entire cloud account in seconds. Static, long-lived secrets are especially dangerous because they rarely expire, are frequently copied, and often outlive the person who created them, so a credential exposed today can still be valid years later. Auditors treat secret handling as a core control — PCI-DSS forbids hardcoded and shared credentials and demands cryptographic key management, while SOC 2 and ISO 27001 expect evidence of rotation, restricted access, and an audit trail. The consequence of getting it wrong is not a near-miss: once a secret is exposed, it must be assumed burned and rotated everywhere, which is far more expensive than storing it correctly in the first place.
What we assess
What we look for
- Plaintext secrets in code, environment variables, CI/CD pipeline variables, container image layers, and Infrastructure-as-Code (Terraform/CloudFormation) state files
- Whether secrets live in a managed vault with encryption at rest versus ad-hoc parameter stores, config maps, or unencrypted key-value entries
- Automatic rotation status — long-lived static credentials that never expire versus rotated or dynamically issued short-lived secrets
- Least-privilege on secret read access: resource/IAM policies scoped per workload identity rather than broad wildcard GetSecretValue or vault-wide access
- Audit logging on secret retrieval, so every access to a secret is attributable and reviewable
- KMS / customer-managed key (CMEK) envelope encryption backing the secret store, with defined key rotation and purge protection
- Secret scanning and pre-commit / pipeline controls to catch leaked credentials, plus exposed secrets sitting in Git history
- Use of workload identity and dynamic, on-demand credentials (database, OIDC) in place of distributing static keys to applications
Across your clouds
AWS, Azure & Google Cloud
AWS
AWS Secrets Manager (with Lambda-driven automatic rotation) and SSM Parameter Store SecureString parameters backed by KMS envelope encryption; access governed by IAM identity and secret resource policies, with GetSecretValue calls captured as CloudTrail management events for the audit trail.
Azure
Azure Key Vault for secrets, keys, and certificates, accessed by workloads via managed identities rather than embedded credentials; we check RBAC versus legacy vault access policies, network restrictions (firewall / private endpoint), soft-delete and purge protection, and diagnostic logging of secret access to Log Analytics.
Google Cloud
Google Secret Manager with versioned secrets, optional CMEK encryption, and rotation schedules; access is controlled by the secretmanager.secretAccessor IAM role (ideally per-secret), tightened with VPC Service Controls, and every access is recorded in Cloud Audit Logs Data Access logs.
Example finding
Database credentials hardcoded in a repo and injected as plaintext pipeline variables, with no rotation
Risk: The production database password is committed in application config and duplicated as a plaintext CI/CD variable readable by every pipeline job and anyone with repo access; it has never been rotated, so a single leaked build log or repo clone yields standing, unauditable access to customer data with no record of who used it.
Fix: Move the credential into a managed vault (Secrets Manager / Key Vault / Secret Manager), have the application fetch it at runtime through its workload identity, rotate the now-exposed password immediately, purge it from Git history, and enable automatic rotation plus access logging so future retrievals are scoped and attributable.
Remediation
How to close it
- 1 Inventory secrets across the estate — scan repositories (including full Git history), container images, IaC state, parameter stores, and CI/CD variable stores to find where credentials actually live.
- 2 Migrate discovered secrets into a managed vault (AWS Secrets Manager / SSM SecureString, Azure Key Vault, GCP Secret Manager) with KMS/CMEK encryption at rest and purge/soft-delete protection enabled.
- 3 Rotate or revoke every secret that was exposed or long-lived, and purge leaked values from Git history and build logs — treat any previously plaintext secret as compromised.
- 4 Scope read access least-privilege: grant each workload identity access only to the specific secrets it needs, eliminating wildcard and vault-wide grants.
- 5 Enable automatic rotation and, where supported, dynamic short-lived credentials (database secrets, OIDC-issued tokens) so applications stop holding static keys.
- 6 Turn on audit logging for secret access and add secret-scanning / pre-commit and pipeline gates so new plaintext credentials are caught before they merge.
Compliance evidence
Questions
Do you extract or read our actual secret values during the assessment?
No. The review is read-only and focused on configuration and exposure — where secrets are stored, how they are encrypted, who can read them, whether they rotate, and whether plaintext secrets are present in code or pipelines. We flag that a secret is exposed and where; we do not exfiltrate or store its value.
We already use a parameter store — isn't that the same as a secrets vault?
Not necessarily. A parameter store only protects a secret if entries are stored as encrypted (for example SSM SecureString backed by KMS) with access scoped per secret. Plaintext parameters, over-broad read policies, and no rotation or access logging leave you with vault-shaped storage but none of the guarantees, which is exactly the gap we look for.
Do you check for secrets that were committed to Git in the past?
Yes. A secret removed from the current codebase usually still lives in Git history and must be treated as leaked until rotated. Reviewing history and build logs is part of understanding real exposure, because attackers scan those same places.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
