Secrets in Code and CI/CD
The CI/CD pipeline holds the keys to everything — the credentials to deploy to production, to push images, to reach the cloud account — which makes it one of the highest-value targets in the whole environment, and it is where secrets most often leak. Hardcoded credentials in a repo, secrets printed in build logs, and an over-privileged pipeline are the recurring failures.
This topic connects Chapter 3's secrets management to the build system specifically: keeping secrets out of code and out of the pipeline's reach beyond what it needs.
Secrets in Source Control
The most common leak is a credential committed to git, living in history forever even after deletion, and found by attackers scanning public (and breached private) repos (Chapter 5). The fix is two-part: scanning to prevent the commit in the first place, and rotating anything that leaked — because, as Chapter 3 stressed, a secret in git history is compromised, and only rotation actually fixes it.
The Pipeline as a Target
CI/CD systems hold deploy credentials and run arbitrary code from the repo, so compromising the pipeline — or a malicious pull request that runs in it — can reach production directly. The pipeline needs least privilege and isolation like any crown-jewel system, because a pipeline with broad standing cloud access is a single compromise away from owning the whole environment.
Injecting Secrets Safely
Secrets come from a manager (Chapter 3) or the CI system's secret store at runtime, scoped per job, and are never printed to logs. The strong pattern is ephemeral, short-lived credentials — OIDC-federated cloud access instead of long-lived keys — so the pipeline exchanges a short-lived token for cloud access per run, and there is no standing key to steal from it.
Least Privilege and Isolation for Builds
A build job should have only the credentials it needs, untrusted pull requests should not run with production secrets, and the pipeline's cloud access should be narrowly scoped so a pipeline compromise is not total (Chapter 13). Meridian's setup is concrete: secret scanning in pre-commit and CI, no long-lived cloud keys (OIDC federation), per-job scoped secrets from the manager, masked logs, and isolated handling of untrusted pull requests.
- Committing secrets to git and thinking deletion fixed it — it is in history and must be rotated, and scanners and attackers find it (Chapter 5).
- Printing secrets to build logs or exposing them to untrusted pull-request builds, leaking them to anyone who can read CI output.
- Long-lived, broadly-scoped cloud credentials in the pipeline, so a pipeline compromise hands over the whole cloud account.
- Treating CI/CD as low-risk infrastructure rather than a crown-jewel target with production keys.
- Running untrusted pull requests with the same secrets and access as trusted builds.
- Scan for secrets in pre-commit and CI to stop leaks before they land, and rotate anything that ever leaked.
- Pull secrets from a manager or CI secret store at runtime, scoped per job, masked in logs — never hardcoded.
- Prefer short-lived, federated credentials (OIDC to the cloud) over long-lived keys, and scope pipeline access narrowly (Chapter 13).
- Isolate untrusted pull-request builds from production secrets, and treat the pipeline as a high-value target to harden and monitor.
- Give each build job only the credentials it actually needs, nothing more.
Knowledge Check
Why is the CI/CD pipeline one of the highest-value targets in an environment?
- It holds deploy credentials and runs repo code, so it can reach production
- It stores the company's entire primary customer database
- It is the only company system directly exposed to the public internet at all
- It cannot be monitored or logged
Why prefer OIDC-federated cloud access over long-lived keys in a pipeline?
- A per-run token means no standing key to steal
- OIDC tokens are simply longer strings, so much harder to guess
- Long-lived keys simply cannot access the cloud at all anymore
- OIDC removes the need to scope pipeline permissions
Why isolate untrusted pull-request builds from production secrets?
- A malicious pull request runs code in the pipeline, and with production secrets it could reach production directly
- Untrusted builds run slower and shouldn't share resources
- Pull requests cannot execute code in CI
- Production secrets expire when a PR is opened
You got correct