Software supply chain attacks have moved from a recognised but secondary concern to a sustained operational threat over the past five years. The first four months of 2026 have continued the trajectory, with several significant incidents that deserve examination for the defensive lessons they offer.

This is a mid-year review of where the threat sits, what’s changed in attacker techniques, and where defensive practice has actually moved.

The attack surface keeps widening

The package ecosystem attacks - npm, PyPI, RubyGems, and the various language-specific package registries - have continued to be a high-volume threat surface. The volume of malicious package publications detected and removed by the registry operators in Q1 2026 was higher than the comparable period last year, continuing a trend that’s now several years old.

The specific techniques have evolved. Typosquatting and dependency confusion remain common, but they’ve been joined by more sophisticated approaches - compromise of established packages through maintainer account takeovers, the introduction of malicious code into legitimate packages by trusted contributors, and the exploitation of build pipeline weaknesses to inject code without modifying source repositories.

The maintainer compromise vector has been particularly significant. Several recent incidents have involved attackers obtaining maintainer credentials and pushing malicious updates to packages with substantial downstream user bases. The detection lag for these incidents has been variable - some were caught within hours, others ran for days before discovery.

Build pipeline attacks have become more common

The CI/CD pipeline as an attack surface has received more attention from sophisticated threat actors over the past 18 months. The reasoning is straightforward - compromise of a build environment can produce malicious binaries signed with legitimate signatures, distributed through legitimate channels, and consumed by downstream users with no obvious indicators of compromise.

Several of the year’s most consequential supply chain incidents have involved build pipeline compromise rather than source code compromise. The defensive implications are significant - source code review, even thorough source code review, doesn’t catch attacks that occur after the source has been written.

The build environment hardening practices that have emerged - reproducible builds, build provenance attestations, hardened build runners, restricted secret access from build environments - have matured significantly. The implementations across organisations vary widely. The companies that have invested in these practices are meaningfully better positioned than those that haven’t.

The SLSA framework and the SBOM-related guidance from CISA have continued to be useful reference points for organisations working through this. Implementation guidance has matured, and the tooling support is genuinely better than it was two years ago.

Open source maintainer burnout is a defensive issue

A theme that has surfaced more prominently in 2026 is the recognition that the security of widely-used open source software depends on the wellbeing and capacity of its maintainers, and that maintainer burnout is a defensive concern as well as a community concern.

Several recent incidents have involved circumstances where overworked or under-supported maintainers either accepted contributions they should have scrutinised more carefully, or transferred control of packages to less trusted parties because they didn’t have the capacity to continue maintaining them themselves. The XZ utils incident from 2024 remains the canonical example, but it’s not unique.

The funding and support models for critical open source maintenance have improved over the past few years - the Open Source Security Foundation’s work, the various corporate sponsorship programmes, and the increased recognition of maintainer security work as a legitimate engineering function within enterprise environments - but the gap between what’s needed and what’s resourced remains substantial.

For organisations consuming open source software, the practical implication is that the security posture of the projects you depend on matters and is something you should have visibility into. Several enterprise software composition analysis tools now include maintainer-health and project-health signals alongside the traditional vulnerability data.

SaaS supply chain has become a major theme

The SaaS layer of the supply chain has emerged as a significant area of concern through 2025 and into 2026. Compromises of widely-used SaaS providers, particularly those with deep integrations into customer environments through OAuth, API access, or webhook delivery, have produced some of the year’s largest incidents in terms of downstream impact.

The OAuth scope review work that several large enterprises have undertaken has identified concerning patterns - thousands of third-party integrations across enterprise environments, many with broader permissions than they need, many maintained by smaller vendors with weaker security postures than the enterprise’s own controls.

The defensive practice that’s emerging is more aggressive scope minimisation, periodic re-attestation of integration relationships, and centralised visibility into what third-party access exists across the environment. The tooling for this has improved but is still maturing.

AI in the supply chain conversation

A 2026-specific theme is the AI dimension of the supply chain conversation. Several aspects deserve attention.

First, AI coding assistants have become embedded in enterprise development workflows, and the AI vendors are themselves part of the supply chain. The training data, model behaviour, and update mechanisms of these tools matter for downstream security in ways that the conversation hasn’t fully caught up with.

Second, AI-generated code is entering codebases at significant volumes. The security review practices that worked for purely human-written code don’t always catch the specific failure modes of AI-generated code - including the tendency to confidently use vulnerable patterns or non-existent libraries (the “hallucinated dependency” problem that several recent attack campaigns have specifically targeted).

Third, the defensive applications of AI in supply chain security are real and improving. Behavioural analysis of package update patterns, anomaly detection on build artifacts, and intelligent triage of vulnerability data are all areas where AI-augmented tools are providing genuine value. Several specialist security AI providers working in the AI defence space have built useful capabilities here.

What’s working defensively

A few things are clearly working in supply chain defence. Centralised inventory of dependencies and integrations - SBOM generation and maintenance at the enterprise level - provides the visibility foundation that everything else builds on. Attestation and provenance verification for build artifacts addresses the build pipeline compromise threat in ways that other controls don’t. Aggressive minimisation of OAuth scopes and third-party integration relationships reduces the SaaS supply chain attack surface.

Less clearly effective are the more theatrical responses - vendor questionnaires that don’t produce actionable intelligence, security ratings services with weak signal quality, and compliance checklists that don’t translate to operational defence. The maturity of supply chain security practice is now sufficient that organisations should be able to distinguish between practices that produce defensive value and practices that produce paperwork.

Where to focus for the rest of 2026

For security teams planning the rest of the year, a few areas suggest themselves as high-value priorities. Build pipeline hardening, including provenance attestation, deserves continued investment if not already complete. SaaS integration governance is an area where significant gains are available for moderate investment. AI dimension of the supply chain - both the tools developers are using and the defensive applications - needs sustained attention rather than treating it as a separate topic.

The supply chain attack surface isn’t going to shrink. The defensive practice that addresses it has matured to the point where serious investment produces serious results. The organisations that treat this as a primary concern will be in materially better shape than those that treat it as a secondary one.