One Poisoned Package From Catastrophe

The Supply Chain Is the Product Now

Right now, as you read this, two separate groups of attackers are poisoning popular open source packages that your team probably depends on. Simultaneously. The Register is reporting that two different threat actors independently compromised widely used tools at the same time, showing us what the future of supply chain attacks actually looks like. Meanwhile, Yahoo Tech confirms dozens of packages are hit in an ongoing campaign.

At the exact same moment, an AI agent built with DeepSeek-V4 is topping GitHub's trending list. AI-generated code is now the most-starred software on earth. Let that combination sit with you for a second.

We are accelerating code production while simultaneously losing the ability to verify what we ship. This is not a theoretical risk. It is happening today, May 30th, 2026. And from where I sit in Jönköping, running a tech company that builds software for clients who trust us with their businesses, this is the thing that keeps me up at night.

AI Writes the Code. Nobody Reads the Dependencies.

Here is the pattern I see every single week. A founder wants an MVP built fast. The instinct, increasingly, is to let an AI agent scaffold the whole thing. Pick a framework. Pull in dependencies. Wire it up. Ship it. The agent does not question the packages it installs. It does not check if is-even version 3.2.1 was published by the same person who published 3.2.0. It does not notice that a popular utility was taken over by a new maintainer two days ago.

This is the new reality of software development in Sweden and everywhere else. AI agent development is booming. Look at ECC on GitHub, nearly 200,000 stars, an agent harness system for Claude Code, Codex, and others. Or opencode, sitting at 167,000 stars. These tools are genuinely impressive. I use agent tooling. We build AI agent solutions at HEIMLANDR. I am not anti-agent. I am anti-blind-trust.

The problem is straightforward. AI agents optimize for speed and functionality. They are trained on patterns from millions of repos. When those patterns include pulling in thirty transitive dependencies to send an HTTP request, the agent does it. When a poisoned package looks identical to a legitimate one except for a single character in the name, the agent does not catch it. Humans barely catch it. And now humans are reviewing less code than ever.

Two Attacks at Once Is Not a Coincidence. It Is a Preview.

What makes today's news significant is not that supply chain attacks are happening. We have known about this since the event-stream incident in 2018. What matters is the simultaneity and the method.

Two different attackers. Same timeframe. Different targets. Both going after the weakest point in the entire software ecosystem: the moment between "a maintainer publishes" and "a developer installs." That window is where trust lives. And trust, in open source, is almost entirely social. There is no cryptographic proof that the person who pushed the latest version is the same person who built the project. There is no automated verification that a dependency does what it says and nothing more.

Now multiply this by the speed at which AI generates and deploys code. The attack surface is not growing linearly. It is exponential. Every AI-generated project that hits production without human dependency review is another entry point. Every startup that ships their MVP over a weekend using agent-generated scaffolding is rolling dice they do not know they are holding.

Sweden and the Nordics: Ahead on Some Things, Behind on This

I have a complicated relationship with Sweden's position in tech. We punch above our weight. Stockholm, Gothenburg, and yes, Jönköping produce real companies with real products. The Nordic model encourages trust, collaboration, open standards. Swedish developers tend to be thoughtful, well-educated, and systems-oriented.

But on supply chain security, we are not where we need to be.

The EU Cyber Resilience Act lands enforcement in 2027. Most Swedish startups I talk to have not begun scoping what compliance looks like. They do not know what an SBOM (Software Bill of Materials) is. They are not tracking which open source components are in their production systems. They definitely are not auditing transitive dependencies.

Meanwhile, US companies operate with essentially zero equivalent regulation on open source liability. American startups ship faster partly because nobody is making them account for what is inside the box. That creates a weird competitive dynamic. European companies will soon face compliance costs that American competitors do not. But European companies will also, eventually, ship more trustworthy software. The question is whether the market rewards that or punishes it.

From my perspective as a CEO doing software development in Sweden, the CRA is both a burden and an opportunity. If we get ahead of it now, if we build the tooling and processes into how we work today, we turn compliance into a selling point. If we wait until 2027 and scramble, it is just cost.

Swedish regulators at MSB (Myndigheten för samhällsskydd och beredskap) are aware of supply chain risks but are still operating in a framework designed for infrastructure, not for npm packages. The gap between policy understanding and technical reality is enormous. I do not say this to be harsh. I say it because pretending the gap does not exist is more dangerous than acknowledging it.

