Organisations rely daily on open-source libraries, package managers, CI/CD pipelines, cloud platforms, development tools, and external services to accelerate the creation of applications and digital services. In this context, trust is essential to ensure innovation, agility, and scalability but it has also become part of the attack surface.

In recent months, software supply chain attacks have once again gained prominence. The logic is simple: rather than compromising an organisation directly, attackers exploit components, accounts, or processes already used and considered legitimate by thousands of companies. When that element is installed, updated, or executed, the attack enters through the very same channel normally used to distribute trusted software.

This type of attack can take different forms: publishing malicious package versions, compromising maintainer accounts, abusing CI/CD pipelines, exposing tokens, or altering low-visibility transitive dependencies. For those installing the package, everything may appear perfectly normal. The name is familiar, the source seems legitimate, and the update even follows standard versioning conventions.

Recent incidents across the ecosystem have shown precisely how this reality has evolved. In some cases, malicious package versions were distributed through seemingly legitimate accounts or processes. In others, the primary objective was to steal credentials from developer workstations and CI/CD environments, enabling attackers to spread further into repositories, packages, or cloud services.

The critical point is that the risk no longer lies solely in internally developed code. It also exists in imported dependencies, automated processes, and the credentials used to build, test, and publish software. A barely visible transitive dependency, an overly permissive token, or an insufficiently isolated runner can turn a trusted tool into an attack vector.

The consequences can be significant: credential theft, source code exposure, unauthorised access to cloud environments, distribution of tampered software, delivery disruptions, and reputational damage. For this reason, software supply chain security is no longer merely a technical issue. It is now a matter of operational resilience, governance, and digital trust.

The answer is not to abandon open source or slow down automation, but rather to manage trust more effectively: understanding what is being used, controlling how it is updated, protecting those who can publish or automate, and responding quickly when a trusted component is compromised.

In an increasingly interconnected ecosystem, security begins long before code reaches production.

Some measures can help reduce this risk:

• Map all dependencies in use, including transitive dependencies;
• Implement SBOMs and Software Composition Analysis (SCA) tools;
• Avoid automatically using “latest” versions in critical environments;
• Use lockfiles to ensure more predictable and reproducible builds;
• Apply version pinning where appropriate, while still ensuring controlled updates;
• Consider minimum release age policies or dependency cooldown periods before installing newly published versions;
• Strengthen MFA for accounts on GitHub, npm, PyPI, and cloud platforms;
• Ensure regular rotation and least-privilege access for tokens and secrets;
• Treat CI/CD pipelines and runners as critical security assets;
• Regularly validate logs, builds, and publishing processes;
• Prepare dedicated incident response procedures for supply chain attacks