Willem Delbare, Co-Founder and CEO of Aikido – Interview Series

Willem Delbare, Co-Founder and CEO of Aikido, is a serial SaaS entrepreneur and technical founder with a strong background in building developer-focused software companies. Before launching Aikido in 2022, he co-founded HR platform Officient, sustainability initiative FutureproofedCities, and CRM company Teamleader, where he served as CTO and helped scale the company into one of Belgium’s notable SaaS success stories. Throughout his career, Delbare has focused on simplifying complex technical challenges in cloud infrastructure, SaaS scalability, and cybersecurity. Under his leadership, Aikido has rapidly grown into one of Europe’s fastest-rising cybersecurity startups by focusing on practical security solutions designed for modern development teams.

Aikido is a Belgium-based cybersecurity company focused on helping developers and engineering teams secure applications and cloud environments through a single unified platform. The company combines multiple security functions such as code scanning, dependency analysis, cloud security posture management, runtime protection, and AI-assisted testing into one streamlined system. Its approach is designed to reduce complexity, minimize false positives, and eliminate the need for organizations to manage fragmented security stacks across multiple vendors. Built with a developer-first philosophy, Aikido emphasizes automation, continuous monitoring, and simplified remediation workflows to help companies integrate security directly into the software development lifecycle.

What experiences from building and scaling companies like Teamleader and Officient led you to found Aikido Security in 2022, and how did your background as a technical founder shape your vision for creating a more developer-friendly approach to cybersecurity??

Over the last decade, I found my calling in B2B SaaS. With three startups as a technical co-founder and CTO and three exits across HR tech, invoice tech, and carbon accounting. All  very different worlds, but with the same obsession of building software that didn’t make people want to throw their laptops out the window.

But at every one of those companies, security kept me up at night. The fear of a data breach was real, and the tools that were supposed to help looked like the inside of an F-16 cockpit. Expensive, overwhelming, and built for someone with a PhD in computer science, not a dev team trying to ship fast.

We founded Aikido Security to directly solve this challenge. Aikido provides a unified, developer-first software security platform for organizations of all sizes that brings together the essential security features across code, cloud, and runtime in one place to make it easier for developers to ship safely and securely.

Since then, AI has made software delivery even faster and the attack surface bigger. Our next chapter is to enable organizations to keep up with self-securing software.

In February, we launched Aikido Infinite, our continuous AI penetration testing solution that validates exploitability and closes the remediation loop all before code hits production.

Developer environments are now being described as one of the biggest security blind spots. What has changed recently to make this such a critical issue?

Developer machines have always been valuable targets. They hold cloud credentials, SSH keys, npm publish tokens, Kubernetes configs, direct access to source code. But what’s changed in the last 6 to 12 months is that attackers have figured out how easy they are to compromise through the tooling developers already trust. We’ve tracked this across the full year. Trivy, TanStack, Bitwarden CLI, the Nx Console VS Code extension, and now GitHub, all breached through developer tooling, all targeting the device.

The problem is that most security teams have no visibility into what’s actually running on those machines. EDR monitors at the application level, but it doesn’t see the packages, extensions, or AI tooling running inside those applications. Meanwhile, developers are pulling in new packages, extensions, and AI tools each day with very little in the way of checks. LLMs have also made it easier to create convincing malware, which has lowered the bar for attackers across the board. That gap between what’s on developer machines and what security teams can actually see is where all of these attacks are landing.

We are seeing a surge in supply chain attacks at the same time AI is becoming widely adopted. How is AI changing the balance between attackers and defenders?

AI has made it significantly easier to create supply chain malware. Building convincing payloads, obfuscating code, and understanding how package registries work well enough to abuse them all used to require real technical skill. Now it only requires an LLM subscription. We’ve seen this directly with TeamPCP, who have been behind most of the major supply chain attacks this year, including the recent GitHub breach. They’re not a particularly sophisticated group but they’ve been prolific, and AI is a big part of how they’ve scaled. A year ago we were dealing with single-package compromises. Now we’re seeing self-replicating worms like Shai-Hulud and chained campaigns that move across registries, stealing credentials from one compromise to fuel the next.

On the defensive side, AI is helping too but in different ways. Security teams can now run continuous penetration testing across entire codebases using AI agents that test hundreds of attack paths in parallel. That frees up time for the judgment calls that still need a human. At the device level, AI is also helping catch malicious packages earlier by analysing what’s being installed before it reaches the developer’s machine. But the honest reality is that the attackers are currently benefiting more from AI than the defenders are. The bar for creating malware has dropped faster than the bar for detecting it.

Aikido talks about shifting security upstream. What does that mean in practical terms for teams building and shipping software today?

Most of the industry has spent years shifting security left into the CI/CD pipeline. The problem is the attack surface has shifted even further left than that, onto the developer’s machine itself. The GitHub breach is a good example. That wasn’t insecure code making it to production. That was a compromised VS Code extension on one developer’s laptop exfiltrating credentials before anyone wrote a line of code.

In practical terms, shifting upstream means security has to be operating continuously where the code is actually being written and where tooling is being installed. That means validating what’s running on developer devices, catching malicious packages and extensions before they land, and automatically testing for exploitable risk as code changes rather than waiting for a scheduled review. The goal is a closed loop where detection, validation, and remediation happen as part of the development workflow rather than as a separate process that runs after the fact.

