Secrets Management: The Right Way to Handle Credentials in CI/CD

Long-lived static credentials sitting in CI environment variables are still, by far, the most common secrets-management mistake we find during security reviews — and they're also the easiest to fix. Here's how we think about picking the right approach for a given pipeline.

The baseline: stop storing long-lived credentials at all

The single highest-leverage change most teams can make is eliminating long-lived static credentials from CI entirely in favor of short-lived, dynamically issued tokens scoped to exactly what a given job needs. Everything below is a variation on that theme.

GitHub Actions OIDC: the right default for cloud deploys

If your CI runs in GitHub Actions and deploys to AWS, Azure, or GCP, OIDC federation should be your default. Instead of storing a static cloud credential as a repo secret, your workflow exchanges a short-lived OIDC token for temporary cloud credentials scoped to a specific role, with no long-lived secret to leak, rotate, or accidentally log.

AWS SSM Parameter Store / Secrets Manager: for application runtime secrets

For secrets your running application needs — database passwords, third-party API keys — SSM Parameter Store (with SecureString) or Secrets Manager are the right call when you're already AWS-native. Secrets Manager adds automatic rotation for supported services (RDS, in particular) which SSM doesn't natively provide.

HashiCorp Vault: for multi-cloud or dynamic-secret requirements

Vault earns its operational complexity when you need dynamic secrets — database credentials generated per-request with automatic expiry, not static passwords rotated on a schedule — or when you're managing secrets across multiple clouds and don't want per-provider tooling. For a single-cloud shop, Vault's operational overhead often isn't worth it over native tooling.

The mistake we see even security-conscious teams make

Teams that get the initial setup right — OIDC, Secrets Manager, Vault, whatever fits — often forget to close the loop on old credentials. A migration to short-lived tokens that leaves the previous static credential active 'just in case' isn't a completed migration; it's an active vulnerability with a false sense of security layered on top.

A practical checklist

• No static cloud credentials in CI — use OIDC federation wherever the CI platform supports it
• Runtime application secrets live in a managed secret store, never in environment files committed to a repo
• Every secret has an owner and a rotation policy, even if rotation is manual
• Old credentials are actually revoked, not just replaced, once a migration ships
• CI logs are audited for accidental secret exposure — most leaks happen via debug output, not the secret store itself

We build this into every CI/CD pipeline we set up as part of our DevOps & CI/CD engagements — it's cheaper to design in from the first pipeline than to retrofit once a hundred jobs already depend on the old pattern.