A build pipeline needs credentials to deploy. What is the safe design, and what is the most common leak?

The safe design

• Workload identity rather than stored secrets. The pipeline proves what it is cryptographically and receives short-lived credentials scoped to the specific deployment. This eliminates the long-lived secret entirely, which is strictly better than managing one well.
• Scoped to the specific action. A pipeline that deploys one service should not hold credentials that reach anything else — and the scoping is what bounds the damage when a build is compromised.
• Short lifetimes with automatic renewal, so the exposure window of any leak is minutes.
• No ambient credentials in the build environment. A build runs untrusted code — dependencies, build scripts, test fixtures — and a build that can reach production secrets turns any dependency into a path to them.
• Separate credentials per environment, so a compromise of a development pipeline does not reach production.
• Audit logging of every credential issue and use.

The most common leak

Secrets in build logs. A command echoing its environment, a debug flag, a failing script printing its configuration, an error-reporting integration capturing the environment. Build logs are widely readable, retained, and frequently exported to a log platform — so a secret that appears in one has been distributed.

Close behind: secrets in the repository, including in test fixtures and configuration examples, which are then in the history forever and in every clone.

The detection layer

Scanning for secrets in code, in build artefacts, in logs and in public repositories, with automated revocation on detection rather than a ticket. The window between a secret appearing publicly and being exploited is short enough that human triage is too slow.

That requires the credential format to be recognisable, which is a small design decision with a large operational payoff.

The property to verify

Rotate a production deployment credential on an ordinary afternoon and see what breaks. An organisation that cannot do this does not have a rotation capability whatever its policy says — and a rotation first exercised during a suspected breach will fail at the worst possible moment.