Secrets Management: Vault, Cloud-Native + Rotation

A "secret" is any credential that grants access: database passwords, API keys, OAuth client secrets, private keys, service-account tokens. They are the keys to the kingdom, and the default way developers handle them — pasting them into a config file, an environment variable committed to git, a Slack message, a Terraform variable — is how they leak. Hardcoded secrets are one of the most common and most damaging findings in any security review, because a single leaked key in a public repo can hand an attacker production access in minutes. Bots scan GitHub for exposed keys continuously; the window between commit and compromise is often measured in minutes.

Secrets management is the discipline (and the tooling) that gets secrets out of code and config and into a dedicated, access-controlled, audited store — and, ideally, makes them short-lived so a leaked secret is worthless by the time anyone finds it. This lesson covers the secret stores you'll encounter (HashiCorp Vault and the cloud-native services), the lifecycle controls that matter, and why "dynamic secrets" are the strongest version of the control.

The moment after you commit the API key to a public repo

What a secrets manager actually does

A secrets manager is a dedicated service that stores secrets encrypted, controls who and what can retrieve them, logs every access, and helps rotate them. The core capabilities:

Centralized encrypted storage — secrets live in one hardened store (encrypted at rest with a KMS key), not scattered across config files, CI variables, and developer laptops.
Fine-grained access control — which application, service, or human can read which secret is an explicit, auditable policy. A web app gets the database password; it does not get the payment-provider key.
Audit logging — every secret retrieval is logged: who/what fetched which secret, when. This is the evidence that access is controlled, and the trail you follow during an incident.
Rotation — secrets are changed on a schedule (or on demand after a suspected exposure) without a human editing config, so a compromised-but-rotated secret stops working.
Dynamic secrets (the strongest form) — instead of storing a long-lived password, the manager generates a short-lived credential on demand and revokes it after a brief TTL. The "secret" exists for minutes, so a leak has almost no value.

The mental shift is from secrets as static strings you protect to secrets as short-lived, brokered access you grant and revoke. The more you move toward the latter, the less a leak can hurt you.

Application retrieving a secret: authenticated, authorized, logged — and ideally short-lived

The tools you'll encounter

As with KMS, the same control comes under several names. You should recognize all of them because real environments mix them.

Tool	Sweet spot	Notable strengths
HashiCorp Vault	Multi-cloud / on-prem, advanced needs	Cloud-agnostic; rich dynamic secrets (generates short-lived DB creds, cloud creds); secret leasing/revocation; encryption-as-a-service. More to operate.
AWS Secrets Manager	AWS-native apps	Native IAM integration; built-in automatic rotation (esp. RDS); tight CloudTrail logging.
AWS Systems Manager Parameter Store	AWS, simpler/cheaper	Good for config + secrets at lower cost; less rotation tooling than Secrets Manager.
GCP Secret Manager	GCP-native apps	IAM-integrated, versioned secrets, audit logging via Cloud Audit Logs.
Azure Key Vault	Azure-native apps	Stores secrets, keys, and certificates together; RBAC + managed-identity integration.

A common pattern: cloud-native secret stores for cloud-native apps (least friction, native identity integration), with Vault where you need cloud-agnostic management or dynamic secrets across systems. The GRC point is not which tool — it's that secrets live in a managed store with access control, logging, and rotation, rather than in code.

The identity problem: how does the app authenticate to the vault?

A subtle but important point: if your app needs a secret to read its other secrets, you've just moved the problem. The solution is workload identity — the application authenticates to the secrets manager using an identity the platform vouches for, not a stored credential: an AWS IAM role on the instance/container, a GCP service account, an Azure managed identity, or Vault's auth methods (Kubernetes, cloud IAM). This is the bootstrap that lets you remove the last hardcoded secret. When you review a secrets setup, check how the app authenticates to the store — a master token sitting in an env var is the gap hiding behind an otherwise clean design.

Rotation and the secret lifecycle

Like keys and certificates, secrets have a lifecycle, and the controls live in it:

Creation / storage — the secret is generated and stored in the manager, never written to code or config.
Access — applications and authorized humans retrieve it at runtime via authenticated, logged requests.
Rotation — the secret is changed regularly (automatically where the manager supports it) so a long-lived secret doesn't accumulate exposure, and immediately if compromise is suspected. Automatic rotation (e.g., Secrets Manager rotating an RDS password) is the clean control; "we'll rotate it manually someday" is the gap.
Revocation / expiry — dynamic secrets expire on their own (short TTL); static secrets must be explicitly revoked when no longer needed or when a person leaves.

The shorter the secret's life, the less rotation even matters — which is why dynamic secrets are the endgame: there's nothing long-lived to rotate.

Quick check

A security scan finds an AWS access key hardcoded in a public GitHub repository, committed three weeks ago. What is the correct response, in order?

Remove the key from the latest commit and push — that deletes it from the repo

Immediately revoke/rotate the exposed key (assume it is already compromised), investigate via CloudTrail what the key did during the exposure window, then remove it from the code and move the secret into a secrets manager retrieved via the app’s IAM role — and add secret-scanning to prevent recurrence

Make the repository private; that prevents anyone from using the key

Add the key to a .gitignore file so it is not committed again

Mapping to frameworks

Secrets management is implied across the access-control and cryptographic controls of every framework:

SOC 2 — CC6.1 (logical access — credentials are access), CC6.7 (protecting data); the secrets-store access logs and rotation config are evidence.
ISO 27001:2022 — Annex A 5.17 (authentication information) and 8.24 (cryptography / key & secret handling); A.8.3/8.4 for access to systems and source code (where secrets so often leak).
PCI DSS / NIST — explicit requirements around not hardcoding credentials, restricting access, and rotating keys/passwords.

The evidence package: the secrets inventory (what's stored where), the access policies (who/what can read each secret), the rotation configuration, the access logs, and — increasingly expected — proof that secret scanning runs in CI to catch hardcoded secrets before they merge.

GRC Engineer's lens

When you review secrets management, the headline question is blunt: are there any secrets in code or config? Pair a secret-scanning tool (git history included) with a review of how applications get their credentials. Then assess the store itself: access scoped per secret, every retrieval logged, rotation enabled (or dynamic secrets in use), and — the often-missed piece — how the workload authenticates to the store (a platform identity, not another hardcoded master token). The mature answer you're verifying is "no secret lives in code; apps fetch short-lived credentials from a managed store using their platform identity, every access is logged, and CI blocks any hardcoded secret from merging." That's the difference between hoping no key leaks and ensuring a leaked one is worthless.

What to carry forward

Secrets management moves credentials out of code and into a dedicated store with access control, audit logging, and rotation — and, at its strongest, replaces long-lived secrets with dynamic, short-lived ones so a leak has no value. The tools (Vault, AWS/GCP/Azure native) differ; the controls don't. The subtle linchpin is workload identity, which lets the app authenticate to the store without a hardcoded secret of its own.

In the next lesson we turn from keeping credentials in to keeping sensitive data from getting out — Data Loss Prevention: finding, classifying, and stopping regulated data before it leaves the building.