3rd Party Risk Management
,
Governance & Risk Management
Continuous Integration Has Its Downsides

No complex computer program is an island. The rely on third-party libraries, a fact not lost on hackers who lately have realized how effective it is to compromise the repository rather than individual targets.
See Also: Securing Microsoft 365: A Live Breakdown of Modern Attack Paths
Numerous apps additionally rely on open-source projects, oftentimes distributed by npm, a package manager for the JavaScript programming language that’s owned by Microsoft’s GitHub. There’s also Python Package Index – aka PyPI – a Python programming language software repository.
Whenever updates get issued for these open-source code packages, many developers have their oftentimes now artificial intelligence-driven, continuous integration pipeline tools set to automatically merge the new code into any of their own code repositories that rely on it.
The problem: “Recent supply-chain attacks stayed live for hours. Automation tools silently merged their malware in minutes,” said cybersecurity firm GitGuardian earlier this month. While many organizations use software composition analysis tools, which scan for the presence of any code repositories with known flaws, new attacks take time to discover, only after which does updated vulnerability information get pushed to scanning tools.
Attackers last month attackers injected data-stealing malware into code repositories for LiteLLM and Axios. Further such attacks this week led to compromises of Xinference, Namastex.ai, Checkmarx KICS as well as Bitwarden CLI password vault software.
For any organization with developers who rely on third-party code libraries, “how do they have confidence?” in the code integrity when they pull the code into their own repository, and “can they delay?” for immediately integrated, updated code are the two questions they should ask, said Ollie Whitehouse, CTO of Britain’s National Cyber Security Center, a part of intelligence agency GCHQ.
“What we’re finding actually is these are detected quite quickly – detected in a matter of hours or days – and a lot of organizations don’t need to run within-minute updates,” Whitehouse told reporters this week, during the agency’s annual CyberUK conference, held this year in Glasgow, Scotland (see: Hacked Devices Are Gateways for Chinese Nation-State Hackers).
Attackers know they have a window of opportunity between when they inject malicious code into an open-source project’s code repository, and when it gets spotted and expunged (see: How AI Supply-Chain Monitor Spotted Unfolding Axios Attack).
In last month’s supply-chain attack against LiteLLM, a widely-used, open-source Python library that allows developers to connect applications to different AI model providers through a single interface, PyPI detected and removed the two malicious packages introduced by attackers within 46 minutes. But by that time, the malicious versions of the packages were already downloaded 47,000 times.
A complicating factor is that many repositories rely on other repositories. If attackers inject code into just one, they know it might travel far and wide, across software dependencies.
“I don’t think it should come as a surprise that adversaries have recognized: if you cannot compromise the organization that you want, often smaller organizations in their supply chain are comparatively easy and often they supply many organizations and so we’re seeing a lot more speculative kind of compromises in this space,” Whitehouse said.
Poisoned Package Chain
A threat actor going by “TeamPCP,” which specializes in supply-chain attacks against open-source software, poisoned on Wednesday a Docker image for KICS, an open-source tool developed by Checkmarx to scan infrastructure as code to detect misconfigurations and vulnerabilities before deployment, said researchers at Socket.
The trojanized image is designed to steal developer credentials, including GitHub credentials, which get relayed to attackers as well as used in an automatic “malicious GitHub Actions workflow,” they said. This workflow looks for GitHub repositories to which a user is allowed to push code, checks to see if it has valid stolen credentials for those repos, then runs through a process that pushes the worm to a repo, sends it the required credentials, then erases the signs of what it’s done.
The malicious code appears to be a new version of the self-replicating Shai-Hulud worm that’s been previous used to infect npm and GitHub projects, said researchers at Ox Security.
Thanks to the KICS attack, the attackers successfully subverted Bitwarden CLI, the command-line-interface version of the popular password vault software, which gets downloaded 70,000 times per week from npm.
Bitwarden said it counts 50,000 businesses and over 10 million users worldwide as users of its software.
The hijacked version of Bitwarden CLI resulted in the software downloading an obfuscated JavaScript payload designed to function as information-stealing malware. “Once deobfuscated, that payload reveals a broad credential theft operation focused on developer workstations and CI environments: GitHub and npm tokens, SSH material, shell history, AWS, GCP and Azure secrets, GitHub Actions secrets and AI tooling configuration files are all targeted,” said security researchers at JFrog.
“If @bitwarden/cli version 2026.4.0 was installed, responders should assume developer and cloud credentials exposed on that host are compromised,” JFrog said.
Ox Security said the worm that infected Bitwarden CLI appears to have infiltrated at least 277 other GitHub code repositories, infecting them too in a stealthy operation designed to encrypt data before exfiltrating it, as well as to use the GitHub service itself as a command-and-control server.
“The use of GitHub as a remote C2 server for data exfiltration is proving to be an effective technique for threat actors, as traffic to github.com is typically not flagged by security tools and cannot be traced back to a domain belonging to the threat actor,” the researchers said.
Flurry of Hits
Also this week: JFrog warned about attacks inserting backdoors into Xinference package versions 2.6.0, 2.6.1 and 2.6.2, adding code designed to steal secrets stored on Linux servers, cloud virtual machines, continuous integration runners and inference hosts used to train large language models. These include everything from SSH private and host keys and VPM infrastructure details to credentials for Git, Amazon Web Services, cryptocurrency wallets and more.
Separately, attackers poisoned packages developed by Namastex Labs, which creates Automagik open-source AI tools, by adding code designed to steal developers’ credentials, as well as automatically infecting other code repositories, Socket said.
For any organization that uses any of the packages compromised in these supply-chain attacks, “investigate for any exposure and rotate any potentially compromised credentials,” said Austin Larsen, principal threat analyst at Google Threat Intelligence Group, in a post to LinkedIn.
“As threat actors increasingly target developer tooling and CI/CD pipelines, supply-chain defense should be top of mind for defenders,” he said.
Unfortunately for defenders, attackers continue to innovate. “We have now also seen adversaries who are buying software components which were once legitimate and then turning them for malicious use – so, almost legitimate M&A within malicious supply-chain activity,” the NCSC’s Whitehouse told reporters at CyberUK.
“So it’s a deeply complex space, and I think it highlights, once again, the fragility of software development practices and supply chains more generally. We’re going have to prepare for more of it; there is no easy solution,” he said.
