← All insights
Research

The state of open source security

Industry analysis · June 26, 2026 · ~8 min read

For most of the web, the phrase "your code" is a polite fiction. The application you ship is a thin layer of your own logic resting on a deep stack of other people's code: frameworks, parsers, crypto libraries, build plugins, and the dependencies of those dependencies. Black Duck's 2025 audit of 965 commercial codebases found open source in 97% of them, and that 64% of the open source components present were transitive, pulled in indirectly by something else you chose. You did not pick most of what runs in production. You inherited it.

That is not a complaint about open source. Open source is why a small team can ship in weeks what used to take a year. But it reframes the security problem. The interesting attack surface is no longer just your firewall or your login form. It is the trust you extend, automatically, to thousands of strangers every time you run an install command. Attackers have noticed, and over the last two years they have industrialized the exploit.

The numbers stopped being anecdotes

Supply chain malware used to be a curiosity, a few typosquatted packages a researcher would write up. It is now a production line. Sonatype reported more than 454,000 new malicious open source packages discovered in 2025 alone, bringing the cumulative total of known and blocked malware past 1.2 million packages across npm, PyPI, Maven Central, NuGet, and Hugging Face. Over 99% of it landed on npm, the registry with the largest blast radius and the loosest publishing friction.

The character of the attacks changed too. Sonatype attributes more than 800 packages in a single year to Lazarus-associated activity, the North Korean state cluster, almost entirely on npm. This is no longer opportunistic noise. It is sustained, funded, and aimed squarely at the people and tooling that build software.

Meanwhile the older problem, ordinary unpatched vulnerabilities, has not gone anywhere. In the same Black Duck audit, 86% of codebases contained known-vulnerable open source and 81% carried a high- or critical-severity flaw. Ninety percent had at least one component more than four years out of date. The supply chain is being actively attacked and is, on average, badly maintained at the same time.

Four incidents that defined the era

Statistics tell you the weather. The incidents tell you the failure modes. Four stand out because each broke a different assumption about how we trust open source.

xz / liblzma — the maintainer you trusted was the attacker

In March 2024, a Microsoft engineer named Andres Freund chased down a half-second of extra latency in SSH logins and discovered a backdoor planted in xz Utils, a compression library quietly linked into OpenSSH on many Linux distributions. Tracked as CVE-2024-3094 with the maximum CVSS score of 10.0, the backdoor would have given its author remote code execution on a vast number of internet-facing servers.

The chilling part was not the code. It was the patience. An identity using the name "Jia Tan" spent roughly two yearsbuilding credibility on the project, helped along by sock-puppet accounts that pressured the original, burned-out maintainer to hand over control. By the time the backdoor shipped in versions 5.6.0 and 5.6.1, the attacker was a trusted maintainer acting entirely within their permissions. It was caught by luck, days before it would have reached stable releases. There is no patch for "we gave commit rights to the wrong person."

polyfill.io — the script you embedded changed owners

In June 2024, researchers at Sansec found that cdn.polyfill.io, a JavaScript service embedded by hundreds of thousands of sites to patch old browsers, had begun serving malware. The domain had been acquired months earlier by a new owner, who then used its position inside other people's pages to redirect mobile visitors to scam sites. Estimates put the reach at 100,000+ sites at disclosure, with more than 380,000 hosts still embedding the script weeks later. Nobody was breached in the classic sense. The sites had simply trusted a third-party URL forever, and that trust outlived the people who originally earned it.

tj-actions/changed-files — the build pipeline leaked its own keys

In March 2025, attackers compromised a popular GitHub Action, tj-actions/changed-files, used in tens of thousands of CI/CD pipelines (CVE-2025-30066). Rather than ship one bad release, they retroactively re-pointed multiple existing version tags at a malicious commit, so even pipelines pinned to an old "known good" tag pulled the payload. The injected script dumped CI secrets, cloud access keys, personal access tokens, npm tokens, and private keys, straight into public build logs. CISA issued an alert; over 23,000 repositories were affected. The lesson: in CI, a version tag is not an identity. It is a mutable pointer, and your pipeline runs with enough privilege to hand over the keys to everything.

Shai-Hulud — the worm that spread by itself

In September 2025, the Shai-Hulud campaign became the first known self-replicating worm in the npm ecosystem. It did not just sit in a package waiting to be installed. It used the credentials it stole from one compromised developer to publish itself into more packages, autonomously, compromising 500+packages in a matter of days. Supply chain malware had crossed from "poisoned artifact" to "living propagation," a qualitative jump that defenders had been warning about for years.

Why it keeps working

None of these were sophisticated in the zero-day sense. They worked because the ecosystem's defaults are built for speed and trust, not adversarial conditions:

  • You cannot see most of what you run. With two-thirds of components arriving as transitive dependencies, the thing that attacks you is often something you never typed into a manifest.
  • Trust is granted once and rarely revisited. A maintainer handoff, a domain sale, or a tag rewrite happens after you already decided to trust the dependency, and almost nobody re-checks.
  • Registries are treated as platforms. Frictionless publishing is great for authors and equally great for attackers; a majority of malicious packages now abuse the registry itself as the delivery channel.
  • The build pipeline is a high-value target with low-value guarding. CI runners often hold the most powerful credentials in the company and execute third-party code by default.

What actually reduces the risk

The good news is that the defenses are known, boring, and effective. None of them require catching a genius. They require removing the easy assumptions the attacks rely on.

  • Pin to immutable references. Lockfiles with hashes for packages, and full commit SHAs (not tags) for GitHub Actions. A pinned hash is the single control that would have blunted the tj-actions tag-rewrite attack.
  • Generate and keep an SBOM.You cannot respond to "are we affected by package X" in an hour if you cannot list what you ship. CycloneDX and SPDX are the common formats; the next xz will be a race, and the SBOM is your head start.
  • Demand provenance.Build provenance and signing (Sigstore, SLSA levels, npm provenance) move the question from "do I trust this name" to "can I verify this artifact came from the source it claims."
  • Starve your CI of standing secrets. Short-lived, least-privilege tokens and OIDC instead of long-lived keys mean a leaked build log is an incident, not a catastrophe.
  • Weight maintenance, not just vulnerabilities. A dependency four years stale, with one maintainer and no release cadence, is a risk before any CVE is filed. Tools like the OpenSSF Scorecard surface that health signal.

Regulation is starting to push the same way. The EU's Cyber Resilience Act will make software makers accountable for the security of what they ship, SBOM included, which tends to turn "nice to have" supply chain hygiene into a requirement with a deadline.

Where SecureMonk fits

SecureMonk is an external scanner, so it sees the supply chain from the outside. When you enable the vulnerability scan, it fingerprints the front-end and server technologies a site exposes, looks up known CVEs for them, and flags an accidentally published dependency manifest (a package-lock.json or composer.lock left reachable) along with the advisories for the packages it reveals. That is a useful outside-in check, not a substitute for an internal SBOM and signed builds. If you want the deeper how-to, our guide on software supply chain risk walks through finding, fixing, and managing the exposure.

The headline has not changed in two years, only the volume. Most of your software is written by people you will never meet, and the attackers have moved upstream to meet them first. The organizations that come through this well are not the ones with the cleverest detection. They are the ones that pinned their dependencies, knew what they shipped, and refused to let a name stand in for a verified identity.

Sources