How do you handle secrets in a build and deployment pipeline?

Keep long lived credentials out of the pipeline entirely. Use workload identity federation so the CI job exchanges a short lived OIDC token for a scoped role, and pull application secrets at runtime from a secrets manager rather than injecting them at build time. Scope each secret to one environment and one consumer, rotate automatically, audit access, and mask them in logs. Never bake secrets into images or commit them, even encrypted, without key management.

My starting position is that the pipeline should not hold any long lived cloud credentials. The CI provider issues a signed identity token for the job, the cloud trusts that issuer, and the job exchanges it for a role that lasts minutes and is scoped to one environment. That deletes the whole category of a leaked static key sitting in a repository setting for three years. Application secrets are a separate concern and they belong at runtime, pulled from a secrets manager by the workload using its own identity, so a database password never passes through the build at all. If I have to keep encrypted secrets in git, for example in a GitOps repository, they are encrypted against a key management service so the decryption right is what I am really controlling, not the file. Everything is scoped narrowly, rotated on a schedule, and access is logged. And I plan for leaks: revoke first, rotate, then work out the blast radius from the audit trail, because trying to prove nobody used it before revoking is the wrong order.