Your IDP Is Your Supply Chain Defence

At 00:21 UTC on March 31, a new version of axios — the HTTP client library used by 174,000 packages and downloaded 101 million times a week — was published to npm. Version 1.14.1 looked routine. It was not.

A compromised maintainer account published the release directly, bypassing the project's normal CI/CD pipeline. The legitimate 1.14.0 release had used GitHub Actions with cryptographic publishing verification. The attacker skipped all of that and published straight from the hijacked account. The malicious version included a dependency called plain-crypto-js, which ran an install script that downloaded malware onto the build machine. That malware gave the attacker remote access: file browsing, command execution, and a persistent callback to their server every 60 seconds.

Google Threat Intelligence attributed the attack to a North Korean group designated UNC1069. Security firm Huntress confirmed 135 endpoints contacted the attacker's server during the three-hour window before npm pulled the package. Elastic Security Labs found a 3% execution rate across affected environments — meaning in most cases, the malicious code reached machines but something in the build or runtime environment prevented full execution.

Socket, a supply chain security monitoring service, detected the malware within six minutes of publication. npm removed the package roughly three hours later. For the organisations that pulled axios during that window, three hours was all it took.

Why this keeps happening

The axios compromise is not an anomaly. It is a recurring pattern in software supply chain attacks, and the pattern has been consistent for nearly a decade.

In 2018, the event-stream package was compromised through a social engineering handover — a new maintainer injected code targeting a cryptocurrency wallet. In 2021, ua-parser-js, with 8 million weekly downloads, was hijacked to install cryptominers. In 2022, the maintainer of colors.js and faker.js deliberately corrupted his own packages in protest, breaking thousands of builds. The same year, the node-ipc package was weaponised with code targeting Russian IP addresses during the Ukraine war. In 2024, the xz-utils backdoor showed this pattern extending beyond npm into core Linux infrastructure, with a multi-year social engineering campaign to gain maintainer trust.

Sonatype's 2026 report counted 454,648 malicious packages published to open source registries in 2025 alone — a 75% increase year over year. Cybersecurity Ventures estimated the global cost of software supply chain attacks at $60 billion in 2025, projected to reach $138 billion by 2031.

The structural problem is straightforward. Public package registries are centralised, open-publish systems. Anyone with an account can publish. Packages pull in other packages transitively — your application may depend on hundreds of libraries you never explicitly chose. There is no verification layer between the public registry and your build system unless you build one.

This is not a flaw in npm specifically. It is the architecture of how open source distribution works across every language ecosystem. The axios incident exploited it. The next incident will too.

What your IDP should do

An Internal Developer Platform that takes supply chain security seriously needs four capabilities. None of them require commercial tooling. All of them require deliberate engineering.

Package registry as proxy

The single most effective supply chain defence is not running builds directly against public registries. A self-hosted package registry that proxies npm, PyPI, Maven Central, and other upstream sources gives you a cache of known-good package versions and a control point during incidents.

GitLab Community Edition includes a package registry that supports npm, PyPI, Maven, NuGet, and several other formats — at no licence cost. When configured as a proxy, it caches packages on first download and serves subsequent requests from the local cache.

During the axios incident, organisations with a proxying registry had options. They could freeze their registry to prevent new versions from being pulled. They could audit exactly which projects had downloaded the compromised version. They could replace the cached malicious version with the known-good 1.14.0 and resume builds — all before npm completed their own cleanup.

Organisations pulling directly from npm had one option: wait.

CI-enforced defences

The axios attack vector was an install script — code that runs automatically when npm installs a package. This is a known and well-documented attack surface. The defence is a single CI pipeline flag: --ignore-scripts.

Running npm install --ignore-scripts (or the equivalent yarn install --ignore-scripts) disables all lifecycle scripts during installation. It blocks the exact mechanism the axios malware used. Most applications work fine without install scripts. The ones that don't — typically packages with native binary compilation — need explicit exceptions, which forces you to enumerate and review the packages that have this elevated privilege.

Beyond script blocking, your CI pipeline should enforce lockfile integrity. Every build should verify that the installed dependency tree matches the committed lockfile exactly. If someone updates a dependency without updating the lockfile, the build should fail. This catches both supply chain attacks and accidental dependency drift.

Signature verification is the next layer. npm now supports package provenance — cryptographic attestation that a package was built by a specific CI system from a specific source repository. The legitimate axios 1.14.0 used this. The malicious 1.14.1 did not, because it was published directly from a compromised account rather than through CI. Verifying provenance in your pipeline would have flagged this discrepancy automatically.

Dependency scanning and SBOM generation

You need to know what you depend on, whether any of it has known vulnerabilities, and you need that information in a machine-readable format.

Three open source tools handle this:

• Trivy (Aqua Security, Apache 2.0 licence) scans container images, filesystems, and Git repositories for known vulnerabilities. It covers OS packages, language-specific dependencies, and infrastructure-as-code misconfigurations.
• Syft (Anchore, Apache 2.0 licence) generates Software Bills of Materials in standard formats (SPDX, CycloneDX) from container images and filesystems.
• osv-scanner (Google, Apache 2.0 licence) checks dependencies against the OSV database — the largest aggregated vulnerability database, covering multiple ecosystems.

