Your Supply Chain Is Now Your Attack Surface

Two attackers poisoned popular open source packages this week. Not last quarter. This week. The Register calls it a preview of "the future of supply chain compromise." I call it Tuesday. If your CTO is still measuring security maturity by how fast your team ships features, you're optimizing for the wrong number, and attackers already know it.

Here's the thing nobody wants to say out loud in a board meeting: your dependency tree is not a technical detail anymore. It's your actual attack surface. Every npm install, every pip requirement, every Docker base image you pull is a decision you made without reading the fine print, made by someone you've never met, running in your production environment with your customers' data next to it.

The Patch Cycle Lost. It's Not Close.

GitHub's own annual report on CVEs and malware confirms what security teams have felt in their gut for two years: the trendline is accelerating, not slowing. Meanwhile OpenAI is reportedly trying to make open source "less of a security bargain," according to Digital Trends, which is a polite way of saying even the biggest AI labs think the ecosystem is dangerously exposed right now, today, in August 2026. And the kicker: a DeepSeek-V4-built coding agent just topped GitHub Trending this week, per 36Kr. Chinese AI labs are shipping autonomous coding agents that top global trending charts in the same week Western security researchers are confirming two live poisoning incidents. That is not a coincidence. That is the new baseline. AI writes code faster than humans can review it, and AI-assisted attackers write exploits faster than humans can patch them. Both sides of this war have the same weapon now. The Linux Foundation's latest data shows AI is driving hiring UP across Europe, even as security and skills gaps widen at the same time. Read that twice. We are hiring engineers faster than we are training them to secure what they build. Every CTO I talk to in Stockholm, Gothenburg, and here in Jönköping is racing to hire AI talent. Almost none of them are asking whether that talent knows how to audit a dependency tree.

Sweden Is Fast. Fast Is Not the Same as Safe.

Here's where I get uncomfortable, because I love this country and I built my company here. Swedish and Nordic engineering culture is genuinely excellent at velocity. We ship. We automate. n8n, the workflow automation platform out of Berlin with serious Nordic adoption, is proof that European teams build tools the whole world uses. That's real. That's something to be proud of. But velocity culture has a blind spot. In Jönköping, in Stockholm, in every Swedish tech hub I talk to, the conversation is still "can we ship this MVP in six weeks" and almost never "do we actually know every package this MVP depends on and who maintains them." Compare that to what's happening in the US right now: American enterprise security budgets have ballooned specifically because CISOs there got burned publicly, repeatedly, by SolarWinds-style attacks years ago and never went back to sleep. Sweden hasn't had its public reckoning yet. That should worry you more, not less, because it means the wake-up call is still coming. Meanwhile in Brussels, the Cyber Resilience Act is technically in force, requiring manufacturers of "products with digital elements" to build security in from design through the entire lifecycle. On paper, that's exactly the regulation this moment needs. In practice, enforcement timelines stretch into 2027 and beyond, and most Swedish SMEs building software today have no internal process that maps to CRA requirements. I've asked. Regulators wrote a good law. Almost nobody building product in this country today can tell you if they comply with it. DI and Breakit cover Swedish startup funding rounds every week. I have not seen one story this year asking a funded Swedish startup for their software bill of materials. That silence is the story.

The Uncomfortable Nordic Truth

We are good at trust. Swedish business culture runs on it. Open source runs on the same trust, at global scale, with zero verification by default. That combination used to be fine when the attackers were slow and manual. It stops being fine the moment attackers automate.

Where This Goes: 2 to 5 Years Out

