Continuous integration and continuous delivery are often described as engineering automation: code enters a repository, tests run, an artifact is built, and a release moves into an environment. That description is operationally correct, but it leaves out the security fact that matters most. A CI/CD workflow is also a programmable access path into production.
Modern pipelines authenticate to source repositories, package registries, cloud control planes, Kubernetes clusters, secret stores, signing services, and deployment platforms. They can create infrastructure, replace container images, modify access policies, publish packages, rotate configuration, and delete resources. In many environments, a deployment workflow can perform changes that would require a senior administrator to pass multifactor authentication and obtain privileged access through a controlled session.
The difference is that the workflow often performs those actions through machine identity. Its authority is encoded in YAML, runner configuration, repository permissions, cloud trust policies, and secrets that may be invisible to the security team. A malicious workflow edit, compromised third-party action, poisoned build dependency, or hostile runner process can turn that machine identity into a direct path to production.
NIST treats the source, build, test, package, and deployment stages as connected software supply chain activities whose integrity affects the security of the delivered system. OWASP frames CI/CD systems in similar terms, listing weak flow controls, poisoned pipeline execution, poor credential handling, weak pipeline-based access controls, artifact integrity failures, and limited visibility as major CI/CD risks. These models point to the same conclusion: pipeline security is production access security.
The Pipeline Is a Privileged Identity
A user account is usually evaluated through identity governance. Security teams can ask who owns it, what roles it holds, how it authenticates, whether its access is temporary, and which actions it performed. CI/CD workflows need the same treatment.
A pipeline job receives an identity at runtime. In GitHub Actions, the automatically issued repository token can call GitHub APIs, read source, publish packages, update releases, or write back to the repository based on its configured permissions. GitHub notes that an action can access this token through the workflow context even when the workflow does not explicitly pass it, which makes job-level permission scoping a core control. GitLab generates a job token for each running job and ties its access to the triggering user and the endpoints the token can reach.
Production deployments often add a second identity layer. The workflow exchanges an OpenID Connect token for a short-lived cloud role, reads a static service-account key from a secret store, obtains a Kubernetes credential, or invokes a deployment controller. The job may exist for only minutes, but its effective permissions can include production write access.
This is why a workflow should be modeled as a service principal with executable logic. The identity is not just the token. It is the combination of trigger, repository, branch or tag, workflow file, reusable workflow, runner, environment, artifact, and cloud role. A weakness in any one of those elements can alter what the identity is allowed to do or what code runs under its authority.
Source Control Has Become Part of the Production Control Plane
In many organizations, the route to production starts with a pull request rather than a privileged login. A developer changes application code, an infrastructure template, a Helm chart, a Terraform module, or a workflow file. Once the change is merged, automation builds and deploys it.
That architecture shifts part of the production control plane into source control. Repository administration, branch protection, code ownership, merge rights, workflow permissions, and release tagging now influence production state. An attacker who compromises a developer account may not need direct access to AWS, Azure, Google Cloud, or a Kubernetes API. The attacker may be able to change the instructions that an already trusted workflow will execute.
The most dangerous repository changes are not always application-code changes. A one-line edit to a workflow can grant broader token permissions, replace a pinned action with a mutable tag, add a data-exfiltration command, route a deployment through a hostile script, or request an identity token for a cloud role. Changes to deployment manifests can point production at a malicious image digest. Changes to infrastructure code can create new credentials, weaken network controls, or add an attacker-controlled identity to a privileged role.
Protected branches and mandatory review help, but they do not solve the issue by themselves. Workflow files, reusable workflows, infrastructure code, deployment manifests, and policy files need stricter ownership than ordinary application code. A review from someone who can assess business logic is not equivalent to a review from someone who can evaluate token scope, trigger safety, shell expansion, artifact flow, and cloud trust conditions.
How Pipeline Abuse Becomes Production Compromise
A CI/CD attack usually begins before the production deployment step. The attacker first gains influence over code or execution. That influence may come from a compromised developer account, a malicious pull request, a third-party action, a package dependency, a stolen repository token, a vulnerable CI server, or a persistent runner.
The next step is code execution inside the pipeline. OWASP calls one form of this poisoned pipeline execution: an attacker manipulates pipeline configuration or referenced files so malicious commands run inside the build environment. The attacker may edit the primary workflow directly, or alter a script, Makefile, package manifest, test hook, or build tool that the workflow invokes.
Once code runs on the runner, the attacker looks for authority. That may include the repository token, environment secrets, cloud credentials, package publishing rights, cached credentials, signing keys, metadata-service tokens, deployment API tokens, or network access to internal systems. OWASP describes this as a pipeline-based access-control problem: code executing in a job can abuse the permissions granted to the pipeline to move into other systems.
The final step depends on the pipeline. The attacker may deploy a backdoored image, modify infrastructure, publish a malicious package, replace a release artifact, read production secrets, alter identity policy, or use the runner as a bridge into an internal network. A pipeline compromise can create both an immediate production incident and a downstream software supply chain incident if customers or other internal teams consume the resulting artifact.
Workflow Triggers Can Cross Trust Boundaries
CI/CD systems process a large amount of attacker-controlled data. Branch names, commit messages, issue titles, pull-request bodies, changed filenames, labels, matrix values, and repository metadata may all enter expressions or shell commands.
GitHub warns that untrusted context values can become script injection when a workflow interpolates them directly into a command. A malicious string that appears harmless as repository metadata can be interpreted by Bash, Python, or another command interpreter once the job starts. GitHub also warns that certain trigger combinations, including privileged workflow events paired with checkout of untrusted pull-request code, can expose a repository to compromise.
The security question is not simply whether a workflow runs on a pull request. It is which revision runs, which token permissions are present, whether secrets are exposed, whether the base or fork code is checked out, and whether the job runs on infrastructure shared with trusted workloads.
A safe pull-request validation job should operate with read-only repository permissions, no production secrets, no deployment identity, and no access to persistent runners or internal networks. A privileged post-merge deployment job should run only from a protected revision after required controls have passed. Combining untrusted code evaluation and privileged deployment in the same workflow creates a direct trust-boundary failure.
Third-Party Actions Are Executable Dependencies
Third-party workflow actions are often treated like configuration modules. They are code executed inside the runner with the permissions, files, tokens, and network access available to that job.
This risk became harder to dismiss after the compromise of tj-actions/changed-files, which CISA tracked as CVE-2025-30066. The malicious action exposed secrets through workflow logs. GitHub’s 2026 Actions security roadmap also cites incidents involving tj-actions/changed-files, Nx, and trivy-action as evidence that attackers are targeting CI/CD automation and over-permissioned credentials.
Mutable references make this attack path more dangerous. A workflow that calls vendor/action@v3 trusts whoever can move that tag. The workflow may run different code tomorrow without any change in the consuming repository. GitHub recommends pinning actions to a full commit SHA and now supports organization and enterprise policies that can reject unpinned actions.
Pinning is a containment measure, not a complete validation method. Teams still need an allowlist for external actions, an ownership process for internal reusable workflows, automated update review, and a way to identify transitive code fetched at runtime. An action pinned to a known commit can still be unsafe, and a secure commit can later pull an untrusted script, package, or container image during execution.
The stronger pattern is to reduce third-party code in privileged jobs. Build and test workflows may need a broader action set. Production deployment workflows should use a small, centrally maintained set of reviewed components, each pinned to an immutable reference.
Runners Are Production-Adjacent Compute
The runner is where workflow text becomes operating-system activity. Any security model that focuses on repository permissions and ignores the runner is incomplete.
GitHub-hosted runners use clean, ephemeral virtual machines for each job. Self-hosted runners have different risk properties. GitHub states that self-hosted runners can be persistently compromised by untrusted workflow code and warns that a compromised organization-level runner can affect several repositories. GitLab gives similar guidance: non-ephemeral self-managed runners can leak tokens, retain malicious code, expose other repositories, and permit host compromise, especially with shell executors or privileged containers.
A runner with production network access is a production access path even when it lacks an explicit deployment credential. It may reach internal package registries, databases, metadata services, cluster APIs, administration endpoints, or secret brokers that are unreachable from the public internet. An attacker who gains runner execution may use that network position to scan, authenticate, or exploit adjacent systems.
Persistent runners also create cross-job risk. Residual workspace data, caches, process lists, container layers, temporary files, SSH material, and local credential helpers can expose data from earlier jobs. A cleanup script is weaker than creating a fresh execution environment from a known image.
High-trust jobs should use isolated runner pools, single-use instances, minimal base images, restricted egress, no ambient cloud credentials, and no shared cache with untrusted jobs. GitHub’s just-in-time runner model limits a runner to one job, though GitHub still warns that reused hardware needs a clean environment. GitLab recommends a one-build lifecycle for autoscaled machines exposed to risky execution modes.
Long-Lived Secrets Turn Workflow Bugs Into Credential Theft
Static cloud keys and service-account credentials remain common in CI/CD. They are easy to store as repository or organization secrets, and easy to reuse across jobs. They also create a durable credential that can survive long after the workflow run ends.
Masking does not make a secret safe from code executing inside the job. A malicious process can transmit it over the network, encode it to bypass log masking, place it in an artifact, write it to a cache, or use it directly against the target service. Protected variables narrow where a secret is presented, but any code that runs inside an authorized job can attempt to read or use it. GitLab notes that CI/CD variables are less secure than dedicated secret-management systems and can be exposed through pipeline configuration errors.
Federated workload identity changes the model. GitHub Actions, GitLab, Azure DevOps, and other systems can issue OpenID Connect tokens that describe the job. A cloud provider can validate those claims and return a short-lived credential. GitHub’s AWS guidance recommends trust-policy conditions that bind role assumption to the token subject, such as a named repository, branch, or deployment environment. Google Cloud likewise recommends workload identity federation for deployment pipelines instead of service-account keys.
Federation removes a stored cloud key, but it does not remove risk. A broad trust policy can let any branch, workflow, repository, or fork request a production role. The trust relationship needs to bind the identity to stable claims and a narrow deployment context. The cloud role also needs a short session duration and permissions limited to the release operation.
The best design makes credential issuance depend on policy outside the workflow file. A workflow should not be able to grant itself production access by editing its own YAML. The cloud identity provider should independently verify the repository, protected ref, environment, audience, workflow identity, and any required approval state.
Build and Deploy Must Be Separate Security Domains
Many pipelines build an artifact and deploy it in one job. That design gives build scripts, test tools, package managers, and third-party actions access to production credentials. It also makes it difficult to prove that the artifact entering production is the artifact that passed testing.
A safer design separates build from deployment. The build stage receives source and dependency access, produces an immutable artifact, records its digest, generates provenance, and publishes it to a controlled registry. It has no production deployment authority.
The deployment stage receives a digest or verified artifact reference, checks provenance and policy, obtains a short-lived environment-specific identity, and promotes that exact artifact. It does not run the package manager, compile source, execute unit tests, or rebuild the release.
This separation shrinks the trusted computing base for production access. The production job no longer needs to trust every compiler plugin, test dependency, code generator, or build hook. It needs to trust the artifact verification process, the deployment component, the identity exchange, and the target platform.
NIST recommends isolated build platforms, hardened build servers, enforced build policy, and concurrently generated evidence that records the environment, process, materials, and final artifact. The evidence should be protected by a component with a higher trust level than the build process itself.
Artifact Integrity Must Be Enforced at Deployment
An artifact signature or provenance record has limited value when no control checks it before release. SLSA describes provenance as verifiable information about where, when, and how an artifact was built, including the build platform, process, and inputs. Its threat model also covers tampering after CI/CD and ties verification to the artifact hash.
Production policy should answer a direct question: is this exact artifact allowed to run here? The verifier can require a trusted repository, approved workflow, protected branch or tag, expected builder identity, valid signature, matching digest, and required security evidence.
GitHub artifact attestations create signed provenance claims for builds, and GitHub documents Kubernetes admission enforcement that can reject images lacking an attestation from the approved organization. This moves the final decision from pipeline intent to runtime policy. A compromised workflow cannot deploy an arbitrary image merely by changing a manifest when the cluster independently validates artifact origin and identity.
The artifact should also move through environments by digest. Rebuilding separately for staging and production creates two different artifacts and breaks the evidence chain. Promotion should change policy state or deployment references, not rerun the build.
GitOps Removes Direct Cluster Credentials but Moves the Trust Boundary
GitOps can reduce direct production access from CI. In an Argo CD model, the pipeline updates a repository containing the desired deployment state. Argo CD, running inside or near the cluster, detects the change and synchronizes the live environment. Argo CD’s documentation states that automated sync lets the pipeline deploy by committing to Git instead of calling the Argo CD API directly.
This is a strong architectural change, but it does not eliminate the production access path. It relocates it.
The deployment repository becomes an authorization boundary. Anyone who can merge an image change, chart update, configuration edit, or policy modification may be able to alter production. The GitOps controller becomes a privileged deployment identity. Its repository credentials, cluster roles, project boundaries, sync policy, pruning rights, and source restrictions define the blast radius.
A secure GitOps design separates application source from environment state, restricts who can update production manifests, verifies artifact digests and provenance, limits the controller to named namespaces or resource types, and requires review for changes to controller projects, repository mappings, and cluster credentials.
Auto-sync also changes incident timing. A malicious commit may become a cluster change within minutes. Detection and rollback need to operate at repository speed, and emergency controls need a way to suspend reconciliation, revoke repository access, or block an artifact at admission.
Production Approval Must Control Identity, Not Just Workflow Progress
Many platforms support protected environments and required reviewers. These gates are useful, but their placement matters.
An approval that occurs after a job has already received a production credential is too late. An approval that protects only a named secret does not protect an ambient runner credential or a cloud role available through a broad OIDC trust policy. An approval that can be removed through the same pull request does not create an independent control.
The gate should control the issuance or use of the production identity. The workflow can build and prepare a release before approval. After approval, a separate deployment job obtains a short-lived role scoped to one environment and one operation. The approval record, workflow run, artifact digest, identity session, and deployment event should be linkable in audit logs.
GitHub environments can require reviewers, block self-approval, restrict deployment branches or tags, and withhold environment secrets until protection rules pass. Those controls are strongest when the cloud trust policy references the same protected environment and refuses identity tokens from other contexts.
High-risk production changes may need a second independent policy check. Examples include infrastructure deletion, identity-policy changes, database migration, secret rotation, and changes to the deployment system itself. These actions should not inherit the same unattended path used for routine application releases.
CI/CD Security Needs Cross-System Detection
Pipeline attacks cross several control planes, so no single audit log tells the full story. Repository logs show workflow changes and merges. CI logs show job steps and runner assignment. Identity logs show token exchange and role assumption. Registry logs show artifact publication. Cloud and cluster logs show the resulting production change.
Security operations should correlate these events by repository, commit, workflow run, artifact digest, environment, runner, and workload identity. That chain makes it possible to answer whether a production change came from an approved source revision and a verified artifact.
High-value detections include changes to workflow files, permissions, reusable workflows, protected branches, runner groups, environment rules, action references, and OIDC trust policies. Runtime detections should cover unusual token issuance, production role assumption from an unexpected ref, outbound connections from runners, access to cloud metadata services, secret retrieval outside normal jobs, registry tag replacement, artifact digest drift, deployment of unsigned images, and GitOps changes from an unapproved identity.
OWASP lists limited logging and visibility as a distinct CI/CD risk, and GitHub’s 2026 roadmap calls for stronger runner observability and network controls. The industry direction reflects a basic operational gap: many organizations can trace a human administrator’s production session more clearly than a workflow that changed the same systems.
Incident Response Must Treat the Pipeline as Compromised Infrastructure
A compromised pipeline requires more than reverting a commit. Attackers may have copied secrets, altered tags, replaced artifacts, poisoned caches, modified reusable workflows, persisted on runners, changed cloud trust policy, or published packages consumed elsewhere.
Containment starts by disabling affected workflows and deployment controllers, revoking federated trust where needed, rotating exposed credentials, quarantining self-hosted runners, blocking suspect actions or commits, and freezing artifact promotion. Teams then need to identify every workflow run that used the compromised component and every artifact produced during that period.
Recovery should use a known-clean runner image, reviewed workflow definitions, reissued credentials, verified dependencies, and rebuilt artifacts with fresh provenance. Production systems need redeployment from a known-good digest. Downstream consumers may need notification when a compromised pipeline published packages, containers, installers, or updates.
The investigation also needs to preserve ephemeral evidence. Workflow logs, runner telemetry, cloud identity events, registry records, deployment-controller history, and artifact attestations can disappear on different schedules. Retention settings should reflect the time it may take to discover a software supply chain incident.
A Safer CI/CD Architecture
The target architecture is a sequence of narrow trust decisions rather than one large workflow with broad access.
Untrusted pull-request jobs run on isolated ephemeral infrastructure with read-only permissions and no secrets. Protected merge workflows build artifacts without production credentials. External actions are allowlisted and pinned to immutable commits. The build emits a digest, software bill of materials, and signed provenance from an isolated builder.
A separate deployment workflow accepts only the verified artifact digest. It runs from a protected environment, passes an approval or policy gate, and exchanges an OIDC token for a short-lived role bound to the expected repository, ref, workflow, and environment. Its runner has access only to the deployment endpoint and approved supporting services.
The target environment verifies the artifact again. A Kubernetes admission policy, release controller, or deployment platform rejects artifacts that lack trusted provenance, expected signatures, or an approved source identity. Cloud permissions prevent the deployment role from changing its own trust policy or creating new privileged identities.
GitOps can replace direct cluster access, provided the deployment repository is governed like production infrastructure and the controller’s cluster rights are tightly bounded. Logs from source control, CI, identity, registry, and runtime are joined around the same commit and artifact digest.
This design does not rely on the workflow file to police itself. Repository governance, identity policy, runner isolation, network policy, artifact verification, and runtime admission each provide an independent boundary.
The Production Perimeter Starts at the Commit
CI/CD made software delivery faster by converting manual release steps into code. That same shift converted production access into code.
The security perimeter now includes the repository setting that allows a workflow, the branch rule that permits a merge, the action tag resolved at runtime, the runner that executes the job, the token issued to it, the registry that stores the artifact, and the controller that applies the release.
Treating CI/CD as a developer tool leaves those production paths under-governed. Treating it as privileged infrastructure changes the questions security teams ask. Who can modify the path? What code can run inside it? Which identity does it receive? What can that identity reach? Can the resulting artifact be verified independently? Can every production change be traced back to an approved commit and a trusted build?
A workflow that can deploy to production is production access. Its code deserves the same review as privileged automation, its identity deserves the same controls as an administrator, and its execution environment deserves the same scrutiny as any system operating inside the production trust boundary.
How Can Netizen Help?
Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally.
Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.
Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.
Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.
Netizen Blog and News 
Leave a comment