The Supply Chain Is the Attack Surface Now

Two separate attackers poisoned popular open source tools this week. Not last year. This week. Read The Register's breakdown and you'll notice something that should scare you more than any AGI timeline debate: nobody caught it in review. Not because the reviewers were lazy. Because the review, as a real security control, mostly stopped existing years ago. What's left is a checkbox. A green checkmark on a pull request that says "approved" while the actual human who clicked approve skimmed a diff for four seconds between two Slack messages.

I run a software company out of Jönköping. We ship AI agents, SaaS products, and blockchain infrastructure for clients who trust us with their production environments. So when I say the supply chain is the attack surface now, I'm not theorizing from a conference stage. I'm looking at our own dependency trees and asking uncomfortable questions I didn't have to ask five years ago.

The Uncomfortable Truth Nobody Wants in the Standup

AI-assisted coding did not create this vulnerability. Let's be precise about that, because the lazy take is "AI made software insecure" and that's wrong. The vulnerability has been sitting there since npm, PyPI, and every other package registry decided that "publish first, verify never" was an acceptable trust model. Typosquatting, dependency confusion, maintainer account takeovers, this is old news. Security researchers have been screaming about it since at least 2018. What changed is the blast radius. When a junior developer manually vets ten dependencies a week, they might catch something weird. When an AI coding agent pulls in forty transitive dependencies to solve a problem that used to take a human three days, nobody is reading forty new package.json entries line by line. They're reading the agent's summary and hitting merge. Look at what's trending on GitHub right now. n8n has 400+ integrations. LangChain calls itself an agent engineering platform and it pulls in a genuinely enormous dependency graph to do it. opencode, the open source coding agent with 189K stars, exists specifically to write more code faster, which means more dependencies added faster, which means more surface area added faster than any human review process was ever designed to handle. None of these projects are doing anything wrong. I use some of them. But the math is brutal: dependency trees are exploding while the number of humans capable of actually auditing a diff stays flat or shrinks. That gap is where this week's attacks lived.

Ollama's $65M and the Skills Gap Nobody's Pricing In

Ollama just raised $65M and crossed 9 million users. Good for them, genuinely, local model tooling matters and they've earned the growth. But sit with that number next to the Linux Foundation's own report flagging a widening security-and-skills gap in Europe. We have explosive growth in AI tooling adoption happening at the exact same moment the pool of people who can competently review what that tooling pulls into your codebase is not growing at anywhere near the same rate. Hiring stays hot for AI roles. Nobody's hiring supply chain security engineers at the same pace. That's not an accident, it's a market signal. Companies are optimizing for velocity because velocity is what gets funded, what gets promoted, what gets celebrated in a GitHub trending list. Security review is a cost center until the week it isn't, and this week it wasn't for whoever got hit by these two poisoned packages.

Sweden and the Nordic Reality Check

Here's where I'll push back on my own countrymen a bit. Swedish tech culture prides itself on being methodical. We like process. We like consensus. We like a Fika break to talk through a decision before we make it. That instinct, historically, has made Swedish and Nordic software teams reasonably good at not shipping garbage. But that same instinct creates a false sense of security right now. A lot of founders and CTOs I talk to in Stockholm and here in Jönköping assume their careful, consensus-driven engineering culture protects them from supply chain risk. It doesn't. Careful people click "approve" on dependency updates just as fast as careless ones when the volume is high enough and the tooling tells them it's fine. Process without teeth is just a slower version of no process. Compare that to what's happening in the US right now, where the volume of AI-generated code shipping to production is genuinely staggering, and companies are starting to build real automated supply chain scanning into CI/CD because they got burned first and they got burned bigger. Compare it to what I see out of parts of Asia, where some of the largest platform companies have had dedicated dependency security teams for a decade because they learned this lesson at a scale that made it existential. Sweden and the broader EU are in an awkward middle position. We have strong institutional trust and decent baseline engineering discipline, but we don't yet have the regulatory teeth or the tooling culture to match the actual risk. The EU's Cyber Resilience Act is coming, and it will eventually force software vendors to take a harder look at their software bill of materials. But "eventually" is doing a lot of work in that sentence. The Act phases in obligations over the next couple of years while poisoned packages ship into production today, this week, in real time. Regulation is walking. The attack surface is running.

Are Swedish Regulators Ready?