The Accountability Vacuum

Here is what nobody wants to say out loud. When AI writes the code, who is responsible for the vulnerability?

Is it the developer who prompted the agent? The company that shipped the product? The AI provider whose model suggested the dependency? The open source maintainer who was a solo volunteer working for free and got their credentials phished?

Right now the answer is: nobody. We have an accountability vacuum at the exact moment the attack surface is exploding. This is not sustainable. It is not even close to sustainable.

In traditional software development, if a senior engineer pulls in a compromised library, there is a code review process. There is a human who approved the PR. There is a chain of responsibility. With AI-generated code, especially in rapid MVP development, that chain often does not exist. The agent suggested it. The developer accepted the suggestion. The CI/CD pipeline deployed it. Nobody in the loop had the context to know that one of forty-seven transitive dependencies had been tampered with.

At HEIMLANDR, we treat every dependency like a decision. Not because we are paranoid but because we are responsible for what we ship. When we do fullstack development for a client, the dependency tree is part of the product. Not an afterthought. Part of the product.

Where This Goes: 2027-2030

Let me sketch the trajectory as I see it.

Short term (2026-2027)

Supply chain attacks become the primary vector for large-scale breaches. We will see a major incident. Not "dozens of packages compromised" but a top-100 npm or PyPI package fully weaponized, affecting thousands of production systems before anyone notices. The economic damage will be in the billions. It will be the moment this issue moves from security Twitter to boardrooms.

Medium term (2027-2028)

The CRA enforcement creates a split. Companies that prepared have SBOMs, dependency auditing, and provenance verification baked into their pipelines. Companies that did not are scrambling or exiting the EU market. AI providers start shipping "supply chain aware" models that can flag suspicious dependencies. This becomes a competitive feature, not a research project.

Longer term (2028-2030)

As we move toward more capable AI systems, the code generation volume will be orders of magnitude higher than today. If we do not solve provenance, verification, and accountability now, we are building critical infrastructure on foundations we cannot inspect. The path toward AGI makes this more urgent, not less. More capable systems will write more code, faster, with deeper dependency trees. If the verification layer does not scale at the same rate, we are running toward a cliff.

There is also a blockchain angle here that I think most people are sleeping on. Immutable, decentralized package registries with cryptographic provenance could fundamentally change how we trust dependencies. It is not a solved problem, but it is a problem that decentralized systems are well-suited to address. We do work in this space at HEIMLANDR and I think the intersection of supply chain integrity and distributed ledger technology is underexplored.

What to Look At

If you are a CTO or engineering lead, here is what I would put on my radar this week:

1. Sigstore

Sigstore provides free, open source tooling for signing, verifying, and protecting software integrity. If you are not using it, start. It is the closest thing we have to a standard for supply chain provenance in open source.

2. Socket.dev

Socket detects supply chain attacks before they hit your codebase. It analyzes package behavior, not just known vulnerabilities. Given what is happening right now with active package compromises, this should be in every CI pipeline.

3. The EU CRA text

Seriously. Read it. Not a summary. Not a blog post about it. The actual regulation. If you are shipping software in or to the EU, you need to understand what is coming in 2027. Most of the requirements around vulnerability handling and SBOM generation are things you should be doing already.

4. n8n for workflow automation

n8n is at 190k stars and it is a solid self-hostable option for building automated security workflows. Dependency monitoring, alert pipelines, automated SBOM generation. If you are going to automate, automate the verification layer, not just the deployment layer.

The Bottom Line

We are in a moment where the tools for building software are better than they have ever been. AI agents can scaffold a working product in hours. The open source ecosystem gives us access to extraordinary capability for free. The speed is intoxicating.

But speed without verification is just velocity toward failure. The supply chain is not a side concern anymore. It is the product. When your application is 90% third-party code, the security of that third-party code is your security posture. Period.

I am not telling you to stop using AI agents or to stop depending on open source. That would be stupid. I am telling you to treat your dependency tree with the same seriousness you treat your own source code. Audit it. Sign it. Monitor it. Know what is in the box before you ship the box.

From Jönköping, building things that have to work for real people, that is how we operate. The punk rock move in 2026 is not shipping fast. Everyone can ship fast now. The punk rock move is shipping fast and actually knowing what you shipped.

Build accordingly.

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.