Software supply chain attacks: check your dependencies

Software supply chain attacks: check your dependencies
Attackers are compromising open source packages to spread malware. Cyber defenders are asked to review dependencies to reduce risks
sarayut Thaneerat via Getty Images
Modern software development has transformed how software is created, shared and reused – but recent attacks on these tools highlight the rapidly growing risks of using modern software ecosystems. Attackers are compromising open source packages at scale to spread malware in ways that can be difficult to detect and can do extensive damage.
This blog, aimed at cyber security professionals, exposes the insidious nature of recent attacks, underlining the growing threat from software supply chains, and how attackers are able to exploit them. We explain how organisations can check if they have been affected by such a supply chain attack, and recommend actions to take to mitigate compromise and prevent further spread.
This blog helps cyber defenders to better understand, mitigate and more effectively respond to the new open source software risks.
Software supply chain attacks are evolving
Widely used platforms and ecosystems enable developers to develop, collaborate and re-use software at a global scale. This allows teams to build software faster and reuse widely trusted components, that are secure, reliable and maintainable. But these ecosystems also create an increasingly complex set of dependencies. A single application may rely on a large number of third-party packages – including libraries, frameworks, snippets, software development kits, and others. Some of these will be less trustworthy than others.
As an example, Node.js, Rust and Python are unusually exposed as they have minimal standard libraries. This increases use of third-party dependencies, and delegation of basic functionalities, and results in a heavy reliance on external registries.
Moreover, many of these components are retrieved automatically through continuous integration and continuous delivery (CI/CD) pipelines, often without human intervention.
It is this combination of automation, trust and scale which means that malicious code introduced into a single package can spread rapidly across many organisations and services before detection.
Recent attacks show a changing and growing threat
Recent attacks affecting widely used package managers such as npm and PyPI demonstrate how attackers have focused on maliciously exploiting the complex modern software supply chain.
For example, in the May 2026 Mini Shai-hulud supply chain attack, the developer ecosystem – including CI/CD systems, package registries and developer tooling – was used to propagate malicious software. Damage from this attack was limited thanks to the speed at which it was discovered, but subsequent similar supply chain attacks have gone undetected for longer and spread more widely.
How the modern software development ecosystem can be exploited
The following are features of the modern software ecosystem that attackers are successfully exploiting at scale:
Targeting developer environments
Developer devices are usually less tightly controlled than managed corporate devices, which further increases the likelihood of compromise and credential theft of shared code or package registries.
Rapid propagation across ecosystems
A single malicious package may spread quickly across downstream software products and services. The impact of compromising a lesser known, but critical, software component can have significant and far reaching impact for many organisations and systems. This complexity is especially visible in Node.js, as its highly modular packages depend on many smaller components. A single dependency may introduce a large number of transitive dependencies.
Abuse of automation
Recent attacks have exploited the considerable implicit trust in CI/CD and automation pipelines. The automation of updates, installation, and execution of scripts and packages allows attackers to execute malicious code. For example, Node.js and Python support scripts that execute on installation, and allow a malicious package to be run immediately. Without human intervention or approval, the code can simply propagate.
Open publishing models increase exposure
Anyone can upload a package, and maintainers are often implicitly trusted. While there are security controls for maintainer registry accounts, these are not currently enforced by all registry providers, for example, in the absence of globally enforced multi-factor authentication (MFA).
Software ecosystems are taking action to address some of these issues, but organisations also need to take action to identify and manage the risks that arise from these attacks.
Common attacker techniques
You should be aware of the following methods seen in recent attacks:
Maintainer account compromise
- Attackers steal credentials or tokens that allow a malicious actor to update a trusted package.
Abandoned package takeover
- Attackers take over ownership of expired domains connected to package maintainers, or otherwise transfer ownership of a previously legitimate package.
Typosquatting
- Publishing packages using similar names or misspelling popular legitimate packages in the hope they are installed by mistake.
Self-propagation
- Using the credentials or tokens stolen from a previous attack to access or modify additional packages.
How to identify if you’ve been affected
You should take the following steps to assess exposure:
Review dependencies
- Audit recent package updates and version changes
- Identify newly introduced or unexpected dependencies
Monitor for unusual behaviour in:
- CI/CD activity
- network traffic
- credential use
Scan for known issues
- Use dependency scanning tools to detect compromised packages
Check developer and registry accounts
- Look for unauthorised access or token use
Maintaining a clear inventory of all software dependencies is critical – and we recommend reducing the size and complexity of dependencies wherever possible. This inventory can take whichever format suits the processes and culture of the organisation, such as a software bill of materials (SBOM).
Immediate actions to reduce risk
If you suspect you have been affected – or as a precaution – you should act quickly to reduce risk. Immediate actions include the following:
- Pause automatic dependency updates where compromise may be present.
- Review and approve new updates, dependencies or versions manually.
- Rotate exposed or potentially exposed credentials.
- Enforce MFA for developer and package registry accounts.
- Use private or trusted registries where appropriate.
Strengthening your development approach
These attacks highlight the need to revisit how dependencies are introduced and managed, as part of a secure development lifecycle (SDLC). Whilst Node.js, Python and Rust are considered higher risk for these attacks, it’s important to be aware that other languages, tools, and package repositories are also at risk.
Use the Software Security Code of Practice
We recommend you refer to the Software Security Code of Practice which provides a foundation for strengthening software development and supply chain management in organisations.
In particular, you should:
- Review how dependencies are introduced and updated.
- Avoid automatically adopting new dependency versions without review.
- Find a balance between deploying patches quickly and updating dependencies slowly, to minimise the impact of compromise.
- Ensure deployments occur through controlled CI/CD pipelines rather than developer devices.
- Store sensitive credentials securely, avoiding exposure on developer workstations.
Recent attacks have also targeted API keys and tokens used by developer tooling. If compromise is suspected, these credentials should be rotated immediately.
In its SSCoP implementation guidance, the NCSC provides useful advice on understanding and assessing risks associated with third-party software dependencies. It will be updated shortly to include advice relevant to countering the new attack scenarios outlined here.
Jack F
National Resilience Officer
Share and print this article
Written by
National Resilience Officer