From the recent Miasma malware packages that infiltrated Microsoft to the Axios compromise affecting one of the world’s most widely used JavaScript libraries, the headlines are becoming difficult to ignore. Organizations are struggling to keep pace with the speed and scale of modern software supply chain threats.

However, despite the growing frequency of these incidents, many continue to treat software supply chain security as a niche technical problem rather than a key part of their security perimeter. Recent warnings from CISA state that companies are still failing to address known open source and software supply chain vulnerabilities quickly enough.

Threat actors can now use AI to find flaws faster than ever before, and an attack that begins with a seemingly insignificant open-source package can cascade across platforms and users. Organizations need controls that operate at the same pace.

The root of the problem: Organizations underestimate their exposure

Modern software relies on thousands of open-source components and developer tools. In fact, 96 percent of commercial programs today include some code created or distributed for free by public-facing tech forums.

While these resources have transformed the speed of innovation, they’ve also introduced a level of complexity that many companies are unable to manage. Few security teams can accurately identify every component running in production, understand where those components originated, or determine how quickly they could respond if a critical vulnerability emerged tomorrow. The unfortunate truth is that, as a result, many attackers have a better understanding of an organisation’s software supply chain than the organization itself.

This lack of visibility creates opportunity. Attackers no longer have to break down the ‘front door’. They can look for the overlooked dependency or developer tool that everyone assumes is safe.

The attack strategy: The Trojan horse in the developer workflow

In these attacks, trust itself has become a weak point. The modern Trojan horse arrives in the form of a dependency update or compromised package. By the time malicious behavior is detected, the code has already spread rapidly through legitimate developer workflows and bypassed traditional security controls. At that point, it’s too late to patch: a compromised package or development workflow has provided access to hundreds or even thousands of high-value targets upstream.

Incidents like the recent Axios compromise have revealed how a small dependency change inside a highly trusted package can create outsized downstream risk. Within the past few months, a malicious package was found every six minutes, and trust abuse was the defining pattern. These campaigns were designed for persistence and reuse inside developer and CI/CD environments, collecting information they can use to pivot later.

The reality of the fight: Accelerated attacks, insufficient discovery time

Agentic systems are changing the economics of attacks, giving attackers visibility they never had before.

Threat actors can now use AI to automate parts of vulnerability discovery, correlate weaknesses across projects, and deploy exploits at unprecedented speed. Attacks that previously required significant expertise and time can now be facilitated and repeated with far less effort.

Meanwhile, software supply chain risk also now extends well beyond simple secrets exploitation. Tokens, CI credentials, IDE settings, and AI coding tools are all part of the attack surface, and organizations that treat these as separate problems will stay exposed.

The disadvantage: Technical debt is slowing down security teams

To make matters worse, defenders are still operating inside workflows built around manual prioritization, fragmented tooling, and patch cycles measured in days or weeks. They’re legacy systems designed for a different era: when organizations could reasonably expect to ‘patch their way out’ of a problem.

Today, malicious code can execute the moment a package is installed, so detecting it even minutes later will only confirm the damage has already happened. Security that relies on periodic reviews or post-disclosure response cycles is no longer sufficient.

Attackers aren’t operating on manual timelines, so defenders can’t afford to do so either.

The solution: why the UK needs a ‘shields up’ approach

Software supply chain security has become a national security challenge. Critical infrastructure providers, healthcare organisations, and government agencies all depend on software built from complex supply chains. The fact that recent Miasma activity reached users of platforms like Claude and Gemini shows how interconnected modern software ecosystems have become.

As open source consumption reaches unprecedented scale, registries are facing a dangerous rise in AI-driven demand, bot traffic, and registry abuse. In just the first quarter of 2026, open source malware increased by 21 percent.

The UK therefore needs a more coordinated ‘shields up’ approach to defending their software supply chains. Bodies such as the National Cyber Security Centre already play a vital role in issuing guidance and sharing intelligence, but the pace and scale of these attacks demand a broader shift in mindset. As the Greeks learned centuries ago, even the strongest army is useless against an unexpected threat.

The NCSC must drive attention to the severity of this issue for companies across the UK. However, true change is unrealistic if organisations don’t implement automation.

Organizations need systems capable of continuously identifying risk, enforcing policy automatically, and reducing exposure before weaknesses become active incidents. When a new vulnerability or malicious package is discovered, security teams need to understand where it exists, whether it is exploitable, who owns the affected application, and how quickly it can be fixed.

In short, automation is essential to give development teams a clear view of the battlefield and the speed and control they need to make better decisions before attackers do.

Attackers have already adapted to the realities of software development. They know the dependencies you trust and where your blind spots lie. Defenders need to understand their supply chain just as well before the next attack makes headlines.