More than 454,600 new malicious packages. Last year alone.

Software supply chain attacks have become the dominant intrusion pattern of the current threat landscape, and the numbers back up why it deserves board-level attention rather than a line item in a broader security budget. Sonatype identified over 454,600 new malicious open source packages in a single recent year, a 75 percent year-over-year increase, bringing the cumulative total of known malicious packages past 1.2 million — with more than 99 percent of that volume concentrated on npm alone. Third-party involvement in breaches has doubled year over year according to industry breach reporting, the largest single-year shift ever recorded in that data, and a supply chain compromise now takes an average of well over 250 days to identify and contain, the longest lifecycle of any breach vector tracked.

The second problem is that attackers aren't relying on sophisticated zero-days to pull this off. The consistent pattern across recent major incidents is maintainer account takeover through credential stuffing, phishing, and SIM swapping, followed by publishing a malicious package version through an entirely legitimate, properly signed, authenticated channel. Traditional signature verification alone is structurally insufficient against this pattern, because the malicious code arrives with a completely valid signature from a genuinely compromised, previously trustworthy account — and dependency confusion attacks have grown more targeted, with attackers actively researching internal package naming conventions from job postings and public repositories before registering the matching malicious public package.

The third problem, increasingly relevant, is AI coding assistants introducing an entirely new failure mode: hallucinated dependencies. AI tools frequently suggest package names that don't actually exist, or that exist but are outdated or already known to be vulnerable, and a substantial share of AI-suggested dependency versions carry real risk from hallucination or known vulnerabilities. Attackers have begun registering the specific non-existent package names AI assistants reliably hallucinate, waiting for a developer to accept the suggestion on a tab-complete — a technique with real room to scale as AI-assisted development adoption continues to grow.

We build supply chain security around verifiable provenance rather than implicit trust — Software Bills of Materials that are living and continuously enriched rather than static exports, combined with SLSA-aligned build provenance that cryptographically documents how every artifact was actually built, not just what components it claims to contain. This matters specifically because an SBOM alone would not have caught incidents like SolarWinds, where every listed component was technically legitimate and the compromise happened inside the build process itself — provenance verification is what catches that category of attack, and it's the layer most supply chain security programs are still missing.

For the credential-based attack pattern now dominant in the field, we implement short-lived, OIDC-based credentials for CI/CD systems in place of long-lived static keys, scope build permissions to the minimum required for each specific job, and isolate build environments so no single compromised system controls both source and build execution. For AI-assisted development specifically, we establish dependency curation policies that block packages that are too new, unmaintained, or otherwise suspicious before they ever reach a developer's environment, and build validation specifically for AI-suggested dependencies, given how frequently those suggestions carry real, documented risk.