Picture the next few years honestly, not optimistically. By 2027, I expect autonomous attack agents that don't just find vulnerabilities in open source repos, they write the poisoned package, submit the pull request, and wait, patient as a state actor, for a maintainer with low scrutiny to merge it. This isn't speculative. It's the exact pattern The Register documented this week, just without a human on the attacking side doing the manual work anymore. By 2028, expect the first serious regulatory teeth in the EU. The Cyber Resilience Act enforcement will bite, and Swedish companies exporting to the EU market (which is most of them) will face real fines, not warnings, for shipping software with undocumented dependencies. Brussels moves slowly but it does eventually move. Toward AGI-adjacent capability (and I use that term carefully, we are not there, but the trajectory matters), the asymmetry gets worse before it gets better. A sufficiently capable AI system doesn't need to find one clever exploit. It can probe ten thousand repos simultaneously, learn from every failed attempt, and never get tired. Your security team does not scale that way. Nobody's does, unless the defense is also automated, also continuous, also built into the pipeline rather than bolted onto the end of it. The market shift I'm most confident about: "software bill of materials" stops being a compliance checkbox and becomes a sales requirement. Enterprise buyers in the US already ask for SBOMs in procurement. That habit is coming to Europe, and Swedish B2B SaaS companies that can produce one instantly, with confidence, will close deals faster than competitors who scramble to generate one under deadline pressure.

What This Means for Builders, Not Just Security Teams

I run an AI and software company. We ship product. So this isn't theory for me, it's Tuesday morning risk management. When we do Rapid MVP work for a client, "fast" has always meant fast to validate, not fast and blind. Every dependency we pull in gets a reason to exist. That discipline costs almost nothing when you build it in from day one. It costs everything when you retrofit it after a breach. The same applies doubly to AI agent development. If you're building autonomous agents (and given what's trending on GitHub this week, you probably are, or your competitor is), those agents often pull their own dependencies, call their own APIs, sometimes even write and execute their own code at runtime. That is a supply chain multiplier. An agent with tool access is your attack surface times however many tools it can reach. Most teams building agentic systems right now have not modeled this risk. They're excited about capability. Fair enough, capability is genuinely exciting. But capability without a security model is just an incident waiting for a slow Tuesday.

Know What You Shipped

The real skill for 2026 isn't "ship fast." Everyone can ship fast now, that's what AI coding assistants gave the entire industry. The skill that actually differentiates good engineering teams from exposed ones is knowing, with certainty, exactly what's in what you shipped. Every package. Every transitive dependency. Every maintainer's commit history. If you can't answer "what does our software actually depend on" in under five minutes, you don't have a security program, you have a hope.

What to Look At This Week

If you run engineering and you're taking this seriously starting today, here's where I'd point you: LangChain, now positioning itself as an "agent engineering platform" rather than just a framework, is worth studying for how a major player is thinking about production-grade agent architecture, including the security implications of agents that call tools and execute code. n8n if you're automating workflows with AI in the loop. Self-hosting it gives you control over exactly what data and credentials flow where, which matters more than the 400+ integrations marketing copy suggests. GitHub's own security research and annual reports are not glamorous reading but they are the closest thing to ground truth on where malware and CVE trends are actually heading, not where vendors want you to think they're heading. And honestly, before you add one more dependency this quarter, run an actual SBOM audit on what you already have running in production. Most teams have never done this once. Doing it once is uncomfortable. Not doing it is worse.

What to Actually Do About It

Stop treating dependency management as a Dependabot notification you dismiss on a Friday. Build a real SBOM process this quarter, not next year when the CRA enforcement window closes in on you. Ask every vendor and every internal team building on SaaS development or fullstack projects to document dependencies as a shipping requirement, not an afterthought. If you're building AI agents with tool access, threat model the agent the same way you'd threat model a new employee with admin credentials, because functionally that's what it is. And if you're a Swedish founder reading this thinking "we're too small for this to matter," you're wrong, and you're exactly the profile attackers automate against first. Small teams, fast shipping, low scrutiny, high trust in open source defaults. That's not an insult. That's a description of most of Sweden's best startups, and it's precisely why this matters more here, not less.

I didn't build HEIMLANDR to write scary security blog posts. I built it to ship real product from Jönköping that competes globally. But you can't compete globally if your supply chain gets poisoned by an automated attacker who never sleeps and never gets a CVE assigned to them personally. Ship fast. Ship smart. But for the love of everything, know what you shipped.

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.