No. I'll say it plainly. PTS and MSB do solid work on national infrastructure resilience, and Sweden's cybersecurity strategy documents read well on paper. But the actual enforcement mechanism for "did your company verify its open source dependency chain before shipping" barely exists for the mid-market companies that make up most of Swedish tech. Big banks and defense contractors get real scrutiny. The 40-person SaaS startup in Jönköping building the next fintech tool does not, and that startup is exactly as exposed as everyone else to a poisoned package three layers deep in its build.

Where This Goes: 2 to 5 Years Out

Here's my honest forecast, and I want to be direct instead of hedging, because hedging is how CEOs avoid making decisions. Supply chain attacks are going to get worse before regulation or tooling catches up, and AI coding agents will accelerate both the problem and eventually the solution. In the next two years, expect more headline-grabbing poisoned package incidents, and expect at least one to hit a company big enough that it forces real regulatory movement, probably in the EU first given the Cyber Resilience Act timeline, possibly triggered by a breach that touches critical infrastructure or financial services. By 2028 or so, I expect "AI-verified software bill of materials" to become table stakes for any serious enterprise vendor contract, the same way SOC 2 became table stakes a decade ago. Not because everyone suddenly cares about security, but because insurance underwriters and enterprise procurement teams will start requiring it as a line item, and that commercial pressure moves faster than any regulator. The AGI angle matters here too, and it's not the angle most people expect. As coding agents get more capable, the honest risk isn't that they write malicious code themselves. It's that fully autonomous agentic development pipelines, agents writing code, agents choosing dependencies, agents approving other agents' pull requests, will remove the last human checkpoint entirely. Right now the rubber stamp is at least a human hand doing the stamping. In three to five years, if we're not deliberate about where humans stay in that loop, the rubber stamp becomes an API call between two models neither of which was trained to think adversarially about supply chain trust. That's not AGI risk in the sci-fi sense. It's a much more boring, much more immediate version: capable systems optimizing for shipping speed with zero adversarial skepticism built in, at a scale no human team can audit after the fact. The companies that win in this window are the ones that build adversarial verification into their pipeline now, while it's still cheap and while the regulatory hammer hasn't fully dropped.

What to Look At

If you're a CTO or engineering lead reading this and wondering what to actually do Monday morning, here's where I'd point you: Software bill of materials tooling. If you don't have an automated SBOM generated on every build, start there. It's not glamorous. It's the seatbelt. Dependency pinning and lockfile discipline, enforced, not suggested. Look at how projects like freeCodeCamp, one of the most-starred and most-scrutinized codebases on the planet, handle dependency governance at scale. Big open source projects with real community review are a decent benchmark for what disciplined dependency management actually looks like versus what most private companies pretend it looks like. Agent harness security patterns. Projects like ECC, built specifically around skills, memory, and security-first development for coding agents like Claude Code and Cursor, are worth studying even if you don't adopt them wholesale. The pattern of building explicit security guardrails into the agent harness itself, rather than hoping a human catches the output later, is the direction this entire discipline needs to move. Actually read the diff on your critical path dependencies. Not all forty of them. The five that touch auth, payments, and data storage. Every time. No exceptions, no "the AI already checked it."

What This Means for Your Roadmap

If you're building an MVP right now, whether in Jönköping, Stockholm, or anywhere else, this is the moment to bake security review into your velocity instead of treating it as the thing you'll fix after you find product-market fit. I've watched too many founders tell themselves they'll "harden it later." Later is when you're already in production with real user data and a poisoned dependency three layers deep that nobody's looked at since the day it was added. At HEIMLANDR we build this in from day one on every rapid MVP and fullstack development engagement, because retrofitting security review into a codebase after six months of AI-assisted sprinting is genuinely more expensive than doing it right from the start. Same goes double for anything touching AI agent development, where the dependency surface and the autonomy of the thing you're shipping compound the risk in ways a normal web app doesn't have to worry about. This isn't a sales pitch, it's math. A poisoned package caught in week one costs you an hour. Caught in month six, in production, with customer data flowing through it, costs you your company's reputation and possibly your company.

The Bottom Line

Approval processes built for a world of ten dependencies a year don't work in a world where AI coding agents can add forty in an afternoon. That's not an AI problem, it's a math problem that AI made visible faster. The blast radius grew. The review didn't. Two poisoned packages shipped this week to prove it, and I'd bet real money there are more sitting undetected in production systems right now, including possibly some of ours, including possibly some of yours. The only responsible move is to stop pretending the green checkmark means what it used to mean, and start building verification that actually verifies.

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.