Why do CI and publishing systems create such a large identity risk?

Because they combine automation, secrets access, and downstream distribution rights in one place. A single compromised workflow can harvest tokens, publish malicious packages, and impersonate trusted releases across ecosystems. That makes CI a non-human identity problem with direct impact on secrets management and least privilege.

Why This Matters for Security Teams

CI and publishing pipelines concentrate the exact capabilities attackers want most: authenticated build execution, access to secrets, and the authority to release software that downstream systems trust. That is why this is not just a supply chain hygiene issue. It is an identity issue. NHI Management Group’s Ultimate Guide to NHIs notes that 96% of organisations store secrets outside dedicated secrets managers in vulnerable locations, including CI/CD tools, which makes pipeline identity sprawl a direct exposure path.

The risk compounds because CI systems do not behave like users. They run with automation, fan out across jobs, chain tools, and often inherit broad permissions for convenience. Once a workflow token is stolen, an attacker can move from build access to package publication, signing, artifact modification, or cloud access in a single blast radius. The NIST Cybersecurity Framework 2.0 reinforces the need to govern identities and protect distribution pathways, but CI often slips through traditional IAM reviews because it is treated as infrastructure rather than as a high-value non-human identity.

In practice, many security teams discover this problem only after a trusted release has already been abused or a build token has already been exfiltrated, rather than through intentional identity governance.

How It Works in Practice

CI and publishing systems become large identity risks because they merge three functions that should be separated: authentication, privileged execution, and outward trust. A pipeline may authenticate to source control, retrieve secrets, sign artifacts, push packages, and trigger deployments. Each step is an identity-bearing action, not just a technical task. That makes the pipeline itself a non-human identity with a lifecycle, privileges, and revocation requirements.

The practical control model is to shrink standing privilege and issue access only when a job needs it. Current guidance suggests short-lived credentials, workload identity, and policy evaluated at request time rather than long-lived static tokens. For agents and automated workloads, that means using cryptographic workload identity such as OIDC-bound tokens or SPIFFE-style identities where possible, then mapping each job to the minimum scope required for that exact operation. For broader NHI lifecycle guidance, Ultimate Guide to NHIs — Key Challenges and Risks and Top 10 NHI Issues both reinforce that excessive privilege and poor rotation are recurring failure patterns.

• Use JIT credentials for build, sign, and publish steps instead of reusable long-lived secrets.
• Bind each workflow to a distinct workload identity so access is traceable and revocable.
• Separate build permissions from release permissions and from cloud permissions.
• Rotate and revoke tokens automatically after each run or on pipeline failure.
• Log artifact, package, and signing actions as identity events, not just system events.

This approach aligns with identity-led governance because it treats the pipeline as a controllable actor with explicit authorization, not as a trusted internal machine. These controls tend to break down in monolithic CI environments where shared runners, reused tokens, and manual release steps make per-job isolation impractical.

Common Variations and Edge Cases

Tighter pipeline control often increases release overhead, so organisations have to balance speed against the risk of turning CI into an unreviewed trust hub. The tradeoff is real: short-lived credentials and stronger policy checks can slow brittle legacy pipelines, but the alternative is persistent access that survives far beyond the job that needed it.

One common edge case is publishing systems that are separated from CI only in name. If the same service account can build, sign, and publish, then a single compromise can still become a trusted release. Another is federated developer tooling, where third-party actions, plugins, or shared runners introduce identity dependencies outside the core platform. NHI Management Group has documented how these adjacent trust paths can become breach accelerants, including the Cisco DevHub NHI breach and the JetBrains GitHub plugin token exposure.

There is no universal standard for this yet, especially for signature key custody, package provenance, and automated release approvals. Best practice is evolving toward Zero Trust release paths, where each publish event is independently authorised, each secret is ephemeral, and every integration is assumed to be a potential identity boundary.

Related resources from NHI Mgmt Group

• Why do identity systems create such a large security risk?
• Why do NHI secrets in build systems create such a large blast radius?
• Why can a single SaaS app create such a large blast radius?
• Why do password vault breaches create such a large identity risk?