CI trust boundary

Expanded Definition

The CI trust boundary is the operational perimeter where a continuous integration or delivery system is trusted to act on behalf of the organisation. That trust covers build steps, signing operations, deployment actions, secret retrieval, and any internal API calls the pipeline can make.

In NHI security, this boundary matters because the pipeline is not just a toolchain, it is an identity-bearing actor with standing authority. Definitions vary across vendors, but the practical question is consistent: which credentials, repositories, environments, and approval paths are legitimate for the pipeline to touch? NIST Cybersecurity Framework 2.0 frames this as an access and governance problem, while identity programs must decide whether the CI system is inside the same control plane as service accounts and other NHIs. The boundary should be narrow, explicit, and continuously reviewed, especially when pipelines fan out into production or artifact signing.

The most common misapplication is treating the entire CI runner estate as equally trusted, which occurs when shared runners, broad token scopes, and unrestricted deployment permissions are used by default.

Examples and Use Cases

Implementing the CI trust boundary rigorously often introduces deployment friction, requiring organisations to weigh delivery speed against tighter approval, secret, and environment controls.

• A build job can pull source, compile code, and publish artifacts, but it cannot read production secrets or deploy without a distinct approval step.
• A release pipeline signs artifacts using a dedicated NHI whose key material is stored in a managed vault, not embedded in runner configuration. The broader NHI control issues described in Ultimate Guide to NHIs show why this separation matters.
• A CI system calls internal APIs only from a restricted network segment and only with short-lived credentials scoped to one repository or environment.
• A platform team uses NIST Cybersecurity Framework 2.0 to map pipeline access, then limits who can alter build definitions, secrets, and deployment targets.
• A shared runner is treated as untrusted execution space, so every job receives fresh credentials and no long-lived token survives between runs.

In practice, the boundary is drawn wherever the pipeline’s authority becomes security-relevant, not wherever the tool happens to execute code.

Why It Matters in NHI Security

CI systems often become the easiest path from a routine code change to a broad environment compromise because they hold signing rights, deploy rights, and access to sensitive secrets. When the trust boundary is vague, an attacker who hijacks a pipeline can pivot into artifact integrity, internal services, and production infrastructure without ever stealing a human password. That is why CI must be treated as an NHI governance domain, not just an engineering convenience.

NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 97% of NHIs carry excessive privileges. Those conditions turn a CI boundary failure into a full identity incident, especially when build credentials are reusable across systems. The NHI control lessons in Ultimate Guide to NHIs reinforce that pipeline identities need the same visibility, rotation, and offboarding discipline as service accounts.

Organisations typically encounter the consequence only after a poisoned build, leaked deployment token, or signed malicious release, at which point the CI trust boundary becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• CI/CD Pipeline
• When does device trust matter for CI/CD access decisions?
• When should organisations re-evaluate CI trust assumptions?
• Why do CI/CD pipelines complicate zero trust architecture?