Stay Ahead With Linux Security Features

infrastructure securitycredential theftsupply chain

Why CI/CD Pipelines Became Targets in Software Supply Chain Attacks

For years, software security discussions centered on vulnerable code. A bug inside an application could expose a workstation, production server, or cloud workload, so most supply chain conversations focused on malicious packages, outdated dependencies, and exploitable libraries buried somewhere inside the stack. That is no longer the main problem. . A single compromised GitHub Action can quietly hand attackers the same infrastructure access senior administrators use to deploy production systems, publish software updates, manage cloud workloads, and rotate secrets. In many environments, the pipeline now holds broader operational access than the engineers maintaining it. Attackers realized they often do not need to exploit software directly when they can steal the credentials used to build, deploy, and publish it instead. As CI/CD pipelines became the backbone of modern development, they also became one of the most attractive targets in the software supply chain. The shift changed the nature of software supply chain attacks. Instead of poisoning code alone, attackers increasingly target the automation infrastructure responsible for building and delivering trusted software in the first place. CI/CD security is no longer a DevOps problem sitting quietly in the background. It is now core infrastructure security. Pipe-Psiphon and the Shift Toward Credential Theft In early 2026, a campaign known as Pipe-Psiphon showed how effective that transition had become. A widely used developer scanning tool was modified with malicious code that blended directly into normal CI/CD workflows. Nothing crashed. Most organizations saw no obvious alerts, failed deployments, or unusual system behavior during the initial compromise window. The tool simply operated inside runner environments and waited. Each pipeline execution gave it another opportunity to scrape secrets directly from memory, including GitHub tokens, AWS credentials, npm authentication keys, SSH material, and deployment secrets. The collecteddata was then transmitted to the attacker-controlled infrastructure while workflows continued running normally in the background. What made the campaign dangerous was not the malware sophistication alone. The compromised tool inherited the same trust relationships already granted to the pipeline itself, including deployment access, cloud permissions, package publishing authority, and repository automation privileges. By that point, the code being scanned mattered less than the infrastructure performing the scan. The trust sitting behind the pipeline had become the real target. The Assembly Line Behind Modern Software Understanding why these attacks work starts with understanding what CI/CD actually does. CI/CD, short for Continuous Integration and Continuous Delivery, functions as the automated assembly line behind modern software development. Developers push code into GitHub, GitLab, or internal repositories, then automated workflows begin testing applications, scanning dependencies, building containers, publishing packages, and deploying updates into production infrastructure. Most organizations rely on this automation heavily because it removes manual deployment work. Developers no longer need to log into servers directly every time software changes. Pipelines handle most of the operational work automatically. Convenient, but dangerous. The pipeline itself needs privileged access to function, which means CI/CD environments gradually accumulate credentials tied to cloud infrastructure, repositories, package registries, Kubernetes clusters, deployment tooling, and production systems. A typical environment may contain: AWS credentials for deployments DockerHub authentication tokens SSH keys for infrastructure access GitHub Personal Access Tokens npm publishing credentials Kubernetes configurations and Terraform state files Most of those secrets live inside environment variables or encrypted secret stores so workflows can authenticate automatically atruntime. Teams add more access over time because deployments fail without it, and eventually the pipeline ends up holding broader operational reach than many individual administrators. Attackers noticed that years ago. GitHub Actions Wake-Up Call One of the clearest previews arrived in March 2025 during the compromise of the widely used GitHub Action tj-actions/changed-files . The tool itself handled a relatively simple task. It identified which files changed during workflows so automation logic could react accordingly. More than 23,000 repositories depended on it, many of them deeply embedded inside deployment pipelines. Attackers did not target those repositories one by one. They compromised the shared dependency already trusted across thousands of environments, then modified the action so it quietly exposed secrets available during workflow execution. Some credentials leaked directly into public workflow logs. Other attacks relied on memory scraping techniques against active CI/CD runners, pulling secrets from live environments while jobs continued executing normally. The credential exposure mattered less than the access attached to those credentials. Investigators later connected the incident to a broader campaign affecting at least 218 repositories, including systems associated with Coinbase. Researchers also identified compromises tied to another dependency, reviewdog/action-setup , which widened the supply chain impact even further. Supply chain attacks scale differently from ordinary intrusions. One compromised automation component can spread through thousands of downstream environments before defenders fully understand where the trust boundary actually failed. Why Credentials Became the Real Target Older cyberattacks often focused on disrupting systems or exploiting software vulnerabilities directly. Modern supply chain operations increasingly revolve around stealing trusted access instead. A compromised personal password may expose a single account. A compromisedCI/CD credential can expose the infrastructure responsible for building and distributing software across an entire organization. That access may include: Cloud infrastructure administration Deployment pipeline control Software publishing permissions Kubernetes cluster access Package signing capabilities Administrative access across repositories and workloads For attackers, that level of access is usually far more valuable than compromising one server through a traditional exploit. Later CI/CD compromises involving Aqua Security's Trivy GitHub Actions infrastructure reportedly exposed GitHub tokens, Kubernetes configurations, Terraform state files, SSH keys, shell histories, VPN configurations, and even cryptocurrency wallets pulled directly from active runner environments. At that point, the pipeline was no longer supporting the attack surface. It had become the attack surface. The problem gets worse because malicious activity originating from CI/CD infrastructure frequently appears legitimate. Updates deployed through trusted automation systems often bypass traditional monitoring entirely since the activity comes from approved workflows using valid credentials. Attackers are not just targeting software anymore. They are targeting the factory responsible for producing and delivering it. The Convenience Problem Inside GitHub Actions GitHub Actions became widely adopted largely because developers can automate almost anything with minimal friction. Testing, vulnerability scanning, deployments, and release pipelines. Most of it can be assembled quickly using reusable public actions. That convenience also created a predictable attack path. Many repositories still reference third-party GitHub Actions using floating version tags such as: uses: tj-actions/changed-files@v35> At first glance, that looks reasonably safe, but it is not. Version tags are mutable. If attackers gain access to the repository maintaining the action, tags like @v35 can be silentlyredirected toward malicious commits without downstream users realizing anything changed. Existing trust relationships do the rest. Pipelines continue executing the compromised code automatically because the dependency was already approved months earlier. In practice, many organizations are running third-party automation pulled from public repositories with direct access into production environments, package registries, cloud infrastructure, and deployment tooling. Some teams barely review the dependencies beyond confirming the workflow still succeeds. Attackers understand these environments extremely well by now. Recent supply chain operations have repeatedly targeted: Mutable GitHub Action tags Overprivileged automation accounts Exposed Personal Access Tokens Insecure pull_request_target workflows Workflow logs containing secrets Long-lived credentials stored inside repositories The attack paths are often surprisingly simple. Compromise one trusted automation component, wait for downstream pipelines to execute it automatically, then collect the credentials already available inside the environment. No exploit chain required. How One GitHub Action Exposed Thousands of Repositories The tj-actions/changed-files compromise became a wake-up call because downstream repositories often had no indication that anything was wrong. Attackers modified a trusted GitHub Action already embedded across thousands of CI/CD workflows. Once the pipelines executed the malicious update, secrets stored inside the runner environments became exposed through logs, memory scraping activity, and inherited workflow permissions. Most affected organizations never intentionally approved malicious code. They approved a floating tag months earlier and trusted the dependency relationship to remain stable afterward. That distinction matters. A typical vulnerable workflow looked like this: uses: tj-actions/changed-files@v35> A hardened version pins directly to an immutablecommit hash: uses: tj-actions/changed-files@24d32ffd492484c1d75e0c0b894501ddb9d30d62> Once pinned, attackers cannot silently redirect the workflow toward newer malicious commits without maintainers explicitly updating the reference themselves. The operational problem is that most teams still treat CI/CD dependencies like convenience tooling rather than privileged infrastructure. Pipelines inherit secrets, deployment access, repository permissions, cloud credentials, and package publishing authority almost automatically. One compromised action can inherit all of it. How to Audit Your CI/CD Environment Organizations trying to improve pipeline security should start by reviewing existing workflows before adding new tooling. Most exposure comes from accumulated convenience decisions made over time rather than one catastrophic configuration mistake. A useful first step is identifying workflows using floating tags instead of immutable commit hashes: grep -R "uses: .*@v" .github/workflows/ That will usually surface reusable actions still pinned to mutable version labels. Next, review workflow permissions. Many GitHub Actions environments run with broader access than they actually need. Overly permissive example: permissions: write-all Safer baseline: permissions: {} Then explicitly grant only what the workflow requires: permissions: contents: read The same review process should apply to secrets management. Teams should identify: Long-lived Personal Access Tokens Secrets shared across multiple repositories Unused deployment credentials Exposed environment variables inside logs pull_request_target workflows executing untrusted code Self-hosted runners exposed to public repositories Secret sprawl becomes difficult to track once pipelines scale across multiple repositories and cloud environments. By then, most organizations have credentials sitting in workflows nobody has reviewed in months. Several tools help automateparts of the audit process: Gitleaks for secret discovery inside repositories Trivy for container and workflow scanning OpenSSF Scorecards for supply chain risk analysis GitHub Secret Scanning for exposed credential detection OPA/Conftest for enforcing workflow security policies Even basic scans usually uncover old Personal Access Tokens, overprivileged automation accounts, or deployment secrets that should have been rotated years earlier. Hardening the Software Supply Chain Improving CI/CD security does not require rebuilding the entire development process, but it does require treating automation infrastructure as critical infrastructure rather than background tooling. One of the most effective GitHub Actions hardening steps is pinning reusable actions to immutable commit hashes instead of floating tags. Unlike labels such as @v35 , commit hashes cannot be redirected silently after approval. Another major improvement involves reducing default workflow permissions. Many pipelines still run with unnecessary repository write access because GitHub Actions historically granted broad defaults. Restricting permissions aggressively reduces the blast radius if a workflow or third-party dependency becomes compromised. Example hardened workflow configuration: permissions: contents: read pull-requests: read OIDC authentication also helps reduce long-lived credential exposure. Instead of storing static cloud secrets inside repositories, pipelines request temporary credentials dynamically during runtime. Example AWS OIDC trust relationship: { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" } } } That approach limits the value of stolen credentials because the authentication tokens expire automatically after short periods rather than remaining valid indefinitely. Short-lived authentication is becoming more important as well. Many organizations are moving toward OpenID Connect (OIDC) models where pipelines request temporary credentials that expire automatically instead of relying on long-lived secrets that remain valid for months or years. Other hardening measures include: Reducing unnecessary repository permissions Rotating exposed tokens regularly Removing unused secrets from workflows Enforcing MFA for maintainers Reviewing workflow logs for leaked credentials Restricting self-hosted runner access Auditing third-party GitHub Actions before deployment The objective is no longer limited to protecting source code. Organizations now need to protect the trust relationships responsible for delivering software across their environments. Why CI/CD Security Became Core Security Modern software development depends heavily on automation. CI/CD systems build applications, publish packages, deploy infrastructure, scan dependencies, and distribute updates across production environments every day, usually with minimal human interaction once the workflows are in place. In many organizations, the pipeline now holds more operational access than the developers using it. That reality changed the economics of software supply chain attacks. The danger no longer sits exclusively inside malicious downloads or vulnerable open-source libraries hidden somewhere in the dependency tree. Increasingly, attackers focus on the automated infrastructure trusted to build and distribute software in the first place because compromising that layer scales far better than targeting individual systems. The GitHub Actions compromises and the Pipe-Siphon campaign made that painfully clear. One exposed credential inside a CI/CD environment is no longer just a configuration mistake sittingquietly in a workflow file. It can become the entry point into the entire software supply chain. Stay Ahead of Linux Security & Infrastructure Trends Interested in more in-depth coverage of Linux security, CI/CD security, software supply chain defense, DevSecOps , and enterprise hardening strategies? Subscribe t o the LinuxSecurity newsletter for weekly threat analysis, infrastructure security insights, and practical guidance covering the Linux and open-source ecosystem. Related Reading Linux Supply Chain Attacks Threaten DevOps Teams and Security CI/CD Pipelines Vulnerabilities in Trusted Execution Paths The Next Wave of Supply Chain Attacks: NPM, PyPI, and Docker Hub Incidents Set the Stage for 2026 Securing the Software Supply Chain with In-Toto Open-Source Supply Chain Attacks Threaten Linux Production Systems . Modern software supply chain attacks target CI/CD credentials instead of code. Discover strategies for protecting your pipelines.. CI/CD Security. . MaK Ulac

May 14, 2026 • MaK Ulac