These are not hobbyist tools. AWS uses Trivy in several internal workflows. Google maintains osv-scanner and the OSV database behind it. They are production-grade and free.

One important caveat: 65% of open source vulnerabilities lack a severity score in the National Vulnerability Database, with a median 41-day lag between disclosure and scoring. Tools that rely solely on NVD miss a significant portion of the risk. osv-scanner uses the broader OSV database precisely because of this coverage gap.

GitLab Ultimate includes native dependency scanning and SBOM features, but GitLab CE combined with these three open source tools achieves the same outcome at zero licence cost. The tools run as CI pipeline stages and produce artefacts that your registry can store alongside your build output.

Impact assessment through your service catalogue

Knowing that axios is compromised is step one. Knowing which of your services use axios, who owns those services, which ones are customer-facing, and which ones run in production — that is step two, and it is where most organisations fumble during an incident.

Backstage, configured as your service catalogue, makes this queryable. When a vulnerability is disclosed, you need to answer: "which services are affected and what is the blast radius?" A well-maintained catalogue with dependency metadata lets you answer that question in minutes rather than hours.

The Backstage SBOM plugin can aggregate Software Bills of Materials across your entire service catalogue, making organisation-wide dependency queries possible. "Show me every service that depends on axios" becomes a catalogue query rather than a Slack thread asking team leads to check their package.json files.

This is the difference between incident response and incident archaeology. One happens in real time. The other happens over the next week.

The regulatory floor

For European organisations, supply chain security is no longer a best practice recommendation. It is a legal obligation.

NIS2 Article 21(2)(d) explicitly requires "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." The directive's first compliance audits begin June 30, 2026. Penalties for non-compliance reach EUR 10 million or 2% of global annual turnover, whichever is higher.

The Cyber Resilience Act adds another layer. From September 11, 2026, products with digital elements sold in the EU must comply with SBOM reporting obligations. If your software includes open source dependencies — and it does — you need to produce and maintain Software Bills of Materials as a regulatory requirement.

These are not abstract future risks. The NIS2 audit deadline is less than three months away. Organisations that cannot demonstrate supply chain security controls — a registry policy, CI-enforced scanning, SBOM generation, and an incident response process for compromised dependencies — will have a gap in their compliance posture that auditors are specifically trained to find.

The sovereignty argument

There is a sovereignty dimension to this that goes beyond compliance.

The npm registry is a centralised system operated by GitHub, which is owned by Microsoft, which is a US-headquartered corporation subject to US jurisdiction. Every npm install in your CI pipeline is a runtime dependency on that system. When npm is slow, your builds are slow. When npm is compromised, your builds are compromised. When npm decides to pull a package, your builds break.

A self-hosted package registry on European infrastructure is a sovereignty boundary. It decouples your build pipeline from a US-operated centralised system. This is not a theoretical concern — it is the concrete difference between being able to freeze your registry at 3 AM when a compromise is reported and waiting for a US-based company to complete their incident response process on US business hours.

The same logic applies to your vulnerability databases. osv-scanner can be configured with a local mirror of the OSV database. Trivy can run with a local vulnerability database. Your scanning infrastructure does not need to phone home to US-operated services during every build.

What this requires

Honesty about effort: this is not free.

Building the supply chain hardening layer — proxying registry, CI pipeline defences, scanning toolchain, SBOM generation, and Backstage integration for impact assessment — takes 6 to 11 weeks of platform engineering time for an organisation starting from a standard GitLab and Kubernetes setup. Less if GitLab's package registry and Backstage are already deployed.

The investment is roughly EUR 43,000 to 80,000 in engineering effort, depending on the complexity of your existing CI pipeline and the number of language ecosystems you need to cover.

The return is not measured in cost savings. It is measured in incident response time. When the next axios happens — and it will — the question is whether your platform team can contain it in minutes or whether you spend the next 48 hours in a war room trying to figure out which services are affected.

Infrastructure versus tooling

The axios incident is a useful litmus test.

An Internal Developer Platform that includes supply chain defence — a proxying registry, CI-enforced protections, automated scanning, and a service catalogue that can answer "what is affected" — is infrastructure. It absorbs the incident. It gives your team options. It contains the blast radius.

A collection of CI/CD scripts that happen to run some security checks is tooling. It might catch the problem. It might not. When it doesn't, you discover exactly how much of your supply chain defence was held together by convention rather than enforcement.

The 135 organisations that contacted the attacker's server during the axios window did not lack security awareness. They lacked a control point between the public registry and their build systems. That control point is not a product you buy. It is a platform capability you build — and it is the part of your IDP that earns its keep on the worst days.

---

This article is published on Clouds of Europe, a practitioner community building European cloud independence. We assess infrastructure patterns based on real production experience — no vendor sponsorship, no product agenda.