From getting hacked to cybersecurity founders with Antoine Carossio and Tristan Kalos from Escape.tech
A developer signs up for Escape without telling their manager, finds a critical vulnerability in minutes, and suddenly security has a champion inside engineering nobody asked for. Tristan Kalos built that bottom-up motion on purpose — after his own app got emptied by a Bitcoin ransom note.
Tristan Kalos and Antoine Carossio are the co-founders of Escape, an API and GraphQL security company that scans applications for vulnerabilities inside the CI/CD process.
We get into the Bitcoin ransom note that started it all, why they had to turn a Microsoft Research paper's 24-hour scan into something fast enough to run on every commit, why they deliberately block personal Gmail signups, and why their Slack invite for every single user turned out to be one of the biggest drivers of product usage.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How did Escape actually start?
It starts with a personal story. At 19 I went to the Bay Area and started building chatbots and APIs for tech companies in San Francisco — this was 2017, before anything like ChatGPT, so they were pretty bad by today's standards. One day a customer called and said the platform I'd built for them was completely broken. I logged into the MongoDB database and it was empty, except for a single message: don't worry, your data is safe, send 10 Bitcoin to this address to get it back — a very professional ransom note, with a Bitcoin address at the bottom. I had a backup, so it wasn't catastrophic for me personally, but it made me realize how fragile the applications we build as developers really are. I wondered: what happens if I build something else one day and wake up to nothing? There was no tool for this in 2017 — Snyk was just getting started, and that problem was about vulnerabilities in open-source components, which is different from what had happened to me. That question stuck with me for two and a half years until I met Antoine.
How did the two of you meet and decide to build this together?
We met as students at UC Berkeley. Antoine had worked as a penetration tester and then at Apple before doing an MBA there — he was the cybersecurity expert. I had the personal story, I knew the pain, and I knew the developer market. We put it together: I know the problem, you know the security side, let's build this. Just to be clear — Antoine wasn't the one who hacked me.
What did the actual technical starting point look like?
We were both already deep in adjacent technical work — I'd been at a company called Sourced doing machine-learning-based source code analysis to find vulnerabilities, and Antoine was already working in automated penetration testing. We did a state-of-the-art review of what existed for automated security testing and found a Microsoft Research paper called Ressler, which described basic automated security testing for applications. It was very theoretical and impractical for developers, though — it took 24 hours of computation to return a result. We knew it was possible in principle; we just had to make it dramatically faster so it could actually fit inside a real development process.
Was making it fast the hardest part, or was there more to the challenge?
The bigger challenge was really a product challenge, not just a speed one. Developers aren't used to cybersecurity as part of their workflow, so we had to build a security product that was actually compatible with how developers think and work — appealing, fast, running natively inside CI/CD, and genuinely helping them understand why something's a security concern and how to fix it, not just flagging it and walking away. Taking research-grade technology that's slow and prone to crashing and turning it into something developer-friendly with seamless integration was a huge amount of work in itself.
Security is rarely a developer's actual priority day to day. How do you get them to care?
Two things. First, you create genuine interest — developers are curious people, they want to learn about their own applications. Time to value matters enormously to us: you can set Escape up very quickly, and it immediately teaches you something about the code you actually wrote, like a forgotten setting you could change. That curiosity is the hook. Second, we added metrics developers actually care about beyond security alone — performance benchmarks on every commit, for instance, almost a gamification layer alongside the learning. But the core value is that developers like writing code but don't like writing tests, and Escape writes the security tests for them automatically — removing a genuinely large piece of hassle is what actually keeps people using it.
How did you get your first customers?
Like any startup, that's the hard part. We were insanely focused on lowering time to value — a seamless onboarding where you could immediately see and play with real results. We posted on Twitter, LinkedIn, and Hacker News; a handful of people signed up, tried the tool, and Escape uncovered genuinely critical vulnerabilities in their applications. Because the time to value was so low and what they learned was genuinely interesting, they became long-term users. It was tough from a technical standpoint too — the first time a user signed up, it crashed. The second time, it crashed. But crash by crash, the codebase got more stable, until people could go through the entire process without ever talking to us directly.
Once someone finds a critical vulnerability using Escape, do they usually stick around?
It depends heavily on the company. A ten-person startup without a real business model yet generally won't care much about security — you have to build a business before you can protect one, and that's the right priority for them at that stage. But a 500-person scale-up finding a critical vulnerability has to react — they often have SLAs and customer contracts that require proper vulnerability scanning and management. For them it's existential: stolen data can put you out of business, so it becomes something leadership genuinely cares about.
How does a single developer end up trying Escape without going through procurement or management?
That's really the magic of the go-to-market. Escape scans from an external point of view — within CI/CD, or fully SaaS against a dev or even production environment — which means a single developer can just log in and try it against their own application without telling anyone. That creates a genuinely strong bottom-up motion: we've landed inside big corporations purely because one curious developer went and tried it on their own. Who ends up paying varies a lot too — sometimes engineering, sometimes the cloud team, sometimes security, depending entirely on how that company is structured.
What happens after that individual developer finds something real?
Usually they loop in someone in management — a director of product, platform, or security — and the conversation becomes: we should make sure this never happens again. That's when Escape typically gets integrated directly into the development process so the same class of issue can't recur.
What's been the hardest part of actually staying integrated in a company's development pipeline long term?
Stability was one of the biggest challenges — when you're embedded in someone's development process, you can't be the thing that makes their deployment fail. If you block a deploy, nobody's going to like you, so you have to be extremely stable to avoid becoming the bottleneck in their engineering process, and that took real time to get right. You also have to learn to speak to very different audiences at once — developers, security teams, DevOps — each with different priorities in the DevSecOps process.
Do developers and security teams actually want different things from the same product?
Genuinely, yes — some features developers love aren't presented in a way that's useful to security people, and vice versa, so you end up needing to present the same underlying information differently depending on the persona. Developers tend to have a vertical view, focused on the specific vulnerabilities in their own project; security teams want a horizontal view across every project and team in the organization. That's a real product challenge, but a fascinating one — you're essentially building two products wrapped around one engine, and trying to get the two personas talking to each other on shared ground, so security understands what each dev team is doing, and developers understand what security actually needs from them.
Is there internal political friction between dev and security teams that you have to navigate?
The market's evolving — historically, dev and security teams were fairly siloed from each other. Now you increasingly see application security engineers who understand the codebase and sit close to developers, bridging that gap. Those people tend to become great champions for Escape specifically, because they understand both worlds and want a tool built for exactly that overlap — though finding the right person like that inside an organization isn't easy, since not every developer has the same priorities or interests.
How did you actually find and reach those early champions?
It's tied to how we grew at all — like a lot of dev tools, we ran a heavy inbound content strategy: a technical blog about GraphQL, API security, and developer topics generally, which brought us most of our early users. We also did what you could call engineering as marketing — free side-project tools like graphql.security and openapi.security, where you can quickly test ten best practices against your own API. Those drove a lot of curious traffic. Open source and speaking at conferences rounded it out — meeting the community directly. Put together, you start to build a real picture of who the actual user is inside a company, and you can focus effort on them specifically.
You require a business email to sign up, and you auto-invite every new user to Slack. Why those two specific choices?
Escape is a cybersecurity tool that can, in principle, be used offensively — for things you're not authorized to do. Blocking personal Gmail accounts and requiring a business account is about limiting the risk of misuse and making it possible to actually identify who's using the platform. The Slack invite comes from a strong belief that building a great product requires direct interaction with users, not just through the interface. We noticed usage grew significantly for users we had a Slack channel with, compared to those we didn't, so we made it standard for every single user — and it's something we built ourselves, not an off-the-shelf integration.
What are the two biggest lessons you'd share with other dev tool founders?
First: invest in content from day one. Creating genuinely good, regular content has been a real game-changer for us — people tell me they read our newsletter every time and love the articles, and it's been responsible for a large share of new users and business opportunities, along with real community interaction. Second: open source isn't the only path to a great dev tool. It's easy to assume product-led growth means open source, and we do have several open-source projects at Escape and love that model, but look at Snowflake or Snyk — neither is open source, and both are great dev tools. Integrating directly into tools people already use, like GitHub or GitLab, is another legitimate path. That said, contributing back to open source is still something every dev tool company should do, even if open core isn't your primary model.