What is secrets handling in pipelines?
Pipelines need credentials — registry logins, cloud keys, deploy tokens — but those must never be hardcoded or printed. Secrets handling is how you supply them to a job at runtime, scoped and masked, so they do the work without leaking into logs or artifacts.
Why it matters
CI runs with broad access and produces public logs, making it a prime target for credential leaks. A secret echoed into a log or baked into an image is compromised the moment someone reads it. Handling pipeline secrets correctly is a security responsibility that sits squarely on DevOps.
What to learn
- CI secret stores and how jobs read them
- Masking secrets in logs
- Scoping secrets to environments and branches
- Short-lived credentials and OIDC federation
- Avoiding secrets in build args and image layers
- Rotating leaked secrets immediately
- Restricting secrets on pull requests from forks
Common pitfall
Passing a secret as a Docker build argument, which then persists in the image history for anyone who pulls it to read. Build args are not secret. Use build-time secret mounts or inject credentials only at run time, and never let a secret become a layer in a shareable image.
Resources
Primary (free):
- GitHub — Using secrets in Actions · docs
- GitHub — OIDC hardening · docs
- OWASP — Secrets management cheat sheet · docs
Practice
Take a pipeline that deploys somewhere and supply its credential through the CI secret store instead of any hardcoded value. Confirm the secret is masked in the logs. If possible, swap a long-lived key for short-lived OIDC credentials. Done when no secret appears in any log or image layer.
Outcomes
- Inject credentials from a CI secret store, not hardcoded.
- Keep secrets masked in logs and out of image layers.
- Scope secrets to environments and protected branches.
- Prefer short-lived OIDC credentials over long-lived keys.