Open Source Is a Weapon Now. Most Founders Are in the Blast Zone.

Two separate groups poisoned popular open source tools this week. North Korean state hackers hijacked Axios, one of the most depended-upon npm packages on the planet. Apple, meanwhile, just released a new open source project for password managers, adding yet another dependency to the pile. And GitHub is out here celebrating "this year's most influential open source projects" like the foundation under all of it isn't cracking.

If you are a CEO, CTO, or founder shipping product on top of open source (that is all of you), this is the week you need to stop treating supply chain security as somebody else's problem. It is yours. And it is about to get dramatically worse.

The Fantasy of "Just Audit Your Dependencies"

I hear this constantly. From security consultants, from compliance officers, from conference speakers who have never shipped a product on a deadline. "Audit your dependencies." "Pin your versions." "Review the code before you pull it in."

Let me describe reality. A typical Node.js project pulls in 800 to 1,500 transitive dependencies. A Python ML project can easily hit 400+. That's today. Right now. And most teams have zero humans assigned to review what comes in through their package manager.

The Axios compromise is a perfect case study. North Korean hackers targeted it because it has hundreds of millions of weekly downloads. One poisoned version propagates everywhere. Every startup running Axios (which is basically everyone building JavaScript) was a potential target. No amount of "auditing" catches a state-sponsored supply chain injection in a package your team pulls automatically on every npm install.

And then, on top of that, two more attackers poisoned other popular tools this same week. This is not an anomaly. This is a pattern accelerating.

AI Is About to Break the Model Completely

Here is what keeps me up at night from my office in Jönköping. We are entering a period where AI coding agents can generate and publish packages at scale. Not dozens. Millions.

Look at what is trending on GitHub right now. everything-claude-code has 183,000+ stars. opencode, the open source coding agent, has 160,000+. The system-prompts-and-models-of-ai-tools repo documenting how every AI coding tool works has 137,000+ stars. Everyone is building AI that writes code. Everyone is building AI that ships code.

Now imagine the attacker side. A state actor, or even a sophisticated criminal group, uses AI agents to generate thousands of plausible-looking packages. Typosquats. Forks with subtle backdoors. Packages that look helpful, solve real problems, pass superficial review, and contain a payload that activates weeks later. The cost to produce these is approaching zero. The cost to review them is still measured in expensive human hours.

At HEIMLANDR, where we build AI agent systems, I see both sides of this. AI agents are enormously powerful for legitimate development. We use them. We build them for clients. But the same capabilities that let you ship an MVP in two weeks let an attacker generate a thousand poisoned packages in an afternoon.

The industry's response so far? "Use Dependabot." "Enable Scorecard." "Check Sigstore signatures." These are good tools. They are also completely insufficient for what is coming.

The Sweden Problem (and the Sweden Advantage)

I run a tech company in Jönköping, Sweden. Not San Francisco. Not London. This gives me a specific vantage point on this problem.

Sweden's software development ecosystem is disproportionately dependent on open source. We do not have the same density of enterprise software vendors as the US. Swedish startups and scale-ups build almost exclusively on open source stacks. Spotify, Klarna, Tink, and hundreds of smaller companies all sit on the same supply chain. One poisoned npm or PyPI package hits the Swedish tech ecosystem with the same force it hits Silicon Valley.

But here is where Sweden is actually behind. Swedish regulators and the EU more broadly are focused on the AI Act, GDPR enforcement, and digital sovereignty rhetoric. Nobody is seriously addressing supply chain integrity for open source software at the policy level. The EU Cyber Resilience Act (CRA) takes a step, but it puts obligations on "manufacturers" while the actual vulnerability surface is in the dependency graph of components nobody manufactures. They just... exist. Maintained by one person in Nebraska, as the famous xkcd cartoon describes.

MSB (Myndigheten för samhällsskydd och beredskap) handles cybersecurity guidance for Swedish organizations. They do decent work. But their frameworks assume you know what software you are running. The entire point of supply chain attacks is that you do not know what you are actually running, because it arrived buried seventeen layers deep in your dependency tree.

The advantage Sweden has? Scale. Swedish tech companies are generally small enough to actually change their practices. A 50-person startup in Stockholm or Jönköping can mandate reproducible builds, lock dependency resolution, and implement real-time monitoring of package behavior faster than a 10,000-person American enterprise drowning in procurement processes. If Swedish tech leadership takes this seriously now, we can actually move first.

What Is Actually Happening When a Supply Chain Attack Hits

Let me be concrete. Because too much writing about this stays abstract.

When the Axios package gets compromised, here is the kill chain:

