CI/CD secrets should be short-lived where possible, scoped to one job or environment, and injected only at runtime. This guide compares repository secrets, HashiCorp Vault, and the major cloud secret managers, then provides a practical tracking routine for access, rotation, auditability, and response when a credential is exposed.
Overview
The right home for a pipeline secret depends on more than where the application runs. Consider who needs access, how workloads authenticate, how often credentials rotate, which audit records are required, and how much infrastructure the team can operate. A repository secret may be adequate for a small, low-risk deployment, while a central secret manager is usually easier to govern across many repositories and environments.
Do not place passwords, private keys, long-lived tokens, or cloud credentials in source code, Dockerfiles, committed configuration, pull-request comments, or build artifacts. A protected CI/CD variable is safer than a committed value, but it still needs an owner, access restrictions, masking, rotation, and an incident procedure.
The comparison below is a planning guide rather than a permanent product ranking. Provider features, authentication methods, pricing models, and CI integrations change, so verify current documentation before standardizing an implementation.
| Option | Rotation | Access control and federation | Audit logging | Developer experience | Operational overhead |
|---|---|---|---|---|---|
| GitHub or GitLab repository and environment secrets | Manual or pipeline-assisted; depends on the credential and workflow | Repository, organization, project, branch, environment, and deployment controls vary by platform | Platform activity records may help, but depth and retention depend on the plan and configuration | Fast to adopt; native workflow syntax is convenient | Low initially; governance becomes harder across many repositories |
| HashiCorp Vault | Supports dynamic credentials and centrally managed rotation patterns | Fine-grained policies; authentication can be integrated with workload or platform identity | Designed for centralized secret access auditing; retention and forwarding require configuration | Flexible, but teams must learn its concepts and integration patterns | Higher; availability, upgrades, storage, unsealing or recovery, and policy management need ownership |
| AWS Secrets Manager | Supports managed and custom rotation patterns for supported use cases | IAM-based access; workload identity can avoid static cloud keys | Works with the surrounding AWS audit and logging model when configured | Strong fit for AWS-hosted pipelines and workloads | Moderate; cloud integration is simpler than operating a separate platform |
| Azure Key Vault | Supports versioned secrets and rotation workflows; automation depends on the credential | Azure identity and authorization controls support workload-oriented access | Diagnostic and activity logging require deliberate configuration | Convenient for Azure-based delivery and identity flows | Moderate; permissions, networking, logging, and lifecycle ownership still matter |
| Google Secret Manager | Versioning supports controlled replacement and rotation workflows | Google Cloud IAM and workload identity patterns can limit static credentials | Cloud audit records can support access review when enabled and retained appropriately | Convenient for Google Cloud deployments and service accounts | Moderate; access policy and integration design remain team responsibilities |
A useful default is to keep low-risk, repository-specific configuration in protected CI/CD variables and place shared, sensitive, or frequently rotated credentials in a central manager. For cloud deployments, prefer the provider's workload identity or federation mechanism over storing a permanent cloud access key in the repository. For multi-cloud, hybrid, or highly regulated environments, Vault may offer a consistent policy layer, but its operational cost should be explicit.
For related pipeline design, see GitHub Actions reusable workflows and the comparison of GitHub Actions, GitLab CI, and Jenkins.
What to track
1. Secret inventory and ownership
Maintain an inventory that identifies the secret, its purpose, owning team, environment, system of record, consuming workflow, privilege level, and last rotation date. Do not record secret values in the inventory. Use a stable identifier such as payments-prod-deploy-token, not a copied credential.
Classify each item by impact. A read-only package token, production database password, signing key, and cloud administrator credential should not share the same review interval or access policy. Record whether a secret is static, short-lived, dynamically issued, or federated. This distinction makes it easier to prioritize migration away from long-lived credentials.
2. Injection and exposure paths
Review how each secret enters a job and where it can travel afterward. Prefer runtime environment variables or a temporary file with restrictive permissions over command-line arguments, which may appear in process listings or logs. Avoid interpolating secrets into shell commands, URLs, cache keys, artifact names, or debug output.
Check pull-request behavior carefully. Workflows triggered by untrusted code should not receive production secrets. Separate validation jobs from deployment jobs, require an explicit protected environment for sensitive releases, and ensure forks or external contributions cannot invoke privileged steps unintentionally.
3. Access and identity
Track the identity used to retrieve a secret, not only the secret itself. A pipeline should normally authenticate as a narrowly scoped workload identity, role, or service account. Its permissions should cover the required deployment target and nothing broader. Where a static token is unavoidable, record its scopes, expiry, owning service, and replacement procedure.
Review trust boundaries between the source-control platform, CI runner, cloud account, container registry, cluster, and production service. A compromised runner can undermine otherwise strong storage controls, so runner isolation, dependency pinning, and log handling belong in the same review.
4. Rotation and evidence
Track creation date, last successful rotation, next review date, rotation method, and validation evidence. A rotation is incomplete if the new value is stored but the consuming deployment was never tested. Record whether the old credential was revoked and whether stale copies were removed from local files, caches, artifacts, and external systems.
Use the DevSecOps secrets management guide as a companion checklist when documenting storage, rotation, and CI/CD integration decisions.
Cadence and checkpoints
A recurring review prevents secret management from becoming a one-time migration project. Use a monthly or quarterly cadence according to risk, regulatory requirements, and the volume of change. The schedule below is a practical baseline; it is not a substitute for your organization's security policy.
- Every pipeline change: confirm that new steps do not print, persist, or unnecessarily request secrets. Review changes to triggers, runners, environments, permissions, and third-party actions.
- Monthly: inspect failed rotations, unused secrets, newly added credentials, access denials, unusual retrieval patterns, and secrets past their review date. Remove access for departed users and retired services.
- Quarterly: reconcile the inventory against repositories, CI variables, cloud secret stores, Vault paths, deployment manifests, and infrastructure configuration. Test one representative rotation from each integration pattern.
- After a platform or architecture change: reassess authentication and injection. New deployment targets, runner migrations, cloud-account changes, reusable workflow updates, and Kubernetes service-account changes can alter the trust model.
- At least before a security review: prove that owners, scopes, logs, rotation evidence, and leak-response contacts are current. A secret manager does not replace this evidence.
For Kubernetes workloads, check whether credentials are being mounted through the intended mechanism and whether namespace, service-account, and cluster permissions remain narrow. Pair this review with your deployment strategy documentation and resource configuration; the Kubernetes deployment strategy guide provides useful release context.
How to interpret changes
Not every inventory change signals a security improvement. A falling secret count may mean successful federation, or it may mean credentials were deleted without updating a deployment. A higher rotation count may reflect better hygiene, or it may indicate unstable automation. Interpret the change alongside deployment success, access logs, failed jobs, and ownership evidence.
Prioritize migration when a credential is shared across repositories, has broad production permissions, lacks a reliable owner, appears in multiple environments, or cannot be rotated without downtime. Prioritize workflow hardening when logs contain masked fragments, pull requests can access deployment credentials, or jobs use untrusted actions with elevated permissions.
A useful least-privilege policy template is:
Identity: ci-deploy-<service>-<environment>
Purpose: deploy <service> to <environment>
Allowed secret paths: only the named application and environment
Allowed actions: read required values; no listing or administration
Trigger: protected branch or approved deployment environment
Credential lifetime: shortest practical duration
Audit owner: <team or role>
Review: monthly access check; quarterly rotation test
Emergency contact: <on-call or security channel>For a leaked token, treat the value as compromised even if logs appear masked. Stop or pause affected deployments, revoke or disable the credential, issue a replacement through the approved store, and update every consumer. Preserve relevant logs and workflow metadata for investigation without copying the secret. Search source, history, artifacts, caches, chat, tickets, and local automation for exposure. Then identify the entry point, reduce permissions if needed, notify the responsible security and service owners, and record preventive actions. Use the CI/CD troubleshooting checklist to separate credential failure from unrelated pipeline errors.
When to revisit
Revisit this article and your internal standard monthly or quarterly, and immediately when a provider changes secret APIs, authentication guidance, workflow permissions, runner behavior, audit-log retention, or pricing. Also review it when adding a cloud account, deployment target, repository group, Kubernetes cluster, or third-party CI integration.
End each review with three concrete outputs: an updated secret inventory, a list of overdue or overprivileged credentials, and a small set of remediation owners and dates. Test one rotation and one leak-response path rather than relying only on documentation. If the team cannot explain where a credential lives, who can retrieve it, how it is injected, and how it will be revoked, the control is not yet operational.
Start with the smallest safe improvement: remove one static cloud key in favor of workload identity, move one shared production value into a central manager, or add a protected environment and log-scrubbing test to one deployment. Repeat that pattern until secure pipeline credentials are the default rather than an exception.
