They should treat machine identities as first-class supply chain assets with owners, expiry rules, and revocation paths. The practical goal is to prove provenance for code, build systems, and release automation. Without that lineage, teams cannot reliably detect whether a trusted pipeline credential has been abused or replaced.
Why This Matters for Security Teams
Machine identities in software supply chains are not just service accounts; they are the credentials that let code be built, signed, fetched, promoted, and released. If those identities are not governed as assets with owners, scope, and expiry, an attacker only needs one weak link to impersonate trusted automation. That is why supply chain governance now has to cover provenance, revocation, and segregation of duties across source control, CI/CD, artifact registries, and release orchestration. The OWASP Non-Human Identity Top 10 frames these as NHI risks, not just access-control hygiene. NHIMG research also shows how quickly exposure becomes operational: in Shai Hulud npm malware campaign style incidents, leaked secrets can be harvested from normal developer workflows before anyone notices. In practice, many security teams encounter machine-identity abuse only after a pipeline has already signed or shipped malicious output, rather than through intentional control testing.
How It Works in Practice
Security teams should build governance around the lifecycle of each machine identity, not around the tool that issued it. Start by inventorying every identity used in the chain: GitHub apps, CI runners, signing bots, artifact publishers, deployment agents, and any token that can invoke them. Then define the minimum trust boundary for each one, including owner, purpose, allowed repositories, allowed environments, and a clear revocation path. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams to map assets, protect them, detect misuse, and recover quickly.
A workable operating model usually includes:
- Short-lived credentials for build and release systems, not long-lived secrets stored in CI variables.
- JIT issuance tied to job context, branch, environment, or signing event.
- RBAC for baseline permissions, plus intent-based checks for higher-risk actions such as publishing or signing.
- Central logging of credential issuance, use, and revocation so provenance can be reconstructed later.
- Automatic deactivation when a pipeline, repo, or runner is retired.
This is not theoretical. NHIMG has documented supply chain credential exposure in both Reviewdog GitHub Action supply chain attack and the broader 52 NHI breaches Report, showing that trusted automation is a common entry point. A relevant current data point is that The State of Secrets Sprawl 2026 found 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations. These controls tend to break down when build systems are shared across many teams and secrets are reused across environments because revocation and attribution become too coarse to be effective.
Common Variations and Edge Cases
Tighter machine-identity control often increases release overhead, so organisations have to balance speed against blast-radius reduction. That tradeoff is especially visible in hybrid estates, third-party build services, and ephemeral runners where operators cannot rely on a single perimeter or a stable host inventory. Current guidance suggests that long-lived static credentials should be phased out wherever the workload can tolerate JIT issuance, but there is no universal standard for this yet across all build systems and package ecosystems.
Edge cases deserve special handling. Air-gapped or offline build environments may need tightly controlled offline signing flows rather than always-on token issuance. Shared runners need stronger tenancy separation because one compromised job can inherit another job’s residue if workspace cleanup is incomplete. Human approvers are also not a substitute for machine-identity governance: manual review can slow abuse, but it does not prove that the credential used to request approval was itself legitimate. For audit and lifecycle detail, NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Regulatory and Audit Perspectives are useful companions. The core rule remains simple: if a machine identity can change code, sign releases, or move artifacts, it needs the same governance discipline as any other privileged production asset.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Directly addresses rotation, scope, and lifecycle control for machine identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management is central to supply-chain machine identity governance. |
| NIST Zero Trust (SP 800-207) | Zero trust supports per-request validation for CI/CD and release automation identities. |
Treat each pipeline action as untrusted until the workload, context, and policy are validated at request time.
