Why do secrets and certificates create identity risk in delivery pipelines?

Why This Matters for Security Teams

Delivery pipelines increasingly authenticate build steps, sign artifacts, call cloud APIs, and trigger deployments with secrets and certificates. That means a pipeline is not only moving code, it is exercising machine identities with real privileges. If those credentials are reused, over-scoped, or exposed in logs and artifacts, the result is often lateral movement from a development system into production, not just a failed release. The NIST Cybersecurity Framework 2.0 is useful here because it forces teams to treat identity, access, and resilience as operational controls rather than abstract policy.

The mistake many teams make is assuming the pipeline is trusted because the source code is trusted. In practice, the threat sits in the authentication layer around the pipeline: service accounts, signing keys, API tokens, and TLS certificates all create paths into artifacts, registries, deployment targets, and control planes. Once a secret is copied into a CI job, it can be reused far beyond its intended scope unless the environment is built to constrain it.

In practice, many security teams encounter credential exposure only after an artifact repository, deployment agent, or build log has already been abused rather than through intentional secret lifecycle control.

How It Works in Practice

Secrets and certificates create identity risk because they give software the ability to prove who it is and what it is allowed to do. In delivery pipelines, that proof is often delegated to scripts, runners, orchestration tools, and ephemeral containers. If those identities are not tightly bound to a specific workload, environment, and time window, the pipeline becomes a reusable trust broker. The OWASP Non-Human Identity Top 10 is a practical lens for this problem because it highlights how machine credentials are discovered, over-permissioned, and abused.

Operationally, the risk usually shows up in a few patterns:

• Hardcoded secrets in source code, templates, or build definitions.
• Long-lived certificates or tokens that outlast the job or environment that issued them.
• Shared credentials reused across branches, environments, or microservices.
• Build logs, test output, or artifact metadata that unintentionally expose sensitive values.
• Automated deployment identities that have broader access than the workload they support.

Good practice is to issue short-lived credentials where possible, scope them to the narrowest possible system, and rotate them automatically. Certificate management should be tied to workload identity, not manual renewal calendars. Pipelines should fetch secrets at runtime from a controlled secrets manager, use ephemeral credentials for deployment, and avoid embedding sensitive values in images, manifests, or pipeline variables. Current guidance also favours signing and attestation for build integrity, because provenance helps detect tampering even when a credential is compromised. Where teams use agentic automation, the same logic applies: autonomous tools should have explicit identity, constrained permissions, and auditable access paths.

These controls tend to break down when legacy CI/CD tooling cannot issue short-lived identities or when a single shared runner is trusted to deploy into many environments, because privilege boundaries collapse into one reusable credential.

Common Variations and Edge Cases

Tighter secret controls often increase release friction, requiring organisations to balance developer speed against rotation, approval, and availability constraints. That tradeoff is real, especially in environments with legacy platforms, air-gapped systems, or external partner integrations where automated issuance is not yet possible.

There is no universal standard for every pipeline design, so teams should distinguish between runtime secrets, signing material, and service-to-service credentials. A certificate used for mutual TLS between internal services may need a different lifecycle from a deployment token used by CI, and both differ from a signing key used to attest build output. Best practice is evolving toward workload identity federation and ephemeral trust, but mature adoption varies by platform.

Edge cases also matter. Break-glass credentials are sometimes necessary for incident response, but they should be isolated, heavily logged, and excluded from normal pipeline paths. Third-party build integrations can introduce hidden trust chains, so vendor tokens should be reviewed with the same scrutiny as internal service accounts. If regulated data or production payment flows are involved, the access model should be mapped to audit requirements and monitored for anomalous use. The security question is not whether credentials exist, but whether each one has a provable owner, a narrow purpose, and a lifecycle that matches the pipeline stage it supports.

Best practice is strongest when secrets are treated as non-human identities with explicit governance, because delivery risk usually emerges when credentials outlive the workload, the approval, or the environment they were meant to protect.

Related resources from NHI Mgmt Group

• Why do CI/CD pipelines create non-human identity risk?
• When does workload identity federation create less risk than static CI/CD secrets?
• Why do parallel build jobs create governance risk in identity tooling pipelines?
• Why do automated content pipelines create identity risk for IAM teams?