Managing Secrets in CI/CD

Every non-trivial pipeline needs credentials: a cloud deployment key, a package registry token, a database password for integration tests, a signing key for release artifacts. Secrets management is the discipline of storing, distributing, and rotating those credentials so pipelines can use them without ever exposing plaintext values in source code, logs, or artifacts. The core principle is that secrets should live in a purpose-built secret store — the CI platform's built-in secrets feature, a dedicated vault, or a cloud provider's secrets manager — and be injected into a job only as an in-memory environment variable or short-lived file at the moment it's needed.

Most CI platforms (GitHub Actions, GitLab CI, CircleCI, Jenkins Credentials) provide an encrypted secrets store scoped to a repository, project, or organization, with values masked in log output automatically. For more advanced needs, teams integrate an external secrets manager — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager — and have the pipeline authenticate to it using a short-lived identity (like OIDC federation) rather than a long-lived static credential, then fetch only the specific secrets a given job requires.

Secrets should be injected as environment variables or mounted files scoped to the specific step or job that needs them, not exported globally across the whole pipeline. CI platforms automatically redact known secret values from log output, replacing them with a placeholder like '***', but this masking only works for the exact string registered as a secret — if a script concatenates or transforms a secret (e.g., base64-encodes it) before printing it, the masking can be bypassed, so scripts must be written defensively to avoid ever echoing secret material.

Secrets should be scoped as narrowly as possible: a token used only by the deploy job shouldn't also be exposed to a test job that runs untrusted code from a pull request, since a malicious PR could exfiltrate any secret available in its execution context. Rotation policies — regularly regenerating credentials and revoking old ones — limit the damage window if a secret does leak, and using short-lived, dynamically issued credentials (via OIDC or a vault's dynamic secrets engine) removes the need for rotation almost entirely because the credential simply expires.