From XZ to NPM: Why Software Supply Chain Attacks Are Succeeding and What Security Teams Are Missing

I meet with a lot of different development and security teams. From startups and greenfield skunkworks to large complex, critical infrastructure projects and ASX listed companies. One thing they all have in common is the vast use of open-source tools, libraries, and frameworks. This is great to see, as I am a huge fan of open source, but this comes at a risk.

Complex software supply chain attacks, like the recent attack on the NPM ecosystem and the sophisticated widely used XZ Utils backdoor, can find their way into the cracks of your environment. We’re seeing security teams completely miss these areas, and this is due to many reasons, but one main one is that there is often no person that sits between security and development teams in the organisation. Developers are often left to develop systems completely detached from security requirements, creating a dangerous gap where supply chain compromises can go undetected for months or even years.

The Visibility Problem

What makes this particularly concerning is that many organisations have limited to no visibility into their development environments. Security teams have invested heavily in production only monitoring, vulnerability scanning, and incident response capabilities, but development and non-production environments often operate in a shadow zone. We regularly encounter scenarios where development teams are spinning up cloud resources in personal accounts, using unapproved tooling and version control systems, or working in environments that lack basic security controls like logging or network segmentation. When a compromised upstream dependency makes it into one of these development environments, there’s often no mechanism to detect it.

In theory, development, testing, and production environments should be completely isolated from one another. In practice, we frequently see non-production services communicating directly with production databases, shared IAM roles across environments, and development pipelines that have write access to production infrastructure with no protection on what triggers them to run. This means that a supply chain attack targeting a development dependency doesn’t need to make it all the way to production code to cause damage. A compromised package in a development environment can become a backdoor into production systems if that environment has any connectivity to production resources.

The AI Democratisation Challenge

We are also seeing the democratisation of development through AI coding assistants. Tools like GitHub Copilot, ChatGPT, Cursor and Claude have enabled and accelerated the ability to write code for people who previously wouldn’t have had the capability or bandwidth. This is genuinely exciting for innovation, but it’s also creating easily preventable security gaps at an unprecedented scale. We’re seeing proof of concepts take off and push for production releases quickly, with open API endpoints with no authentication. The storing of critical secrets in plaintext or committing them directly to source control. Junior developers are using AI to generate entire authentication systems without understanding OAuth flows or session management, leading to broken access controls.

Three Practical Steps

The good news is that addressing these gaps doesn’t require a complete security transformation or years of effort. Based on what we’ve seen work across hundreds of organisations; here are three practical steps you can use immediately.

1. Prioritise Proper Environment Segregation (and Rip the Bandaid Off)

Treat all environments with the same security rigour from an architecture perspective. Development and staging environments should have complete network isolation from production, separate IAM roles and service accounts, and their own identity boundaries. These gaps are easy targets for attackers behind supply chain attacks like Shai-Hulud, which specifically exploited poor environment segregation to move laterally from compromised development environments into production systems.

I know what you’re thinking: “We have too much technical debt,” or “The business won’t prioritise this,” or “It’ll take months to untangle.” Proper environment segregation is one of those foundational controls that’s surprisingly quick to implement when you commit to doing it, and the security value is immediate and substantial. The longer you wait, the more complex and expensive the remediation becomes. Start with network segmentation, then tackle IAM boundaries, and finally address any cross-environment dependencies. Most organisations can achieve meaningful segregation in weeks, not months.

2. Log Significantly More Than You Think You Need

Most organisations we work with can afford to log significantly more than they currently are. We regularly see non-production environments completely excluded from SIEM ingestion, despite these environments being potential entry points for attackers. Even more concerning is the lack of logging for critical security-relevant events from systems like GitHub, GitLab, CI/CD pipeline execution logs, cloud control plane activity, and container registry access.

Using the Shai-Hulud attack chain as an example, the attackers performed extensive discovery activities, listing repositories, checking authentication tokens, and cloning private repositories. Without complete logging across your development infrastructure, these reconnaissance activities would go completely undetected. These logs are gold for detecting supply chain compromises, insider threats, and lateral movement. Modern cloud logging and SIEM solutions have become more cost-effective, and the visibility you gain far outweighs the expense. If budget is genuinely constrained, at least ensure you’re logging authentication events, privileged access, and any cross-environment communication across all your environments.

3. Champion (or Hire) the Security-Development Bridge

This is perhaps the most critical recommendation. Champion or hire someone who wants to sit between security and development. This role, whether you call it DevSecOps Engineer, Security Engineer embedded with development, or Platform Security, is absolutely critical and often overlooked in favour of hiring more developers or traditional security analysts.

Many organisations already have this person hiding in plain sight. You know the one: that engineer who’s always asking about security implications in design reviews, who’s built half the internal tooling that everyone relies on, and who somehow understands both the OWASP Top 10 and your Kubernetes architecture. That’s your 10x engineer, and they’re probably underutilised because they’re stuck writing features instead of building security into your platform. Identify and empower them, or if you genuinely don’t have this person, hire for it.

But people alone aren’t enough, you also need to equip them properly. Security doesn’t slow down development cadence when it’s done and invested in properly. Once you have the right people, next is the right tooling. If you can afford it, invest in comprehensive platforms like Wiz that provide visibility across your entire cloud environment, from development through to production, that is easy to setup. If budget is tight, open-source tooling can provide significant value if you have the skillset to maintain and build it properly. Tools like Gitleaks or TruffleHog for secrets detection, Trivy or Grype for container scanning, and Renovate or Dependabot for software composition analysis can all be integrated into CI/CD pipelines. Don’t forget about Infrastructure as Code SAST tools like Checkov, tfsec, or Terrascan, which can catch misconfigurations like overly permissive security groups, publicly accessible storage buckets, or missing encryption before they’re deployed. The key is having someone who understands both the security requirements and the development workflow to implement these tools in a way that adds value rather than friction.

Moving Forward

Software supply chain security doesn’t have to be an overwhelming challenge. These attacks are succeeding for surprisingly simple reasons. Organisations have blind spots in their development environments, security and development teams struggle to communicate effectively with each other, and most organisations don’t actually know where they stand from a security perspective. The gap between security and development teams has created the perfect environment for compromised dependencies to slip through undetected and cause significant damage. Fix the communication problem, gain visibility, and suddenly these attacks become much harder to pull off.