In March 2026, a security tool got hacked.

A scanner that thousands of development teams use to catch malicious packages was itself compromised and turned into a distribution channel for malware. The worm it spread was largely written by AI.

What a supply chain attack looks like in 2026

Security researchers have a name for this: a supply chain attack. Compromise one shared component, and every product built on top of it inherits the breach. The past months made the pattern painfully clear. Hijacked packages delivered malware straight into build pipelines. Self-spreading worms harvested tokens from developer machines and used them to publish poisoned versions of other trusted packages, without any human involvement. Attackers rarely force their way in anymore. They poison what everyone already trusts, and the build pulls it in.

AI is accelerating both sides of this. The same tools that help us write and review code faster are helping attackers find weaknesses and assemble malware at a pace no manual process can match.

Security and dependence are the same problem

Underneath all of these attacks sits the same issue: dependence. Every component, platform and vendor you rely on is part of your attack surface. Securing your software and controlling your dependencies are the same exercise, and at Craftzing we treat them as one.

How we defend against supply chain attacks

We treat this as one defense with several layers, because the attacks chain together too.

Packages get checked before they're allowed in. Every dependency is screened against security rules before installation, on developer laptops, in build pipelines and in containers. A poisoned package gets stopped at the gate instead of discovered in production.

Projects run on our own hardened base images and build actions. One centrally managed set, so when a new attack pattern shows up, the countermeasure reaches every project at once rather than team by team.

Permanent keys are gone. Access runs through SSO and expires automatically within hours. What malware hunts for once it's inside is credentials, so we make sure there's little worth stealing and that anything stolen goes stale fast.

Everything runs containerized. Applications live isolated in their own container and network segment, which limits how far an incident can spread. It keeps workloads portable too: containers can move, so no single platform becomes a dependency we can't walk away from.

Why we chose Aikido Security, and how we stay in control

Security tooling is an ecosystem we know from the inside: open source scanners like Trivy and Checkov, dependency tracking, cloud posture tools, and the platforms that bundle them. Our first instinct was to build the scanning layer ourselves on those open source components, wired into our own pipelines. Technically doable. But Craftzing is growing toward 1,500 repositories and 100+ cloud accounts across different tech stacks, and maintaining the same integration for every stack, in every pipeline, stopped scaling.

So we strengthened that layer with Aikido Security: code, dependency, cloud and runtime scanning in one platform, maintained full-time by specialists. Our engineers fix what it finds, in our own pipelines, on our own images. The setup stays ours.

That last part is deliberate. The same logic that makes a single cloud provider a risk applies to security tooling. The pipelines, images and processes around the platform are ours, the reporting runs on open standards, and if we ever need to switch, we can. Dependence is a choice we keep making consciously, never a default we drift into.

Naturally, we chose European. Aikido is built in Ghent, around the corner from one of our own offices. Our clients increasingly need to know where their security lives, and under whose law. Now that answer is simple.

What NIS2 and the Cyber Resilience Act will require

Europe is turning this way of working into an obligation. NIS2 makes supply chain security and risk management a legal duty for a broad range of sectors, and those requirements flow through to suppliers. The Cyber Resilience Act covers virtually every product with digital elements sold in the EU: from 11 September 2026, actively exploited vulnerabilities and severe security incidents both have to be reported within 24 hours. The attack doesn't need to succeed to start the clock.

A 24-hour window can't be met with an annual audit. It takes continuous monitoring and a controlled supply chain, in place before the incident.

Strong foundations standard, continuous monitoring on top

Every project we build or manage inherits this setup. Package screening, hardened images, expiring access, isolated runtimes and continuous scanning are part of how we deliver, from day one. Security and dependence, managed as one exercise.

Curious how your own chain would hold up? Get in touch.

By Ruben De Swaef