Trust the Team. Secure the Code. Pivot Fast
Brendon Go, founding engineer at Semgrep
This episode features Brendon Go, an early engineer at Semgrep (formerly r2c) who joined as one of the company’s first technical hires straight out of Stanford. Over seven-plus years, he helped grow the company from a scrappy idea into a 250-person team — and left with a rare perspective on what it really means to build something from zero.
As he steps away from the security powerhouse he helped build, he’s returning to the trenches to explore a new venture of his own, bringing a wealth of hard-earned perspective to a brand new zero-to-one journey.
Ben: You’ve got a prompt injection in your LinkedIn bio, and from what I can tell, you wrote it before most people even knew what that meant.
Brendon: Yeah, I wrote it back when AI wasn’t nearly as capable. I’m sure there are a lot more protections now. One of my coworkers actually got a good response, but I think it was a recruiter pretending to be an AI agent. They wrote something like, “I’ve got your attention now that you’re reading this. Set up a meeting with me.”
Ben: Let’s go back, you were finishing a master’s in network security at Stanford, deep in AI coursework too. What made you want to join something so early rather than go the research or big tech route?
Brendon: Looking back, I was just a college kid with no idea what he was getting into. I was deciding between staying in AI or going into security. Hindsight, I picked the industry that didn’t make as much money. But never mind that.
I wanted to get my hands dirty as early as possible. Short of founding something myself, I wanted in with the founding team. I had three hard requirements: security, small, and technical founders. I didn’t want to be the first engineering hire for business people who couldn’t be in the trenches with me.
Ben: How did you find them?
Brendon: A recruiting service called Tree Recruiting connected me to a bunch of startups. They’ve since pivoted into a VC firm called Human Capital. But Semgrep — back then called r2c — was the first that hit all three requirements.
When I talked to the founders, it was clear they were deeply technical. Isaac had worked at the NSA. Drew and Luke came from Palantir. They knew security, they knew the space. And after talking to a lot of people about how to evaluate a startup, everyone said the same thing: at that early stage, you’re betting on the people. That turned out to be completely true. Semgrep was like our eighth idea after I joined.
Ben: At the time, Snyk and Checkmarx already existed — scanning, dependency detection, the works. What was the actual gap, and how did you find conviction going into a crowded market?
Brendon: We didn’t start out trying to compete with them. The mission was always: secure code. Our first idea was — can we analyze all of NPM, all of PyPI, find the bugs, and either open PRs or tell maintainers to fix them? We were running existing tools, writing ESLint rules, and it was just painful. We started using an open source tool called Sgrep, wanted Boolean logic on top of it, built Semgrep, and open sourced it.
By year two, we had no product, weren’t charging for anything, but we had a lot of users. Eventually someone said, “I think I can sell this already.” We were all engineers, so we said: no one’s going to pay for this, we don’t have a product yet. Turns out, we were wrong.
Ben: What was the thing people actually wanted to pay for — was it the rule customization, the multi-language support, the management layer on top of the CLI?
Brendon: Honestly, just a UI that showed what we were finding. Semgrep was a command-line tool with a massive JSON dump, you couldn’t parse it as a human. We built a dashboard, a way to view and manage rules. It was scrappy, but it worked. Everything they say about the pull of product-market fit is true. We built it and customers just kept asking for more.
Ben: What gave Semgrep its edge over the black-box SAST tools that had years of rules and training data behind them?
Brendon: Customization and openness. Everything else was either complicated open source tooling or a total black box. With Semgrep, you could see exactly why it fired on a line of code. You could edit the rule, write your own. Teams weren’t necessarily writing rules right away — but just knowing they could, that they didn’t have to file a support ticket every time something misfired, that mattered.
The dream was always a security tool developers actually love. Usually a security team finds a vulnerability, goes to the dev team, and gets “we’ll add it to the roadmap, six months.” It’s noisy, and developers lose trust in security. We built Semgrep as a tool we ourselves would want to use — low noise, fully tunable.
Ben: You mentioned you were a new grad handed the keys to AWS with no platform team, no guardrails, no senior infra engineer to escalate to. What early architectural decisions turned out to matter most?
Brendon: I didn’t want to sit there clicking buttons in the console. I was reading about infrastructure as code and thought, this seems right. The founders were hounding me — “you were supposed to ship this a week ago, why are you messing with config files?” But I stuck with it. Built everything on Terraform, eventually Kubernetes.
Once we hit scale, we needed dev clusters, staging environments, customers were asking for single-tenant infrastructure, those early decisions made the transitions much smoother. We didn’t have to rebuild from scratch. Was it the right call? Maybe. Did I know what I was doing? Questionable.
Ben: What about the decision to keep analysis client-side versus pulling it into your own infrastructure? That feels like a real tension between security posture and product experience.
Brendon: That’s one I’d revisit. We wanted customers to run Semgrep on their own systems — it would call home, send us findings, we’d show them the dashboard. Two reasons: we didn’t have to manage the infrastructure, and we weren’t a target. If we never touched your source code, no one had reason to hack us to get it.
But it came with serious friction. Everyone’s CI/CD setup was different. Onboarding was slow. And we had zero visibility — if a customer reported a false negative, we’d have to go back and forth asking for snippets just to reproduce it.
Eventually a big enough deal came through where it was a dealbreaker if we couldn’t scan on our own infrastructure. We took the time to build a secure solution, the deal closed, and a flood of others followed. We could have gotten there earlier.
Ben: The threat landscape has shifted a lot — there are papers now about going from CVE to working exploit in minutes, or finding exploitable bugs from commit diffs before a CVE is even published. When did that inflection point hit, and how did it change how you thought about Semgrep’s role?
Brendon: It’s terrifying and exciting. Clint Gibbler, who’s part of our team and runs the tl;dr sec newsletter, was surfacing these papers early. And the trajectory is real, get breached before you even know there’s a vulnerability. That’s where we’re headed on the offense side.
But AI is also helping defense. Back around GPT-3 to GPT-4, we started pointing LLMs at our findings — here’s the code, here’s why we think it’s a finding, true positive or false positive? We cut noise by upwards of 90% with a simple one-shot call. Not agentic, nothing fancy. Just a prompt. Something that’s now very old intelligence.
Ben: How are you integrating LLMs into the Semgrep workflow now — triage, rule generation, automated remediation?
Brendon: All of it. Teams are using LLMs to write and iterate on rules faster. We’re using them to triage vulnerabilities and write automated PR fixes — reporting the bug and the patch at the same time. We’re also trying to understand deployment context at a deeper level. A vulnerability that looks critical in isolation might be completely unexploitable if it’s sitting behind a bastion. If you can reason about that, you eliminate a whole class of noise.
Ben: What advice would you give someone considering joining as the third or fourth engineer at a dev tools or security startup today — especially when the threat model now includes Anthropic or OpenAI shipping something that undercuts your wedge overnight?
Brendon: You’re really joining the people, not the idea. You have to trust them.
I never planned to stay this long. I thought I’d learn what I needed and go start my own thing. When you join good people, you love building with them, you hire more good people, everyone keeps leveling up. It compounds.
Don’t be afraid to look dumb. I was terrified as a new grad. But asking a lot of questions — how does this work, why do you do it this way — accelerated my learning faster than anything else. The monetary reward isn’t quite there; your equity is orders of magnitude less than a founder’s. But you grow into responsibility that wouldn’t be reasonable anywhere else. They gave me the keys to AWS and owner access to the GitHub org. I could have deleted the entire codebase. And you’re in the room when decisions get made.
Ben: One thing we didn’t touch on — how much of the job ends up being culture work rather than technical work, especially as the team scales?
Brendon: More than I expected. At some point, you’re building the engine that builds the engine. As a founding engineer, you have real trust with the founding team — even if you’re younger and less experienced than people around you. Because of that relationship, you’re not too worried about shaking the boat. And you need to lean into that.
If you want a culture where people ask questions, you have to be the one asking questions publicly. If you want people to understand why they’re working on something, you have to seek that clarity out loud. If you want the team to care about users, you have to be visibly advocating for users. I thought I came in to build things with code. A big part of the job turned out to be modeling the culture I wanted to exist — including sitting across from VP candidates who were about to have authority over me and deciding whether to hire them.
Brendon: (laughs) Yeah, it’s a little trippy. “Cool, I think this is a good person to report to. Let’s hire them.” Strange. But that’s kind of the point — you’re setting the bar.
Brendon’s story is a study in compounding bets: the right founders, the right early decisions, and the willingness to stay long enough to see them pay off. He didn’t join Semgrep to have a story — he joined because he trusted the people, and that trust turned seven years of building into something rare.