The software supply chain has become one of the most attractive targets for modern adversaries, but the attacks seen in 2025 did not focus solely on poisoning dependencies or hijacking packages. Increasingly, attackers are targeting the infrastructure that powers the software delivery lifecycle itself.
Build servers, CI/CD runners, package managers, and developer workstations all sit inside an organization’s trusted delivery path. They are designed to execute code automatically, often with elevated privileges, and to move artifacts through the environment without scrutiny. Those same design principles make them ideal attack surfaces. Once an adversary gains access to this trusted infrastructure, malicious activity can blend seamlessly into legitimate build and release workflows.
Now, adversaries are increasingly adopting “shift-left” tactics to subvert build runners, poison development dependencies, and weaponize automation tools before code can even reach a production server. Instead of breaching the perimeter and forcing malware inward, attackers are compromising the systems that organizations inherently trust to deliver software. The result is a class of intrusion that is harder to detect, faster to scale, and capable of bypassing traditional security controls by abusing automation itself.
The Subversion of Trusted Infrastructure
Build servers and runners are high-value targets because they routinely execute privileged actions. They compile code, pull dependencies, move artifacts, and deploy software – all activities that mirror the behavior of an attacker attempting to establish persistence or distribute malware.
Threat actors have recognized that compromising build infrastructure gives them an opportunity to weaponize trust. In one case, attackers exploited a vulnerable self-hosted TeamCity server and remained undetected for more than a year. After gaining access, they created a benign-looking build configuration that was executed by a trusted build agent running with SYSTEM privileges. That build job then deployed a backdoor into internal environments.
Since the malicious code was delivered through a legitimate CI/CD task, it appeared indistinguishable from normal operational activity. No suspicious external binary was introduced, no obvious malware delivery mechanism was observed, and the deployment path blended into routine release workflows. This kind of attack points to the core challenge defenders face: In CI/CD environments, malicious behavior often looks exactly like expected behavior.
Turning Automation Against the Organization
Pipeline compromise does not always require direct malware execution on the build server. In many cases, attackers simply manipulate automation workflows to make the organization’s own tools carry out the intrusion.
One observed intrusion, noted in this year’s Annual Threat Report, involved the compromise of a GitLab service account token. The attacker used the token to create projects containing malicious Ansible playbooks, which were then automatically executed by the organization’s CI/CD pipeline. The build system treated the attacker’s commands as authorized automation, effectively turning the deployment pipeline into the orchestration mechanism for the compromise. This is what makes CI/CD subversion so dangerous. Rather than needing to evade the build process, the attacker simply inherits it.
Once inside the pipeline, the adversary gains the same benefits as the automation itself. This includes trusted execution, access to internal resources, and the ability to move laterally under the guise of legitimate activity. Traditional security tools often struggle to distinguish malicious pipeline actions from expected operational tasks, especially when those tasks are executed under valid service identities.
The Human Layer Is Part of the Pipeline
Some of the most effective “shift-left” attacks in 2025 targeted the developers themselves, bypassing the targeting of target code or infrastructure first. Campaigns like Contagious Interview used fraudulent job offers to compromise developers working in cryptocurrency and blockchain sectors. Victims were directed to fake skill-assessment sites where they encountered fabricated technical errors and were instructed to run commands to “fix” the issue. Those commands silently deployed malware on the developer’s workstation. This approach gave attackers direct access to the developer’s local environment, including SSH keys, repository access, tokens, and credentials. From there, the path into source code repositories and CI/CD systems became significantly easier.
By compromising the human operators behind the development process, attackers gain access at the earliest stage of the software lifecycle – what might be the ultimate “shift left” advantage. Instead of attacking production systems, they infiltrate the environments where software is built, tested, and trusted. This reinforces an important reality in which the software pipeline extends beyond infrastructure. Developers, maintainers, and service accounts are all part of the attack surface.
Unauthorized Runners and Persistent Access
Another growing tactic is the unauthorized registration of attacker-controlled systems as legitimate build runners. In the Sha1-Hulud campaign, malware infected systems and registered them as self-hosted GitHub runners under attacker-defined names. These rogue runners were then able to execute build tasks as trusted participants in the CI/CD process.
This is especially dangerous because self-hosted runners are often granted broad access to repositories, secrets, and deployment workflows. Once a malicious runner is registered, the attacker gains persistent, authorized access inside the development pipeline without needing to repeatedly exploit vulnerabilities.
The campaign also used malicious workflow triggers to ensure persistence. Certain workflows were designed to execute code when a user posted a comment in a repository discussion, turning routine collaboration features into execution mechanisms. Attackers no longer hijack the builds, opting instead to embed themselves into the development lifecycle in modern CI/CD compromise tactics.
Dependency Poisoning Evolves
While build infrastructure attacks surged, dependency poisoning remained a critical vector in 2025. Attackers published malicious versions of popular build packages that executed reconnaissance scripts during installation. These scripts harvested tokens, inspected environments, and in some cases targeted locally hosted AI systems.
In parallel, attackers used phishing to compromise trusted maintainer accounts, allowing them to append malicious code to legitimate package updates. As the updates originated from verified accounts and trusted repositories, they passed through normal review channels undetected.
Malicious code inherits the trust of the source that delivers it is now one of the defining characteristics of modern supply chain compromise. When dependencies, runners, and build jobs are all trusted by default, attackers only need to compromise one link in the chain to gain access to the entire pipeline.
Why Traditional Detection Falls Short
The core difficulty in defending CI/CD infrastructure is that standard build activity inherently resembles malicious behavior. Compiling binaries, downloading packages, invoking scripts, opening network connections, and moving artifacts are normal actions in a build environment. These same actions are also hallmarks of compromise. That overlap creates a blind spot. If a malicious job executes under a valid service account on a trusted runner, the behavior may appear legitimate unless the account performs actions that clearly deviate from its role.
This means traditional detection models based on signatures or isolated indicators are insufficient. Defenders need visibility into context – who created the job, what changed, where the runner was registered, what secrets were accessed, and whether the workflow deviates from expected patterns. The challenge is no longer identifying malware alone. It is verifying the integrity of every automated action across the pipeline.
Moving From Trust to Continuous Verification
The solution to CI/CD subversion is removing implicit trust from the automation process. Every build runner, dependency, script, and service identity should be continuously verified. Security teams need to know when new runners are registered, when build configurations change unexpectedly, when secrets are introduced into workflows, and when jobs exhibit suspicious runtime behavior.
This starts with strong dependency integrity controls such as Software Bills of Materials (SBOMs) to detect unauthorized package changes. It extends to secrets hygiene practices that identify exposed credentials in repositories and pipeline configurations.
Build runners should be treated as high-value systems, monitored for suspicious child processes, credential access attempts, reverse tunnels, and persistence mechanisms. Unauthorized registrations or unusual runner names should trigger immediate investigation.
Equally important is behavioral monitoring for build jobs themselves. New or modified pipelines created by service accounts, jobs interacting with unfamiliar repositories, or workflows that establish network tunnels should all be treated as potential indicators of compromise. The objective is to ensure that trust is earned continuously, not granted automatically.
Conclusion | The Future of Pipeline Defense
CI/CD pipelines have become one of the most strategically valuable targets in enterprise environments. They sit at the intersection of source code, secrets, automation, and deployment. A compromise at this layer gives attackers privileged access to the entire software delivery chain. The attacks that continue to make news headlines show that adversaries understand this well. They are exploiting build infrastructure, abusing automation workflows, hijacking developer trust, and embedding themselves directly into the software lifecycle.
For defenders, this means the security model must evolve. Protecting the pipeline requires treating automation infrastructure as critical security infrastructure, applying runtime protection to build agents, verifying the integrity of dependencies, and continuously monitoring every workflow for signs of abuse. The era of implicit trust in CI/CD is over. The organizations that adapt will be the ones that recognize a fundamental truth: In modern software delivery, the pipeline is part of the perimeter – and attackers are already inside it.
Third-Party Trademark Disclaimer:
All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.
