Every cybersecurity vendor selling into DevOps has the same dirty secret: their account-based marketing list is technically correct and operationally useless. They know Acme Corp uses Kubernetes. They have ZoomInfo emails for 800 people with "engineer" in the title. What they don't know — and what kills them in QBR — is which nineteen of those eight hundred people actually push code that touches the cluster.
This is the story of one of those vendors. Call them Sentinel — a Series C container-security platform competing against the usual cast: Wiz, Snyk, Aqua, Lacework. They had a great product. They had analyst love. What they didn't have was a way to find the people who'd actually approve replacing their existing scanner. We'll walk through how they retired three tools you've probably used and rebuilt their targeting from the contact level up.
The buyer behind the install
Sentinel's old motion looked like every other DevSecOps GTM motion in 2024. Buy an install-base feed. Pull every account running a competitive product. Hand it to SDRs. Watch reply rates flatline at 0.6%.
The diagnosis took their RevOps team a quarter to articulate, but it was simple in hindsight: they were optimizing for the account, not the human inside the account. At a 2,000-engineer fintech, "Director of DevOps" might own deployment tooling — or might own desktop support. "Site Reliability Engineer" might run the platform — or might be a transferred QA lead the title fairy visited last quarter. Titles, said one of their AEs, "are vibes."
We were paying for a list of accounts and pretending it was a list of buyers. The accounts were right. The people were random.
— VP Marketing, Sentinel
What Sentinel needed wasn't more accounts. It was depth inside the accounts they already had. They needed to know, for each target: who pushes to the IaC repo, who owns the GitHub Actions workflows, who has been answering Kubernetes security questions on Stack Overflow, and who quietly merged the last seven SAST PRs. Those people don't show up in title-based filtering. They show up in code.
Why HG, ZoomInfo & BuyerCaddy fell short
Sentinel had spent real money on three different layers of the conventional stack. Each one was good at one thing — and blind to the thing that actually mattered for their sale.
None of the legacy tools were wrong. HG Insights correctly identified the install base. ZoomInfo correctly delivered verified contacts. BuyerCaddy correctly aggregated intent. The problem was that all three operated at the account layer — and Sentinel sold a tool that gets bought one practitioner at a time, then ratified by a VP. Account-level data was solving the wrong half of the equation.
The CLT approach
Contact-Level Technographics is a different unit of analysis. Instead of asking "does this company use Tool X," CLT asks "which specific humans at this company have a digital trail showing they actually use Tool X?" The answer comes from stitching together signals across the places engineers leave evidence of their work: GitHub commits, Stack Overflow tags, Kaggle notebooks, package contributions, conference talks, and OSS issue threads.
For Sentinel, the relevant toolchain wasn't a single product — it was the whole DevSecOps perimeter. The taxonomy they cared about looked like this:
LeadGenius built Sentinel a custom audience layered against those signals. Not a static list — a refreshed view that surfaced, for each of their 1,200 target accounts, the people inside who had observable evidence of working with that stack. The output: a contact graph showing toolchain density per account, named practitioners with confidence scores, and — critically — the relationships between them.
From contacts to a buying center
The cleverest part wasn't the contact discovery. It was the role mapping. CLT didn't just hand Sentinel a flat list of "people who use Kubernetes." It segmented them into the three layers that actually move a security deal forward:
Engineers and SREs with active commits to IaC, Helm charts, GitHub Actions workflows, or container manifests. These are the people who will actually run the POC. CLT identified them by code activity, not by title — so Sentinel found practitioners whose titles ranged from "Software Engineer III" to "Cloud Architect" to, in one memorable case, "Chief of Staff to CTO" (who happened to be merging the most Terraform PRs in the org).
Staff and Principal engineers, platform leads, and DevSecOps managers who oversee the toolchain but don't ship every line. CLT surfaced them via a mix of mentorship signals — answering questions on Stack Overflow, reviewing PRs in OSS, speaking at KubeCon or DevOps Days. These are the people who, when convinced, drag the rest of the team along.
VPs and Directors of Platform, Infrastructure, or Security Engineering. CLT identified them through org-graph inference: who do the practitioners and influencers report up to? Where does the budget for this category sit? In most accounts, this was a single named person — and Sentinel knew about them before the SDR sequence even started.
The buying center stopped being a guess. Sentinel's playbook went from "blast the C-level, pray someone forwards it down" to "engage the practitioner, equip the champion, then book the VP with three internal references already in motion." Bottom-up sales with a top-down close.
Inside the 30-day pilot
Sentinel ran CLT against a focused pilot: 25 target accounts where they'd been stuck for two or more quarters. The brief to LeadGenius was tight — surface every practitioner with toolchain evidence, score the accounts by density, and hand off three activation plays for sales, marketing, and RevOps respectively.
Three plays came out of it, and each one retired a workflow that the legacy stack had been failing at.
Play one — displacement at the practitioner level
Sentinel's competitive displacement motion used to start with the account: "we see Acme uses CompetitorX." Now it started with the engineer: "we see Maria at Acme has been filing issues against CompetitorX's Helm chart and quietly building workarounds in her own fork." That's not an account-level signal a static database can give you. That's a person who is in active pain right now and would take a discovery call this week.
Play two — resolving PLG signups
Every cybersecurity company with a free tier or trial has the same problem: someone signs up with a Gmail address, kicks the tires, and disappears into the unqualified bucket. Sentinel had thousands of these. CLT resolved a striking share of them to a GitHub identity, a work domain, and — in many cases — a target account they were already chasing through outbound. Anonymous trial users became named, contextualized buyers inside priority accounts. Marketing stopped throwing those leads away. They started nurturing them.
Play three — content and events that don't insult engineers
Sentinel's old webinar invite went out as "The Future of Cloud Security." Reply rates: tragic. The CLT-powered version went out as "Hands-on: hardening GitHub Actions workflows with SBOM verification" — and it went only to people whose public activity showed they were working with GitHub Actions. The list was a tenth the size. Registration rates were an order of magnitude higher. Engineers showed up because the invite reflected what they did yesterday.
We stopped writing for personas. We started writing for the seventeen people at each account who would actually click. The funnel became smaller and dramatically more honest.
— Director of Demand Gen, Sentinel
None of this would have been possible from a static database. Static databases tell you what was true the last time someone scraped LinkedIn. CLT tells you what's true in the last 90 days of commits, contributions, and conversations. For a category that moves as fast as DevSecOps, that delta is the whole game.