With AI agents automatically downloading dependencies and tools, how should companies rethink trust in open source and third-party code?

The default with AI agents is that they pull in dependencies and tools automatically with very little human oversight. That changes the trust model fundamentally because you’ve got code running on developer machines that no one explicitly chose to install.

The Vercel breach is a good example of where this goes wrong. Vercel wasn’t hacked directly. A legitimate AI extension had OAuth access to an employee’s Google account, and that extension was compromised upstream through an infostealer on the vendor’s side. This is the same pattern we keep seeing in open source, where trusted third-party code becomes the entry point. The risk compounds because a compromised developer workstation gives an attacker the same level of access as a trusted engineer. They can modify code, insert malicious dependencies, or publish tampered versions of legitimate software, and those changes get picked up by build pipelines and spread through trusted updates downstream.

Companies need to start treating everything that runs on a developer’s machine as part of their attack surface. That includes AI agents, the tools they install, the extensions they depend on, all of it. If you only have visibility into known open source packages, you’re missing the layers where these attacks are actually happening.

The concept of self-securing software is compelling. What core capabilities are required to make that vision work at scale?

To make self-securing software work at scale you need a closed loop. The system has to be able to test real attack paths whenever code changes, confirm whether something is actually exploitable or dismiss it if it isn’t, and generate and apply fixes within the development workflow, then retest to confirm the fix worked. That whole cycle needs to run continuously without waiting for someone to schedule it. The important thing is that this isn’t about removing humans from security. It’s about handling the constant work so security teams can focus on the decisions that actually need judgment.

Developers often struggle with too many alerts and false positives from security tools. How does Aikido help teams focus on what actually matters?

Two-thirds of security leaders in our State of AI in Security & Development survey said their teams have bypassed security processes, dismissed findings, or delayed fixes because of false positives. That’s the real cost of noisy tooling. It doesn’t just waste time, it actively degrades security because people stop trusting the alerts.

The way we tackle this at Aikido is through reachability analysis and autotriage. Rather than flagging every vulnerability and leaving it to the security team to figure out what matters, we analyse whether a vulnerability is actually reachable in your code and can be exploited in your environment. If it can’t, your team never sees it. That drastically cuts the volume of alerts and means when something does come through, it’s worth acting on.

Your platform combines code, cloud, runtime security, and automated pentesting. Why is a unified approach more effective than using multiple standalone tools?

Our State of AI in Security & Development research found something counterintuitive: security teams that suffered incidents actually ran more vendor tools than those that didn’t. More tools didn’t mean better security. It meant more noise, more duplicate findings, and more time spent correlating alerts across dashboards instead of actually fixing things.

That’s why we built Aikido as a single platform across code, cloud, runtime, dependencies, and pipelines. When all of those signals are in one place, you can deduplicate findings, understand whether a vulnerability in your code is actually reachable in your cloud environment, and prioritise based on real risk rather than treating every scanner’s output as equally urgent. Teams spend less time triaging across tools and more time remediating what actually matters. And each of those capabilities has to stand on its own. A unified platform that’s mediocre at everything is just consolidating the problem. Every part of the platform has to be as good or better than the standalone alternative, otherwise the consolidation argument falls apart.

Aikido has scaled quickly and reached significant traction in a short time. What have been the biggest challenges in building and growing a cybersecurity company at this pace?

The obvious one is being a cybersecurity company from Belgium. The industry has traditionally been built out of Tel Aviv and Silicon Valley, and there was early skepticism about whether a world-class security platform could come from anywhere else. But that distance ended up being an advantage. We weren’t recycling the same playbooks. We started with a developer-first approach and a bundled product that made it easy for teams to self-onboard, which is how we quietly became the dominant developer security platform for SMBs.

The bigger challenge is just pace. We reached unicorn status in January 2026 with our Series B, revenue grew fivefold last year, and we’re now trusted by over 100,000 teams including the Premier League, Revolut, and SoundCloud. This year alone we’ve launched Device Protection for supply chain security, Infinite for AI pentesting, and a partnership with Lovable for embedded security in vibe coding workflows. Moving that fast while keeping quality high across every part of the platform is the constant challenge. But it’s a good problem to have.

As AI-native development becomes standard, what does the future of software security look like over the next few years?

The honest answer is that traditional security workflows are already struggling to keep up. Periodic reviews, scheduled pentests, after-the-fact scanning, all of that assumes a pace of development that doesn’t really exist anymore. AI-generated code and autonomous agents are introducing changes faster than those processes can validate them.

We think security has to become a continuous feedback loop built directly into how software is developed. We call this self-securing software. Every code change gets tested for real attack paths, findings get validated for actual exploitability, fixes get generated and retested, all without waiting for a human to schedule it. Early versions of this already exist today, and we’re building towards it across code, cloud, runtime, and the supply chain.

The next step beyond that is self-maintaining software, where security isn’t just catching and fixing issues but actively maintaining the health of the codebase over time. That’s further out, but the foundations are being laid now. The one thing that’s certain is that the barrier to executing sophisticated attacks has already collapsed thanks to AI, so the defensive side has to move at the same speed.

Thank you for the great interview, readers who wish to learn more should visit Aikido.