Network Zero Trust leaves CI/CD exposed when teams mistake network limits for release authorization. They restrict routes, but cannot verify identity, approved workflow, artifact integrity, or production authorization.
CI/CD proves trust; network controls limit blast radius
CI/CD controls establish release facts, while network controls reduce harm after compromise. Pipeline policy can bind deployment to a workflow, commit, approver, artifact digest, and environment. A firewall only permits or blocks connections. It cannot give auditors the evidence needed to reconstruct a release.
| Decision or threat | Primary CI/CD control | Network control | Audit evidence | Owner |
|---|
| Stolen cloud credential | OIDC workload identity with claim rules | Restricted egress and private API path | Federation and cloud role logs | Platform and IAM |
| Tampered build artifact | Signature and provenance verification | Private registry endpoint | Digest, attestation, policy result | Release engineering |
| Compromised shared runner | Ephemeral runner and least privilege role | Microsegmentation and egress allowlist | Runner image, session, network logs | Platform security |
| Unapproved production change | Protected environment and policy gate | Production subnet restriction | Approval and deployment record | Engineering manager |
Workload identity gives an automated job claims about its repository, branch, tag, workflow file, environment, and commit SHA. It does not represent a person. A protected production gate can require these claims and an approved change record before granting access. This proves the requester and the conditions that justified promotion.
VPNs, allowlists, and private endpoints cannot inspect cryptographic integrity. They also cannot decide whether an approved workflow produced an artifact. Giving a shared runner broad cloud access because its subnet is trusted is dangerous. A compromised job can use that route to reach production APIs, registries, or secrets.
CI/CD pipeline security also requires protection for the pipeline definition. Treat workflow YAML, reusable workflows, build scripts, dependency manifests, and third-party actions as production-sensitive code. Require pull-request review, CODEOWNERS approval, protected branches, and pinned immutable versions or commit SHAs.
A changed workflow can become the attack path.
In that case, an attacker can alter build commands, steal tokens, weaken tests, or publish a different artifact. They do not need to attack the deployment network. Pull requests from forks and untrusted contributors should have read-only, non-deployment permissions. Production workflow changes should trigger extra policy gates and a recorded review.
Private endpoints cannot authorize production deploys
Private endpoints keep service traffic on approved cloud paths, but they do not validate workflow identity. They also do not validate change approval or provenance. Regulated organizations must show who approved a release and what software entered production. Showing that traffic stayed inside a VPC is not enough.
Persistent self-hosted runners can retain tools, credentials, or malicious changes between jobs. One shared Kubernetes runner may have a convenient cloud role. That role can let a documentation build access privileges intended for production deployment. Private placement did not create the privilege problem, but it can ease lateral movement after execution.
Network controls that reduce damage
Microsegmentation should stop runners from freely reaching databases, Kubernetes control planes, domain controllers, unrelated subscriptions, and other internal systems. Restrict egress to source control, approved registries, artifact storage, identity services, and needed cloud APIs. These controls limit data theft and second-stage payload retrieval. They do not authorize releases.
Network controls still matter after a pipeline compromise.
A private endpoint is like a locked private road. It limits who can use the road, but cannot prove the driver has release approval. This distinction lowers investigation time because logs show both access conditions and allowed routes.
Use OIDC claims instead of cloud secrets
OIDC federation lets each pipeline job request a short-lived cloud session after claim checks. Production roles should trust only a specific repository, protected branch or release tag, workflow, environment, and commit SHA. A session lasting 15 minutes to one hour sharply limits the value of theft.
Bind claims to release context
Use attribute-based access control to check release facts on every request. Do not grant a permanent broad role. Deny pull-request workflows and untrusted forks from assuming deployment roles. They may run code proposed by external contributors.
Tests can run with limited permissions. Production authority belongs only to the protected release path. This is the core difference between a trusted network location and verified release context.
Separate four kinds of identity
Separate human, machine, workload, and break-glass identities. Human approvals need multi-factor authentication, named records, and short administrative sessions. A workload identity belongs to one running job.
Emergency access must remain outside pipeline identities. It must require multi-factor authentication and expire within one to four hours. Log every action and review it within one business day.
One running job should hold one scoped identity.
A useful starting measure: Count active long-lived cloud secrets used by pipelines. Reduce that count to zero for production deployment paths. Track each exception by owner and expiry date. Do not accept permanent exceptions.
A practical DevOps Zero Trust pattern varies by platform, but its trust boundary stays the same. In GitHub Actions, a protected environment can issue an OIDC token after required reviewers approve a release. Cloud trust rules should restrict that token to the repository, protected ref, workflow, environment, and intended audience.
Use isolated ephemeral runners for jobs needing private access. Route registry and cloud-service traffic through private endpoints where supported. Allow egress only to required services.
In Azure DevOps, use workload identity federation for service connections instead of stored client secrets. Limit deployment permissions through environments and checks. Keep build agents separate from production deployment agents. In both platforms, no runner subnet should authorize production deployment by itself.
Production promotion must verify an artifact signature, SBOM, provenance, and policy results. Do not trust a successful build alone. Provenance links an immutable digest to its source repository, commit, builder, and build process. An SBOM lists included components. Promote the exact assessed digest, not a mutable label like latest.
Policy as code should check that an approved signing identity created the signature. It should also check that provenance names the allowed repository, commit, builder, and release workflow. Compare the deploying digest with the digest that passed tests and security checks.
Version-controlled rules create reviewable, repeatable, and testable evidence for every allow or deny decision. The most frequent error is trusting a registry path as proof of software integrity. A registry tells you where an image sits. It does not prove who pushed it or what code produced it.
A private registry is storage, not release evidence.
Combine dependency and static-analysis scans with signatures and attestations. Scans find known issues. Evidence proves that the assessed item is the artifact being promoted.
Production promotion: evidence must travel with the artifact
Protected commit
→
Isolated build
→
Signed digest + SBOM
→
Policy-checked production
A private route supports each stage. It cannot replace evidence in the release chain.
Choose runner and network controls by threat model
Choose hosted or self-hosted runners based on production criticality, data access, regulation, and multi-cloud exposure. Hosted runners reduce infrastructure work. Self-hosted runners reach private systems more directly, but need stronger isolation. Separate identities and pools across clouds to reduce credential misuse and investigation cost.
Use managed hosted runners for low- and medium-sensitivity jobs without broad private access. Give them OIDC cloud access, restricted egress, pinned third-party actions, and no standing production credentials. For sensitive deployments, connect narrowly to needed registries or APIs.
Do not create wide peering that turns a temporary job into an internal foothold. Wide peering may seem workable in theory, but shared runner pools often blur access boundaries. A routine build can inherit network reach and cloud rights meant for a deployment job.
Runner design determines how far a compromised job can move.
This is not an immediate priority for organizations that do not build or deploy their own software. It also waits when SaaS has no configurable pipelines. Start with MFA, protected repositories, code review, and centralized identity management. Keep network controls because they still reduce exposure and data exfiltration.
Measure maturity with operational rates that show whether controls work during daily delivery. Track the share of production paths with zero long-lived secrets. Track the share of promoted artifacts that pass signature checks and software provenance checks.
Also track releases with an immutable digest, SBOM, approval record, and successful policy gates. Review cloud role logs for workload identities with unused permissions over a defined period, such as 90 days.
Measure median identity-revocation time, policy-gate failure rate, and the share of ephemeral runners. These measures turn least-privilege access and deployment authorization into reviewable outcomes. Platform, security, and engineering leaders can review them regularly.
Questions & answers
Can private endpoints secure a CI/CD pipeline?
Private endpoints reduce public exposure, but cannot prove workflow identity, approval, or artifact integrity. Pair them with OIDC, protected environments, and signature verification before production deployment.
Should GitHub Actions use OIDC instead of secrets?
GitHub Actions should use OIDC for cloud access when the provider supports federation. Restrict claims to the repository, protected branch or tag, workflow, and environment. Keep sessions between 15 minutes and one hour.
Production should verify an immutable artifact digest, approved signature, provenance attestation, SBOM, and policy result. A private registry or successful build alone is not sufficient evidence.
Are self-hosted runners less secure than hosted runners?
Self-hosted runners are not inherently less secure, but persistent shared runners create greater lateral-movement risk. Use one-job ephemeral runners, segmented pools, restricted egress, and separate production roles when private access is required.
What matters most:- Network controls restrict routes and reduce blast radius, but they do not authorize a release.
- OIDC workload identity removes persistent cloud secrets and ties access to release context.
- Artifact signatures, SBOMs, and provenance give production a verifiable reason to trust a specific digest.
- Ephemeral runners and scoped network access contain the impact when pipeline execution is compromised.
- Measure verified releases, removed standing access, and revocation speed instead of counting security tools.
Learn more
Here are some additional resources on this subject:
