Semgrep

It is Tuesday morning at a B2B SaaS company you have heard of. A pull request opens. Before a human reviewer has poured coffee, a bot has already commented on line 47 with a fix: that string concatenation is becoming a SQL query, here is the parameterized version, click to apply. The author is annoyed for about four seconds, then clicks. The bot is Semgrep. It does not know it just prevented a breach. It does not know what a breach is. It knows patterns.

That moment - quiet, unremarkable, deeply unsexy - is the thing Semgrep has spent the better part of a decade trying to make ordinary. The company sells the unglamorous proposition that security should look like a code review, run like a unit test, and feel like nothing at all.

The Problem They Saw

For two decades, application security followed a particular script. A scanner ran overnight. By morning it had produced a PDF the length of a small novel. Somewhere in there, between false positives about test fixtures and warnings about the year 2038, were real vulnerabilities. The security team's job was to find them. The developers' job was to ignore the security team. Everyone agreed this was suboptimal. Nobody had a better idea.

The legacy SAST vendors had built their tools for compliance auditors, not engineers. The reports were comprehensive, which is a polite way of saying they were unreadable. Worse, the rules were locked inside the product. You could not write your own. If you wanted the scanner to understand your codebase - your conventions, your wrappers, your tribal knowledge about the database layer - you could not. You waited for the vendor to ship a release.

"Traditional SAST was a slot machine: pull the lever, get noise, occasionally a prize." The state of code scanning, circa 2017

Isaac Evans, Drew Dennison, and Luke O'Malley - three MIT grads, with Evans and Dennison former college roommates - saw this stalemate from the inside. Evans had run security for a hedge fund. Dennison had been at Palantir. The market did not need another scanner. It needed a scanner developers would actually run.

The Founders' Bet

The bet was simple, and a little contrarian: what if security rules looked like the code they were trying to find?

Not regex. Not abstract syntax tree wizardry that requires a PhD to author. A pattern that reads like the buggy snippet itself, with a few wildcards. Find eval($USER_INPUT). Find requests.get($URL, verify=False). If you can describe the bug in code, the rule writes itself.

The technical foundation already existed, in the way the best technical foundations usually do - someone else had built it years earlier as a Tuesday afternoon side project. In 2009, a Facebook engineer named Yoann Padioleau wrote a tool called sgrep, semantic grep, as part of an internal program-analysis library called pfff. It was clever, useful, and almost entirely unknown. In 2019, Padioleau joined the company. In 2020, the team renamed the tool from sgrep to Semgrep, did the work to make it production-grade across thirty-odd languages, and gave it away free.

"Semgrep is grep that understands code. Which is to say, grep that finally earned the name." The pitch, distilled

Open-sourcing the engine was not a marketing move so much as an existential one. The thesis only worked if developers wrote and shared their own rules. The company - then called r2c, which sounded like a Star Wars droid and confused everyone - built a registry. Security teams at Snowflake and Slack started contributing rules. The flywheel turned.

In 2022, r2c quietly renamed itself Semgrep, Inc. The product had become more famous than the company, which is the kind of problem most startups would trade their dental plan for.

The Product

Today Semgrep sells one platform with three blades on it. Each replaces a category of legacy tooling that AppSec teams used to buy separately, integrate badly, and tolerate grudgingly.

• Semgrep Code (SAST) — The original pattern-based scanner, now with cross-file dataflow analysis. Reads source code in 30+ languages and flags bugs as pull-request comments instead of overnight reports.
• Semgrep Supply Chain (SCA) — Scans third-party dependencies for vulnerabilities, but only screams about the ones your code actually reaches. Reachability analysis is the difference between a Tuesday and a fire drill.
• Semgrep Secrets — Detects leaked credentials, then validates them against live services to figure out which ones still work. Triage by reality, not regex.
• AppSec Platform — The SaaS console that ties it together with a shared policy engine, AI-assisted triage, and per-contributor pricing.
• Semgrep CE — Free, open-source, and the reason any of this works. Run it locally, run it in CI, never pay anyone.

"We are not in the business of generating tickets. We are in the business of making them go away." Isaac Evans, paraphrased across approximately 40 podcast appearances

The Proof

A static analyzer's only real test is whether engineers actually run it twice. Semgrep passes. Dropbox uses it. Figma uses it. Snowflake uses it. GitLab uses it - and also built it into their own DevSecOps offering, which is the kind of compliment that comes with a contract attached.

The numbers around the open-source side are similarly stubborn. More than 14,000 GitHub stars, a registry of thousands of rules, and a community that includes security researchers from Trail of Bits, Snyk, and a long tail of AppSec engineers who would rather write a rule than file a ticket.

"If your security tool isn't running in CI, it isn't running." Every CISO who has lost an argument to a developer

Revenue, per public reporting, sits in the mid-eight figures. The Series D in February 2025 - $100M from Menlo Ventures with the existing crew piling on - brought total funding to $193M. The press release was professionally restrained. The internal Slack, one assumes, was less so.

The Mission

Semgrep's stated mission is to "profoundly improve software security and reliability for everyone." This is the kind of sentence that gets written on a whiteboard and then quietly negotiated with a marketing consultant. The unstated version is more interesting: make security feel like a code review.

The implication, which the company is too polite to state outright, is that an entire generation of AppSec tooling treated developers as adversaries to be governed. Semgrep treats them as the actual customer. The security team is welcome to the dashboard - but the value is delivered in the pull request, in the IDE, before the bug has a chance to ship.

That is a quiet but radical reframing. It is also, by all available evidence, working.

Why It Matters Tomorrow

The next wave is here and it does not care about your security policy. Large language models are generating code faster than humans can read it, let alone audit it. Cursor and Copilot have changed the volume problem from "lots of code" to "an obscene amount of code, much of which is plausible-looking but subtly wrong."

That is, conveniently, the exact problem Semgrep has spent eight years building for. A scanner that runs on every commit, understands the dataflow, and writes back fixes in pull-request comments is no longer a nice-to-have. It is the only sane way to keep AI-generated code from also being AI-generated CVEs. The Series D capital is, by the company's own framing, going toward this: AI-assisted rule authoring, AI-assisted triage, AI-assisted everything except the part where a human decides what a vulnerability actually is.

"The volume of code is going up. The number of security engineers is not. Something has to give, and it is going to be the manual review." The bet, restated for 2026

Back to that Tuesday-morning pull request. The author of those four lines of SQL would not have called themselves a security professional. They were not trying to be one. They were trying to ship a feature before standup. The fix happened anyway, in the background, because someone in San Francisco decided years ago that this was a more interesting problem than building a better PDF report.

The fix happened anyway. That is the entire pitch. The next decade of software security depends on it happening, quietly, a few billion more times.