How should secrets be handled in a delivery pipeline, and what is the strongest available approach?

The strongest approach

Workload identity rather than stored secrets. The pipeline proves the job's identity to the target system and receives a short-lived credential, so there is no long-lived secret to steal, rotate or leak.

This eliminates the highest-value target entirely rather than protecting it, which is why it is qualitatively better than any secret-management improvement.

Where that is not available

Short-lived, narrowly-scoped credentials issued per job — scoped to exactly what that job needs (one artefact path, one environment) and expiring in minutes. Not a static secret in the environment.

The structural controls

1. Trust separation by pipeline. Builds triggered by external contributions run with no deployment credentials; only trusted-branch builds after review receive them. This is the primary control and it is structural rather than technical.

2. The pipeline definition from the trusted branch. If a contributor can modify the workflow and have it run with credentials, every other control is bypassed. This is the most commonly missed control and the most commonly exploited.

3. Approval gates between build and deploy, separating the stage that runs contributor code from the stage that holds deployment credentials.

4. Egress control on runners. A compromised build with a credential still needs to send it somewhere; restricting outbound access to known destinations breaks the exfiltration step.

5. Stronger isolation than containers for untrusted execution, since containers share a host kernel.

The subtle leak paths

• Secrets in build logs. Masking helps and is defeated by encoding or splitting the value. Assume logs from untrusted builds are public.
• Secrets in cached artefacts or layers, persisting into later builds.
• Environment variables visible to child processes, including everything the build invokes.
• Shared runners retaining state between jobs of different trust levels.

The verification question

"If a contributor submits a change whose build prints every environment variable and uploads the working directory to an external host, what do they get?" The answer must be "nothing that matters" — and if it is not, the trust separation is incomplete.