Open-source attacks move through normal development workflows
Software development relies on a steady flow of third-party code, automated updates, and fast release cycles. That environment has made the software supply chain a routine point of entry for attackers, with malicious activity blending into normal build and deployment processes. A recent ReversingLabs study documents how these conditions played out across open source ecosystems during 2025, with attackers leaning on scale, trust, and automation to spread malware and harvest credentials.
Share of 2025 open-source malware detections by package manager (Source: ReversingLabs)
npm becomes a primary distribution channel
npm stood out as the dominant delivery channel for open source malware. The registry accounted for the large majority of detected malicious packages during the year. Many campaigns targeted widely used libraries, turning routine dependency updates into delivery mechanisms for malware. In several cases, attackers compromised maintainer accounts and published tainted updates that spread quickly into downstream projects through automated tooling.
One of the most disruptive examples involved the Shai-hulud worm, a self-propagating threat that operated entirely inside the registry. Using stolen credentials, it injected malicious code into hundreds of packages and exposed tens of thousands of downstream repositories. The activity showed how registry-native malware could move without relying on external infrastructure, making detection and containment harder during normal development operations.
Automation amplifies compromise
Dependency automation played a central role in widening the blast radius of several incidents. Tools designed to keep projects current routinely pulled malicious updates once upstream packages were compromised. Automated pull requests introduced tainted dependencies into otherwise unrelated projects, expanding access to credentials and development environments without direct interaction from attackers.
Tomislav Peričin, CTO at ReversingLabs, told Help Net Security that this pattern highlights how much trust development ecosystems place in upstream controls and platform governance. “If you don’t know which packages you’re building software with, the content of your build pipeline, then someone else will figure it out and use that knowledge against you,” he said.
Python and .NET show different trajectories
Other ecosystems showed different trends. Malware detected in the Python Package Index declined significantly over the same period, and activity in the NuGet ecosystem dropped even further. These declines coincided with platform-level changes such as stronger account protections and publishing controls, which raised the cost of account takeover and package injection.
Attackers shifted attention toward ecosystems and tooling with lighter controls or newer governance models. Smaller repositories and developer tooling marketplaces attracted campaigns that hid malicious files inside dependency folders or abused naming conventions to impersonate dormant projects.
Peričin said newer and smaller platforms can reduce their exposure by applying lessons learned elsewhere. “They should learn from the mistakes and corrections taken by established platforms like npm, PyPI, and others,” he said. “That includes strengthening access controls such as 2FA for developer and maintainer accounts, deprecating legacy authentication methods, limiting token lifetimes, and establishing protocols that limit the impact of package compromises, including quarantine mechanisms.” He added that internal security teams and monitoring for early indicators of compromise play a key role in preventing small issues from turning into large-scale incidents.
Secrets exposure remains routine
Beyond malware, exposed developer secrets continued to accumulate across repositories. API keys, access tokens, and private keys appeared frequently in published packages, often tied to cloud services and collaboration platforms. The volume of exposed secrets increased across most ecosystems, feeding follow-on attacks and enabling lateral movement once malicious code reached a build environment.
The bulk of leaked secrets traced back to a long tail of smaller services rather than a single dominant provider. That pattern reflected routine development practices, where credentials are embedded temporarily and then published unintentionally as part of normal workflows.
AI tooling enters the supply chain
Machine learning platforms and AI-focused repositories also emerged as attractive targets. Model files, plugins, and development utilities provided new places to hide executable code. In several campaigns, attackers embedded malicious payloads inside model artifacts that developers treated as data rather than software.
AI-related tooling also introduced new trust assumptions into build pipelines. Unsanctioned use of external models, plugins, and automation expanded the supply chain beyond traditional package managers, adding layers that security teams rarely inspect during routine operations.
The same volume dynamics are also affecting vulnerability management. Peričin said development teams need a more disciplined way to handle AI-generated vulnerability reports. “AI-generated reports should first be verified to determine whether the flaw is reproducible,” he said. “Given the volume, that often requires more automation than teams have traditionally used for human-generated reports.”
Once verified, Peričin said confirmed findings should be prioritized based on severity, likelihood of exploitation, and potential impact. “That means understanding whether the issue is remotely exploitable, what kind of disruption or exposure it could cause, and how the affected software fits into the larger dependency chain,” he said. Software bills of materials play a central role in that process by providing visibility into where and how vulnerable components are used. He added that teams should also consider whether mitigations exist that reduce risk even before a formal fix is available.
Legacy software stays in play
Open source activity unfolded alongside continued exploitation of long-lived commercial software and network infrastructure. State-aligned actors focused on unpatched devices and edge systems, using known vulnerabilities to establish persistent access. Signed updates and vendor-provided binaries remained trusted inputs in many environments, reinforcing the role of implicit trust across both open source and proprietary supply chains.
A crowded and persistent attack surface
By the end of the year, supply chain attacks appeared as recurring background activity woven into daily development processes. Malware, secrets exposure, and compromised automation all operated within expected workflows, relying on speed and scale.
The picture that emerges is one of a busy and contested development ecosystem. Attackers worked through shared infrastructure, trusted updates, and routine automation. Defenders, in turn, faced the challenge of inspecting software components that arrive through legitimate channels and carry the appearance of ordinary maintenance.