1. Attacker gains access to a maintainer's npm account. Phishing, credential stuffing, social engineering. Sometimes they just buy access.
2. They publish a new version with a payload. Often obfuscated. Sometimes it only activates in certain environments (production, not CI).
3. Automated pipelines pull the new version on next build. If you have not pinned exact versions with integrity hashes, you get the poisoned version automatically.
4. The payload phones home, exfiltrates environment variables (which contain API keys, database credentials, cloud access tokens), or installs a persistent backdoor.
5. By the time anyone notices, the attacker has your secrets and has moved laterally into your infrastructure.

This takes hours. Your quarterly security audit does not help. Your SOC 2 certification does not help. The attack happened between deploys on a Tuesday afternoon.

Where This Goes: 2026 to 2030

Three trajectories I see from here.

1. The package registry crisis

npm, PyPI, and crates.io are going to face a volume problem they cannot solve with current models. AI-generated packages will flood registries. Distinguishing legitimate from malicious will require AI-powered analysis on the registry side, which the current nonprofit and volunteer-run registries cannot afford. Expect either consolidation (big companies taking over registries) or a legitimacy collapse where developers retreat to vendoring dependencies locally. Both outcomes are bad in different ways.

2. Verified supply chains become table stakes

SLSA (Supply-chain Levels for Software Artifacts), Sigstore, and reproducible build infrastructure will stop being niche concerns and become requirements. Not because of regulation, though the EU CRA pushes in this direction. Because insurers will demand it. Cyber insurance underwriters are already asking about software supply chain practices. Within two years, you will not get coverage without demonstrable supply chain integrity measures.

3. The AGI wildcard

As AI systems become more capable and more autonomous, the attack surface expands in ways we haven't fully mapped. An AI agent that can autonomously install packages, evaluate code, and deploy services is also an AI agent that can be tricked into pulling a compromised dependency. The more autonomous your AI development pipeline, the more critical your supply chain integrity becomes. This is not a future problem. At HEIMLANDR, we build AI solutions that interact with code and infrastructure. Supply chain integrity is already a core design constraint for us. If it is not for you, you are building on sand.

What to Actually Do About This

Stop reading think pieces (including this one, after you finish it) and take concrete action.

Monday morning, this week:

• Run npm audit or pip-audit on every project. Not to fix everything. To see how bad it is. Get a baseline.
• Enable lockfile-only installs in CI. No resolving new versions during builds. Only what is locked.
• Set up Socket.dev or Snyk on your repositories. Imperfect tools, but they catch the obvious stuff.

This quarter:

• Implement an SBOM (Software Bill of Materials) for your production systems. The EU CRA is going to require this. Get ahead of it.
• Evaluate your dependency depth. If a critical service depends on 1,200 packages, ask whether that is necessary. Often, it is not. You pulled in a library to left-pad a string and inherited 47 transitive dependencies.
• Talk to your insurer about supply chain risk. If they do not ask about it, switch to one that does. The ones not asking are not pricing risk correctly, which means they will either jack premiums or deny claims later.

What to Look At

Socket.dev provides real-time analysis of npm and PyPI packages for supply chain risk. Not perfect. Far better than nothing. If you are shipping JavaScript or Python, you should have this running.

n8n (188,000+ stars) is interesting here because it represents the workflow automation layer where supply chain risk meets operational reality. If you are building automation pipelines, the packages those pipelines depend on are your attack surface. n8n is self-hostable, which gives you more control. That matters.

SLSA Framework (slsa.dev) is the supply chain integrity framework from Google that actually makes sense. It defines concrete levels of assurance. Start at Level 1 (provenance metadata) and work up. It is the closest thing we have to a practical standard.

Sigstore (sigstore.dev) provides keyless code signing for open source artifacts. It is what npm and PyPI are moving toward. Understanding it now saves you from scrambling when it becomes mandatory.

The Uncomfortable Truth

Open source won. It powers everything. That is precisely why it is now the highest-value target on the planet. The same ecosystem that lets a two-person startup in Jönköping compete with a hundred-person team in San Francisco also lets a North Korean hacking unit compromise thousands of companies simultaneously through a single poisoned package.

The answer is not to abandon open source. That ship sailed. The answer is to stop pretending the trust model from 2015 still works. It does not. Every dependency is a trust decision. Every automated install is a risk acceptance. Every package you did not read is a door you left unlocked.

I am not telling you to read every line. I am telling you to know what is in your house and to have a plan for when something goes wrong. Because this week proved, again, that it will.

Build things. Build them carefully.

Fredrik Brunnberg is the CEO of HEIMLANDR.IO, building AI and software solutions from Jönköping, Sweden. This is the daily HEIMLANDR briefing. If you found this valuable, share it with someone who builds things.