A CI pipeline's credential to a secrets manager should belong to a designated service account, authorize only the secrets that job needs, expire when the job completes, and leave logs that show who triggered each call. That is the shape OWASP describes. A shared admin token that never expires is the opposite.
The OWASP checklist, in plain words
OWASP's Secrets Management Cheat Sheet has a section on CI/CD pipelines. The relevant points for the credential itself:
- Designated service accounts. CI/CD tooling should have its own service accounts that operate only within the scope of the secrets they need.
- Narrow authorization. Pipeline credentials should only authorize the secrets and services of the secret management system that the job requires.
- Short life. The credentials the pipeline uses to reach the secrets manager should be rotated frequently and expire after a job completes.
- Attribution. Pipeline calls should be traceable to the person or service that triggered them, and you should verify this periodically.
- Logging. Assemble all logs from the CI/CD tooling and have rules to detect secret extraction or misuse. OWASP says to keep logs queryable for at least 90 days.
- Least privilege for people. Developers should be able to run pipelines but do not need to administer projects.
- Treat the tooling as production. OWASP says to treat your CI/CD tooling as a production environment, including patching it.
Bad versus good
| Property | Weak pattern | Stronger pattern |
|---|---|---|
| Identity | One shared token for all pipelines | One identity per pipeline or job family |
| Scope | Read access to all secrets | Read access to named paths only |
| Lifetime | Never expires | Expires when the job completes |
| Attribution | Anonymous service token | Calls tied to project, ref, and triggering user |
| Storage | Static token in CI variables | Job identity token exchanged at run time |
How to get the strong pattern
The cleanest route is a job identity. CI platforms such as GitHub and GitLab issue OIDC tokens per job. The secrets manager validates the token's claims, and only then issues a short lived credential. GitLab's Vault integration is one example: the job authenticates with an ID token rather than a stored Vault token. The token expiry follows the job timeout, or 5 minutes if none is set.
If your secrets manager cannot validate OIDC tokens, fall back to a narrowly scoped service account token stored as an environment secret, and rotate it on a short schedule.
Steps to improve what you have
- List every credential your pipelines use to reach a secrets manager.
- For each one, record scope, lifetime, owner, and what logs it produces.
- Split shared tokens by pipeline. One token per job family limits blast radius.
- Reduce scope to named paths. Remove wildcard read policies.
- Switch to job identity where the manager supports it, with conditions on project and ref.
- Send manager audit logs and CI logs to one place, and keep them at least 90 days if your policy allows.
- Write alert rules for odd behavior: reads from unfamiliar refs, reads outside business hours, repeated denials.
- Review quarterly that attribution still works end to end.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one control, such as access scoping, lines up with several framework requirements, then think about which evidence you could hand an auditor.
Quick check
Is 90 days of log retention a rule?
It is OWASP's suggestion for keeping CI/CD logs queryable. Follow any longer period set by your own policy or contracts.
Why not give pipelines broad read access to avoid breakage?
Because a compromised job then reads everything. Narrow paths cost a little setup and cap the damage.
Safeguard compliance and evidence automation can help collect dated records of access reviews, and policies and gates can review pipeline changes. A free scan is at gold.safeguard.sh/scan.
Sources
- OWASP Secrets Management Cheat Sheet
- GitLab Docs: Use HashiCorp Vault secrets in GitLab CI/CD
- GitLab Docs: ID token authentication
Last reviewed: 19 October 2026.
