Vivian Dufour - co-founder of Meterian - enterprise sales for startups
Vivian Dufour's CTO once took "half a day, take your time" to check the security of a company's education app. He came back in under an hour — having hacked her own account through an unpatched open-source backdoor to prove the point.
Vivian Dufour is the co-founder and CEO of Meterian, an open-source vulnerability scanner. She and her co-founder Bruno started the company after that unplanned demonstration of just how easy an open-source vulnerability is to exploit, and after Vivian was personally affected by the 2017 Equifax breach — caused by an unpatched Apache Struts vulnerability.
We get into the specific sales tactic that got prospects to actually test Meterian side-by-side with their existing tools, how she hires and evaluates salespeople with zero prior sales experience of her own to draw on, and why she thinks cold-calling developers works better than the conventional devtools wisdom says it should.
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.
What's the origin story of Meterian?
I was a product manager at an educational firm, and our job was to take a software app viral in schools across Europe. I raised that this would be sitting in classrooms with teachers and students, and asked if we could get a security check done — management's response was, don't worry about that, go viral first, we'll figure out security later. I asked our CTO, Bruno, to do a quick, rough check, telling him to take half a day if he needed it. In under an hour he came back and said, go check your account — he'd found a backdoor via an open-source vulnerability, used it to compromise my account, and moved around content to prove the point, complete with a 'you've been hacked' message. I already knew cross-site scripting and SQL injection existed as concepts, but I hadn't realized how fast and easy actually exploiting one could be. That was the moment that opened my eyes.
What made you commit fully to building a company around this, rather than just fixing it once?
I was personally affected by the Equifax breach in 2017, caused by an unpatched open-source vulnerability in the Apache Struts module — a patch existed, it just hadn't been applied — and I got that letter in the post saying my data had been compromised. Watching McAfee, LinkedIn, Yahoo, and others show up in the news the same way eroded my trust in how large corporations handle data we've all been encouraged to put online for convenience. When the opportunity to work on this came up, it felt genuinely mission-oriented — a chance to use my skills to contribute to the solution rather than just be an innocent bystander watching it happen to other people.
How does Meterian differentiate in an already crowded market with incumbents like Black Duck and Veracode?
We provide comprehensive risk visibility specifically on open source, with strong automation that intelligently removes duplicates and minimizes noise, so developers aren't overwhelmed with false positives — what surfaces are verified vulnerabilities actually embedded in the field, though developers still need to judge whether a given one is applicable given how their application's logic uses that dependency, especially once you get into nested transitive dependencies. We deliberately don't require developers to have deep security expertise; they mainly need to be comfortable updating packages and applying patches. The harder part for most teams is actually integrating a tool into their existing environment — how it plugs into source control, CI/CD, and other test scripts — and that's where a lot of our differentiation and customer support actually lives, since our engineers know the product and the problem space deeply.
You've used a distinctive sales tactic of suggesting a side-by-side test against a prospect's existing tool. How does that work?
Early on, we went through a cybersecurity accelerator called CyLon, where we met a lot of CISOs and CTOs. When someone already had a security tool in place, instead of asking them to switch, I'd suggest running a side-by-side test as an independent evaluation — extra assurance either way. If it went well, they could consider replacing what they had; if not, they got more confidence the tool they already had was good, and we got direct customer feedback on what to improve to reach real product-market fit. That only worked because we made the product genuinely easy to test — it's a thin client, essentially a script inserted into the CI pipeline, so we just needed one developer for half an hour to an hour: thirty minutes for a demo, the rest for them to try it themselves and give feedback.
How do you make sure a successful trial actually turns into a closed deal?
Establishing commitment upfront matters a lot — before the trial even starts, we understand their tech stack in detail so the demo is set up to be meaningful to them, and we make sure they understand how to read the reports, not just install the tool and let it become shelfware. A raw report can be forty pages, and if you're lucky, fixing one issue makes twenty of those pages disappear — so we walk them through the format and how to action a specific vulnerability, sometimes with one-step auto-remediation. We lay out upfront exactly what we'll cover in the trial — code management integration, CI integration, understanding the reports, seeing real value — and get agreement on that before starting, so at the end we can review what was achieved against what was promised, and note anything that turned out to be a bug on our side versus a configuration issue on theirs.
You hired your sales team with no personal sales background. How did you actually find good salespeople?
The best way to find a good salesperson is to talk to other salespeople — they all know who's good, the same way if you want to find a good developer, you ask your developer friends, because they run in the same circles. We eventually found someone experienced who'd built sales teams from the ground up himself, self-taught, and he helped us evaluate other hires. I drafted the first version of the job description, he refined it, we posted it on LinkedIn and startup job boards, and I'd shortlist CVs before he'd screen candidates further. One thing that surprised me: unlike product or engineering CVs, which tend to hold up when you actually get someone on a call, a lot of sales CVs looked incredible on paper and then gave a completely different impression once we actually spoke — I think because of how easy it's become to produce a polished CV. You really have to talk to people, first online and then in person, to filter for that.
What traits do you actually look for in a salesperson?
Real professionalism in how they present the company, since they're often the first voice a prospect encounters — we do a lot of outbound cold calling, so the sales rep's voice literally needs to be clear and engaging. Beyond that, I look for a genuine desire to help the person on the other end of the line understand their actual challenge and how we can remove pain from their day-to-day job, not just push a pitch. In one call, a head of software engineering mentioned drowning in security review meetings looking at pen test results — I pointed out we're not pen testing, but we catch issues early in development so there's less downstream maintenance burden later, which is exactly the 'shift left' thinking security-aware developers already believe in. That kind of genuine problem-framing, more than technical depth, is what actually lands.
Does cold-calling actually work in devtools, despite the common wisdom that it doesn't?
It's worked for us, including calling CTOs, CISOs, and sometimes developers directly. I think it works because you're seizing a moment — most people's day is spent heads-down at a computer working on a document or in a meeting, so if someone actually picks up the phone, they've implicitly signaled they're open to an interruption right then, which is different from an email that just gets scanned and skipped in a crowded inbox. The salesperson still has to capture attention immediately rather than meandering, the same discipline good email subject lines need. It also helps to have a genuinely diverse team, since voice and presence are subjective — a customer one rep couldn't connect with might respond completely differently to someone else.
Do salespeople in a technical security space need to be able to code themselves?
No, I don't think so. If they can, it gives them more material to connect with a customer later as the relationship develops, but it's not necessary — they need to understand the problem and the pain, not how to personally remediate a vulnerability. What actually matters is understanding whether a prospect has this specific problem, when they'd want it resolved by, whether they have budget allocated, and whether they genuinely care. When we bring someone new onto the sales team, they spend their first week studying our sales playbook and adapting it to their own language and understanding, then spend real time with our technical team — especially Bruno, who's always doubled up on presales — so they can ask things like how we're actually different from a Tenable or a Coverity, which cover an adjacent but different part of the space. That first version of the pitch has to come from the founders, though — you can't outsource figuring out what resonates to someone joining from outside.