Open source dependency attacks are on the rise. This makes your CI/CD pipelines one of the most vulnerable places in product development.
Many modern applications are built using open source components.
Attacks on these have recently risen, making the CI/CD pipelines a breeding ground for breaches and security issues. Many recent attacks share similarities, and many of them are worrisome. From self-replication to evidence of large language model scaling, your pipeline needs to be secured.
What is Open Source Dependency?
Open source software is code that anyone can access, inspect, and modify. It is distributed with a license that allows people to use it as they see fit. As a result, open source modules and frameworks are integrated into many applications, meaning developers don’t have to start them from scratch but can borrow and modify what they need. You can find their use in everything from small apps to global-scale projects.
The many benefits, such as cost-effectiveness and speed, are vast. Yet they also come with drawbacks. Tracing vulnerabilities and exploitations in third-party code can be hard, which means they have a range of issues with regard to security.
CI/CD Pipelines
When you make software changes and deploy or update new products, your CI and CD pipelines are vital. Essentially, they are the practice grounds for new software products. They allow dependencies and other issues to be spotted much earlier in the lifecycle.
Yet a major software security company has recently found that these pipelines are currently where attackers are utilising repository and CI/CD features, through open source packages. The detection of these rose by 73% in 2025, through techniques such as the manipulation of GitHub and similar packages. It has been evident in cryptocurrency and AI pipelines, where scaling up quickly and lax controls have made a perfect storm for those who want to exploit systems.
A recent change has been noticed as attackers have moved from small open source projects to large, well-maintained open source packages. This was evident in several attacks, such as Shai-Hulud, which blended automated propagation and private code repositories. Hidden in the npm repository, it was part of an outbreak on 25,000 GitHub repositories. Keeping up to date with news like this, often broken on outlets such as software supply chain security news, is essential for businesses that want to understand current threats.
The Core Risks in Open Core Supply Chains
There are two main areas of concern in open core supply chains. Which is the most important to address is still up for discussion. First of all, there are those that remain embedded in dependencies that have not been maintained or updated. If these items are still in use and have been reported, the audience for their vulnerabilities is huge, and this increases the risk of attack.
A further risk comes from code placed in the repository supply chain. This malicious code usually arrives in one of three ways: Compromised packages, which are modules already infected, registering mistypes of popular domain names, which is known as typosquatting, or a process where automated tracking managers are tricked into downloading fraudulent packages instead of legitimate ones, known as a dependency confusion attack.
Arguments go back and forth on which is most dangerous. Those that are embedded can easily be detected, with fixes and changes readily available. Yet they pose issues because of systematic use and scale across sectors. In contrast, those that have been placed in the repository supply chains can be hard to detect, allowing them to move and infect at scale.
The Major New Changes
What has made these even more troublesome are recent changes that many large attacks have shared. These were largely not evident in previous supply chain attacks, and definitely not in a single malware attack. The first is the ability to self-replicate, moving through registries without having any involvement from external operators.
A second issue is that they often attack the toolchain. These devices, used to build and deliver software, can damage the security tools inherent in the CI/CD pipeline. Add to this the fact that some have shown signs of being generated by large language models, and this brings AI into the craft, which can generate this at scale.
Behind this, the pattern is simple. Firstly, a large maintainer is identified. Their npm or credentials for GitHub are gained, often via phishing. A new version containing malicious code is then pushed out within 24 hours to new pipelines.
How to tackle this is still in dispute, and it seems the problem is going to get worse quite rapidly. It is not a case of being aware, as this is like getting toothpaste back in the tube. It is about controlling who can get into these pipelines. Scanners and visibility can help, but it must also come down to control of the intake path.
