What is the difference between code integrity risk and identity exposure risk in CI/CD?

Code integrity risk is about whether the build or dependency was altered. Identity exposure risk is about whether the workflow’s credentials, tokens, or keys were harvested and reused. In practice, identity exposure is usually the higher-impact problem because attackers can operate as a legitimate automation identity long after the modified code is removed.

Why This Matters for Security Teams

Code integrity risk and identity exposure risk are often conflated because both can show up as “something changed in the pipeline.” The operational difference matters: modified code may be detected and rolled back, but stolen workflow credentials can be reused from outside the pipeline, inside approved tools, or through cloud APIs. That makes identity exposure the more durable threat, especially where service accounts, deploy keys, and token scopes are broad. NHIs are frequently over-privileged, and the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which widens the blast radius when a CI/CD identity is harvested.

Security teams also need to separate prevention from cleanup. Code integrity controls focus on signed commits, protected branches, dependency pinning, and build provenance. Identity exposure controls focus on token scope, secret storage, rotation, revocation, and runner trust. Both matter, but they fail in different ways. This distinction is especially important in pipelines that touch production credentials or deployment automation, where one stolen token can outlive the code that exposed it. Current guidance suggests treating workflow identity as a first-class asset, not an implementation detail, and pairing that with NIST Cybersecurity Framework 2.0 governance for access and recovery. In practice, many security teams discover identity exposure only after a legitimate automation account has already been used to move laterally, rather than through intentional monitoring of the pipeline itself.

How It Works in Practice

In CI/CD, code integrity risk is the question “Did the artifact, dependency, or build step get altered?” Identity exposure risk is the question “Did an attacker obtain the credential that lets the pipeline act?” Those are different control planes. A pipeline can produce clean builds while still leaking a token through logs, environment variables, artifact metadata, chat exports, or a compromised runner. The reverse is also true: a dependency can be poisoned without any secret theft. For that reason, teams should evaluate both the integrity of what is built and the identity authority that built it.

Practical controls usually split into four layers:

• Use signed commits, pinned dependencies, and build attestation to reduce code tampering.
• Store secrets in a dedicated secret manager and avoid long-lived credentials in repository files.
• Issue JIT credentials with narrow scopes so a compromised token expires quickly after the task ends.
• Bind runner or workload identity to cryptographic trust, not just a static API key.

This is where the NHI lens matters. The 52 NHI Breaches Analysis shows how often machine identities become the real entry point, and the CI/CD pipeline exploitation case study illustrates why runner compromise and token reuse can be more damaging than a single tampered commit. Vendor research points the same way: GitGuardian’s The State of Secrets Sprawl 2026 reports that 59% of compromised machines in a major supply chain attack were CI/CD runners rather than personal workstations, which is a strong reminder that pipeline identity is an attack surface of its own. These controls tend to break down when self-hosted runners share credentials across jobs because one compromised job can inherit trust meant for an entire environment.

Common Variations and Edge Cases

Tighter secret handling often increases pipeline friction, requiring organisations to balance developer speed against shorter credential lifetimes and more frequent re-authentication. That tradeoff becomes most visible in monorepos, multi-cloud delivery, and release automation that spans several teams. In those environments, the issue is rarely one token type in isolation. It is usually a mix of static deploy keys, inherited environment variables, unmanaged service accounts, and brittle exception handling around release jobs.

There is no universal standard for every pipeline pattern yet, but current guidance suggests that long-lived credentials should be the exception rather than the default. Ephemeral access works best when the workload identity is clearly established and the authorisation decision is evaluated at request time. That is especially relevant where an AI-assisted build step, bot account, or autonomous deployment agent can chain actions in ways a human operator would not predict. For those cases, identity exposure risk is not just about theft, but about what the stolen identity can still do after the original code path is gone. The Guide to the Secret Sprawl Challenge is useful background for understanding why secrets spread across code, config, and tooling, while the Anthropic report on the first AI-orchestrated cyber espionage campaign reinforces how quickly autonomous systems can turn access into action. In practice, the hardest cases are pipelines that mix static service accounts with ad hoc human approvals, because neither code integrity checks nor secret scans alone are enough to stop misuse.

Related resources from NHI Mgmt Group

• What is the difference between prompt injection risk and identity abuse in agents?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between SAST and DAST for security teams?
• What is the difference between scanning AI-generated code and governing AI agent identity?