CYBRET vs Semgrep: a reasoning engine, not a pattern engine.
Semgrep made code search programmable. Custom rules, OSS roots, dev-first ergonomics, and broad language support are the reasons it lives in thousands of CI pipelines. CYBRET solves a different class of problem: we reason about identity flow, business rules, and runtime behavior, where pattern rules cannot reach.
Semgrep matches patterns. CYBRET reasons about behavior.
Semgrep is, at its core, a structural search tool. You write a rule; it finds matching code; it runs in CI. The rule language is genuinely good (better than the regex era it replaced), and the OSS rule packs cover a long list of common bug patterns across Python, JavaScript, Go, Java, Ruby, and more. For a team that wants to enforce internal coding standards or catch known anti-patterns, Semgrep is the right shape of tool.
CYBRET is not a pattern engine. We build a knowledge graph of the application: routes, identities, ownership predicates, data flows, and runtime call traces. Then we ask questions a rule cannot ask. Does the DELETE handler check the same ownership predicate as the GET handler? Does the identity attached to the JWT match the user_id used in the query? Is the regex on /search a ReDoS risk under the actual traffic pattern we observe in production? Those are reasoning questions. They do not factor into a structural rule, no matter how clever the metavariables get.
Capability comparison
Honest read: Semgrep is the better tool for custom rules, broad surface SAST, and dev-workflow integration with a free starting tier. CYBRET is the better tool when the question is whether a vulnerability is reachable, exploitable, and provable, and when the answer requires reasoning about logic that no pattern can express.
| Capability | Semgrep | CYBRET |
|---|---|---|
| Custom rule authoring | Class-leading | Available, not the focus |
| Language breadth (surface SAST) | 30+ languages | 12 languages, deep analysis |
| Pattern-based bug detection | Excellent | Subset of what we do |
| Identity flow reasoning (BOLA, BFLA) | Hard to express in rules | Core engine |
| Business logic vulnerabilities | Not the model | 37 detectors, 100% recall on Juice Shop / crAPI / VAmPI |
| Cross-file & cross-service taint | Limited | Full graph |
| Runtime call-trace correlation | No | Yes (Runtime Detection) |
| Knowledge graph (code, identity, cloud, runtime) | No | Yes, single graph |
| Autonomous proof-of-exploit | No | Yes, runs the exploit safely |
| Reachability across deployment | No | Yes |
| OSS / self-hosted core | Yes (Semgrep OSS) | Commercial, VPC deploy |
| Compliance posture | SOC 2 | SOC 2 audit underway · ISO 27001 Stage 2 scheduled · GDPR DPA |
The right tool for a real job.
Semgrep's rule language is the best dev-facing pattern DSL we've seen. Metavariables, structural matching, taint mode, and the OSS-first model created a community of contributors that no closed scanner can match. For codifying internal standards (no eval, no os.system on user input, no deprecated cryptographic primitives), Semgrep slots into CI with almost zero friction and runs fast.
Their language coverage is broader than ours and probably will remain so. Their developer experience (CLI, editor plugins, free tier) is sharper than the legacy SAST market by a clear margin. We respect the tool, and a number of CYBRET customers run Semgrep alongside us. The only thing we push back on is the framing that "rules can find anything if you write enough of them." Identity flow, ownership predicates, and reachability across services are not pattern problems; they are reasoning problems, and a pattern engine running 50,000 rules will not converge on the answer.
Three things rules cannot express.
1. Identity flow, not source patterns.
BOLA, BFLA, and identity confusion are about whether the identity in the request matches the identity used in the database query, across every code path that touches the same resource. CYBRET tracks user_id, tenant_id, JWT subject, and ownership predicates as first-class graph nodes. We achieved 18/18 on OWASP Juice Shop and 100% recall on crAPI and VAmPI without writing per-app rules. A pattern engine cannot encode "the same predicate must apply on GET, PATCH, and DELETE" because the predicate is not a pattern.
2. Business rule extraction, not anti-pattern enforcement.
Our BusinessRuleExtractor mines invariants out of your code: price > 0, quantity bounded by inventory, state machine transitions, temporal ordering. Then we look for paths that violate them. Semgrep can flag the absence of a known-bad call; it cannot flag the violation of a rule it has never been told about.
3. Runtime call traces and autonomous validation.
CYBRET correlates static findings with runtime traces from production and writes an exploit that proves the vulnerability is real. Our Validation product runs the exploit safely, attaches the trace to the ticket, and re-runs continuously to detect regressions. Pattern engines don't run code; we do.
Keep Semgrep. Add CYBRET above it.
The most common deployment we see: Semgrep stays in CI for custom rules and code-style enforcement, CYBRET sits above it as the reasoning layer. We ingest Semgrep SARIF natively. Findings flow into our graph, reachability and validation are layered on top, and engineering teams get one ranked list per repo. No need to throw out months of rule authoring; the rules become inputs.
For teams whose Semgrep deployment is mostly OSS rule packs, we've seen successful consolidations onto CYBRET for SAST + business logic. Custom rules remain a strong Semgrep use case if your security team has built up rule libraries; we'll tell you that during sales rather than after you sign. Pricing is per closed path, not per developer or per scan.
Questions buyers actually ask.
Does CYBRET replace Semgrep?
For most teams, no. Semgrep is excellent for custom rules and dev-workflow gating. CYBRET sits above it as the reasoning and validation layer. The two complement each other.
Can CYBRET ingest Semgrep findings?
Yes. We accept Semgrep SARIF and JSON exports natively, plus webhook-driven imports. Findings flow into our knowledge graph and gain reachability scoring within minutes.
Why not just write more Semgrep rules?
You can encode known anti-patterns. You cannot encode identity flow, ownership predicates, or runtime reachability with a pattern, no matter how expressive the DSL gets. Different problem class.
Is CYBRET open source?
No, the engine is commercial. We deploy in your VPC by default and we are public about the techniques we use (graph + reasoning + validation). The choice is intentional given the validation surface.
How does pricing compare?
Semgrep prices per developer (free tier for OSS rules). CYBRET prices per closed path. Teams running mature Semgrep deployments often see CYBRET cost less because we charge for outcomes, not seats.
What does CYBRET do that Semgrep architecturally cannot?
Three things: identity flow reasoning, business rule extraction and violation detection, and autonomous proof-of-exploit. None of these are achievable with a pattern engine, regardless of rule volume.
Bring your Semgrep findings. We'll find the BOLA your rules cannot.
Pilots run for 14 days, ingest existing scanner data, and produce a ranked list of reachable, validated paths in the first 72 hours. No rule authoring required.
Book a working sessionSee Validation