Open source supply-chain attacks: why trusted software can become a security risk

Modern software is built on open source. That gives organisations speed, flexibility and access to high-quality components, but it also means our applications inherit risk from code, maintainers, package registries and build pipelines outside our direct control. Recent attacks show that adversaries are no longer only looking for vulnerabilities in our applications; they are targeting the software supply chain that delivers those applications.

A major example was the XZ Utils backdoor, disclosed in 2024. XZ Utils is a widely used Linux compression library. Malicious code was inserted into upstream versions of the project and was designed to interfere with SSH authentication on affected Linux systems. The attack was particularly concerning because it was not a simple typo-squatting package or obvious malware upload. It involved a long-term attempt to gain trust within an open source project, contribute changes, influence maintainership and eventually introduce a backdoor into a component used by many Linux distributions.

Another recent example involved compromised GitHub Actions. In 2025, the widely used tj-actions/changed-files action was compromised. Attackers modified release tags so that workflows using the action could execute malicious code. The result was exposure of sensitive CI/CD secrets, including access tokens, private keys and cloud credentials. This highlights a key issue for development teams: build pipelines often have powerful permissions, and third-party automation components can become an attack path into the organisation.

Package ecosystems such as npm and PyPI have also seen repeated malicious package campaigns. These attacks commonly use compromised maintainer accounts, typo-squatting, dependency confusion, malicious install scripts or trojanised versions of legitimate packages. Once installed by a developer or CI/CD runner, the package may steal environment variables, cloud keys, GitHub tokens or other credentials. Some campaigns have been self-propagating, using stolen credentials to publish further malicious packages or modify repositories.

The common theme is trust. Developers trust package names. Build systems trust pinned actions and dependencies. Organisations trust that open source components are maintained securely. Attackers exploit that trust by inserting themselves into the process before software reaches production.

Management should view this as an operational and governance risk, not just a developer issue. A single compromised dependency can affect multiple systems, customers and environments. The impact may include credential theft, unauthorised access, data exposure, service disruption, incident response costs and reputational damage.

Practical mitigations are available. Organisations should maintain a software bill of materials so they know which open source components are in use and where. Dependencies should be pinned to known-good versions, monitored for compromise, and updated through controlled review rather than blindly accepting automatic updates. CI/CD workflows should use least-privilege permissions, short-lived credentials, protected secrets and isolated runners. Third-party GitHub Actions should be pinned to immutable commit hashes rather than mutable version tags. Package install scripts should be restricted where possible, especially in automated build environments.

Developers should also validate package provenance, check maintainer and repository history, use dependency scanning, and treat unexpected package behaviour—such as network calls during installation—as suspicious. For internally developed software, signed builds, reproducible build processes, provenance attestations and frameworks such as SLSA can help prove that released artifacts came from trusted source code and trusted build systems.

Open source remains essential and valuable. The lesson from these attacks is not to avoid open source, but to manage it with the same discipline applied to any other critical supplier. Organisations that understand their dependencies, secure their build pipelines and reduce implicit trust will be far better placed to withstand the next supply-chain attack.