Why do compromised build and function hosts increase non-human identity risk?

Why This Matters for Security Teams

Build servers and function hosts are not just execution infrastructure. They are high-value identity aggregators that often sit at the intersection of source code, deployment pipelines, cloud APIs, registries, and production access. When one of those hosts is compromised, the attacker rarely gets only one secret type. They often inherit enough material to pivot from a single workload identity into multiple environments and control planes.

This is why the risk is broader than a typical host intrusion. A compromised build host can expose signing keys, package repository credentials, cloud roles, and tokens used by automation, while a function host can leak short-lived execution credentials and the metadata needed to request more. NHI Management Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities, which aligns with the operational reality that identity sprawl and weak secret hygiene make these systems especially attractive targets. The problem is not only exposure, but reuse across layers of automation.

Security teams also need to account for attacker speed. Build and function systems are designed for orchestration, not containment, so once compromised they can be used to harvest more secrets before detection. In practice, many security teams encounter the blast radius only after a deployment pipeline or serverless runtime has already been used as the fastest path into production.

How It Works in Practice

Compromise usually starts with one foothold and ends with credential harvesting. A build host may store package registry logins, cloud deployment tokens, service account keys, SSH material, and access to signing or artifact systems. A function host may not store secrets in files, but it often has runtime permissions, injected environment variables, and access to metadata services or secret managers. If the host is trusted by automation, the attacker can use that trust to request more access without needing to break traditional perimeter controls.

Current guidance suggests treating these hosts as identity-rich workloads rather than generic servers. That means separating build-time permissions from deploy-time permissions, keeping secrets short-lived, and using workload identity to prove what the host or function is before it is allowed to retrieve anything sensitive. The NIST Cybersecurity Framework 2.0 is useful here for organizing asset, access, and recovery controls, but it does not by itself solve secret exposure on compromised automation nodes.

• Use just-in-time access for pipelines and runtime tasks instead of persistent credentials.
• Bind secrets to workload identity and task context, not to the host alone.
• Rotate signing keys, registry tokens, and cloud credentials after any suspected host compromise.
• Monitor for unusual secret access, token minting, and lateral movement from build and function infrastructure.

For teams mapping the threat surface, the 52 NHI Breaches Analysis and the Top 10 NHI Issues show how often secret sprawl and weak lifecycle controls turn routine infrastructure into an identity compromise event. These controls tend to break down when build hosts share privileged tooling with production automation because one compromised execution path can reveal both operational secrets and the permissions needed to mint more.

Common Variations and Edge Cases

Tighter isolation often increases operational overhead, requiring organisations to balance pipeline speed against the cost of more frequent reauthentication and secret rotation. That tradeoff is real, especially in environments that rely on high-frequency builds, ephemeral test environments, or distributed serverless deployments.

There is no universal standard for this yet, but best practice is evolving toward segmented identities for each stage of the software and runtime lifecycle. Build hosts should not carry the same access as deploy hosts, and functions should not be able to reach broad control-plane permissions simply because they are ephemeral. In practice, that means using distinct service accounts, short TTL tokens, and policy checks that evaluate the request at runtime rather than assuming the host’s general trust level is enough.

Edge cases appear in shared runners, self-hosted CI/CD, and hybrid cloud environments where one host supports many tenants or many teams. Those environments need stronger secret inventory, faster revocation, and tighter logging because compromise of one runner can expose multiple projects at once. The Ultimate Guide to NHIs highlights how excessive privileges and poor rotation amplify that problem, while the Anthropic report on AI-orchestrated cyber espionage is a reminder that automated abuse can move faster than manual response. This guidance becomes less reliable when host-level compromise can also tamper with logs, secret retrieval, and the controls meant to detect misuse.

Related resources from NHI Mgmt Group

• Why do non-human identities increase identity blast radius?
• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?