How should organisations govern identity and secrets in DevSecOps pipelines?

Why This Matters for Security Teams

DevSecOps pipelines often inherit trust too easily. Source control hooks, CI runners, artifact stores, container registries, cloud deployment roles, and secret managers can each hold credentials that are effectively production identities. When those credentials are broad, long-lived, or shared across stages, an attacker who reaches the pipeline can pivot into source code, signing keys, cloud environments, and release systems. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to treat identity, access, and continuous monitoring as core operational controls rather than afterthoughts.

The practical risk is not just theft of a secret, but misuse of the trust chain around that secret. A pipeline token may be copied from a build log, reused in a later job, or over-permissioned to support multiple repositories and environments. That creates a hidden privilege layer that is often absent from IAM reviews because it sits inside delivery tooling instead of a conventional user directory. In practice, many security teams encounter pipeline compromise only after a malicious commit, poisoned dependency, or exposed token has already been used to sign or deploy trusted code, rather than through intentional review of pipeline identity design.

How It Works in Practice

Effective governance starts by inventorying every identity that a pipeline uses, including human-triggered break-glass access, service accounts, workload identities, and ephemeral runner credentials. Each identity should have a named owner, a defined purpose, and an expiry or rotation policy. Secrets should be stored in a dedicated secret manager or injected just in time, never hardcoded in repositories, build scripts, or environment files. Where supported, use short-lived federated credentials from the cloud or identity provider instead of static API keys.

Pipeline design should also separate trust zones. Build systems need different rights from deployment systems, and test environments should not reuse production credentials. Least privilege is the default, but the control must be enforced through policy, not documentation alone. The OWASP Non-Human Identity Top 10 is especially relevant because many pipeline risks are really NHI governance failures: unmanaged service accounts, orphaned tokens, weak rotation, and unclear lifecycle ownership.

• Use ephemeral credentials for runners, agents, and deployment jobs.
• Scope secrets to one pipeline, one environment, and one function where possible.
• Block secret exposure in logs, artifacts, and debug output.
• Require attestation or approval for privileged release steps.
• Monitor token use for anomalies such as unusual source, timing, or destination.

Detection should treat pipeline identities like any other privileged access path. Log secret issuance, token exchange, repo access, image signing, deployment actions, and failed authentication attempts, then correlate them in SIEM or SOAR workflows. These controls tend to break down in highly distributed self-hosted runner estates because ownership is fragmented and token lifetimes are extended to reduce operational friction.

Common Variations and Edge Cases

Tighter secret controls often increase delivery overhead, requiring organisations to balance speed against stronger identity governance. That tradeoff is real in legacy CI systems, mono-repos, and multi-cloud deployments where teams have historically relied on shared variables or long-lived service principals. Best practice is evolving toward workload identity federation and policy-based access, but there is no universal standard for every platform yet.

Edge cases matter. Some pipelines need emergency override paths for release failure, regulated signing, or incident recovery. Those paths should be rare, separately approved, and heavily logged. Container build systems, infrastructure-as-code runners, and AI training pipelines may also embed secrets in ways that are not obvious to application teams, so discovery must extend beyond the main CI product. For organisations operating under a broader resilience model, the same identity and secrets discipline aligns well with NIST Cybersecurity Framework 2.0 principles for governance, protection, detection, and response. The main failure mode appears when teams optimise for developer convenience first and only later discover that pipeline credentials have become durable production access.

Related resources from NHI Mgmt Group

• How should organisations govern identity-related automation in the SOC?
• How should organisations govern identity signals in high-volume security data?
• How should organisations govern developer tools that install packages or use AI agents?
• Should organisations treat secrets scanning as part of IAM or AppSec governance?