CI/CD & Secret Exposure

A continuous integration job checks out code, runs tests, builds an artifact, and often deploys it. To do that last step it needs a credential: a cloud role, a package-registry token, a signing key, an SSH key, or an API token for production. That credential is a secret even when the repository is private. Anyone who can change the pipeline, read its logs, or controls the runner can reach whatever the secret can reach.

The intended home for that material is the CI system's secret store or, better, a workload identity that mints a short-lived credential for one job. The unintended homes are a committed env file, a Dockerfile argument baked into an image, a wiki page, a chat paste, and a variable defined in the job file in plain text because someone was debugging a failed deploy.

This lesson does not show how to pull secrets out of a runner or a log archive. It teaches you to ask whether the design needed a long-lived secret at all.

Standing cloud keys in CI variables, shared across every repository in the organization, with administrator rights 'so deploys do not fail.' One compromised repo then deploys, or destroys, more than its own app.

Secrets printed while debugging. The command that echoes the environment, the verbose error that includes the connection string, and the build log retained for months are all copies. Log access becomes secret access.

Pull-request pipelines that run untrusted code with production secrets available. A fork or a feature branch should not receive the production deploy credential. The professional recommendation is environment protection: production secrets only on protected branches, reviewed changes, and trusted runners.

Build artifacts that contain the secret because it was passed as a build argument or copied into the image layer. Deleting the variable later does not rewrite the image that was pushed yesterday.

Prefer workload identity federation (OIDC from the CI provider to the cloud) so the job receives a short-lived credential for one deployment and nothing sits in a variable for a year. Where a static secret is unavoidable, store it in the CI secret manager or a dedicated vault, scope it to one environment, and rotate it on a schedule and on personnel changes.

Separate read credentials for tests from deploy credentials for production. Mask secrets in logs. Limit who can read logs and who can edit pipeline definitions. Protect the environments that hold production rights.

When a review finds a live credential, the first action is rotation and revocation, coordinated with the owner, not a longer write-up of where else it might work. The report then explains the design change that keeps the next one from landing in the same place.

Git stores every commit. A password added on Monday and removed on Tuesday is still in Monday's commit, and in every clone made in between. Squashing on one branch does not rewrite every fork, every CI cache, and every laptop. A public repository is readable by anyone. A private repository is readable by everyone who was ever granted access, plus backups.

Exposure is not only a file named .env. Secrets show up in infrastructure snippets, test fixtures, notebook outputs, container manifests, and tickets that were copied into the tree. A sample that looks fake sometimes is not. Treat a high-confidence match as a credential until the owner proves it was a decoy.

Your job in an authorized review is to find exposure and drive rotation. It is not to use the secret, prove how far it reaches beyond what the owner asks, or keep a personal copy. Using a found credential is an incident of your own making unless the rules of engagement explicitly allow a tightly bounded check and the owner is on the call.

Both tools are already in the OpsField directory. They scan content you are allowed to read and report strings that look like credentials. Gitleaks is a fast pattern-based scanner teams often run in pre-commit hooks and in CI so a known key format is blocked before it merges. TruffleHog searches git history and other sources and can verify some provider credentials so the report leans toward live keys rather than every high-entropy string.

Neither tool is a license to scan the internet's repositories. Point them at the organization, the history window, and the clones named in scope. Expect false positives: test fixtures, revoked keys, and documentation samples. Expect false negatives: a secret that does not match a known pattern. A clean scan is not proof the tree is safe. It is one control.

Read the tool pages for what each project is. This lesson intentionally has no command lines and no walkthrough of pulling a secret back out of an old commit. If you need the vendor's own usage notes, use them inside a repository you own or are contracted to assess, after you have a place to send findings.

Scope: which hosts (GitHub, GitLab, a self-hosted server), which organizations, whether forks are included, how far back history goes, and who receives the raw findings. Raw findings are credentials. Store them like credentials, with a short retention clock, not in a shared slide deck.

Order of operations when something looks live: tell the owner through the agreed channel, revoke or rotate, then confirm the new credential is in the secret manager and the old one is dead. History rewriting is painful and incomplete; it is a cleanup step after rotation, not a substitute for rotation. Notify downstream clones if the repository was public or widely forked.

Prevention you should be able to recommend without a tool manual: secret managers, pre-commit and CI scanning, a documented exception path for intentional test fixtures, protected branches, least-privilege tokens, and a short page that tells developers what to do in the first hour after they commit a key. The first hour is rotation, not a force-push and a hope that nobody pulled.