What Enterprise SAST Does Differently

The Snyk Code lesson found the honest answer to "does a commercial SAST engine find more bugs": sometimes, and the margin is narrow. Snyk Code caught a SQL injection and a second XSS that Semgrep's default rules missed — three real findings in the same direction — but a twelve-line Semgrep taint rule closes most of that gap the moment you write it.

If detection were the whole story, the buying decision would be simple: run Semgrep, write your rules, keep the money. Detection is not the whole story, and the enterprise platforms — Veracode, Checkmarx One, Fortify, SonarQube's paid tiers — know it. They are not selling you a better scanner. They are selling you everything around the scanner.

This lesson is about what that "everything" is, and how to tell whether you actually need it.

This is an overview, not a benchmark run. The measured head-to-head lives in the Snyk Code lesson and the scanner comparison. The enterprise platforms below are described from their documented capabilities and pricing model, not from a run against the Range — several have no free tier to run.

Step 1 — What we have actually measured

Two SAST engines, run end-to-end against the same deliberately broken app:

That is the entire evidence base for "commercial finds more". It is real, and it is small. Everything the enterprise tier charges beyond Snyk's per-developer price is not about that column — it is about the four things below, none of which appear in a findings count.

Step 2 — Policy you can enforce and prove

A free scanner has a threshold: --severity-threshold=high, block or pass. That is a gate. It is not a policy.

An enterprise policy is a rule the organisation sets centrally and every team inherits, whether they want it or not:

• No application ships with an open critical older than 30 days.
• Every repository handling customer data runs SAST on every pull request — and cannot turn it off.
• A new class of finding (say, SSRF) becomes blocking across 400 repositories on the date the policy says, not whenever each team gets around to it.

You can approximate the first with a shared CI template. You cannot approximate "cannot turn it off" or "changes everywhere on one date" with a template that each team owns and can edit. Centralised policy that teams cannot silently weaken is a real capability, and it is most of what Veracode and Checkmarx One charge for.

The tell is the word "cannot". Free tooling gives every team a gate they configure. Enterprise tooling gives a security function a control that teams cannot configure away. If nobody in your organisation needs to enforce something over a team's objection, you do not yet need this.

Step 3 — Reporting an auditor accepts

Run Semgrep in CI and the output is a log. It expires with the job. Ask it "prove we have scanned every production service for injection flaws every month this year, and show the remediation timeline for each finding" and there is no answer — the data was never retained in a form that can answer it.

That question is not hypothetical for a regulated business. It is the routine shape of an APRA CPS 234 or SOC 2 evidence request, and the artefact that satisfies it is not a scan — it is a durable, queryable record of:

• what was scanned, when, and at what version
• what was found, and how severe
• who it was assigned to
• when it was remediated, or the documented decision to accept the risk

Every enterprise SAST platform is, underneath the scanner, a database built to answer exactly that. Snyk's --report flag and its project history are the entry-level version of the same idea; Veracode and Checkmarx build the whole product around it, with the compliance-framework mappings (PCI, OWASP ASVS, CWE/SANS Top 25) pre-wired so the report comes out in the shape the auditor already expects.

This is the same argument the GitGuardian lesson made about secrets and the Snyk IaC lesson made about --report. Across every chapter, the thing you cannot rebuild yourself is not detection — it is the audit record. For a compliance-driven buyer, that record is the product.

Step 4 — Triage at a scale where findings stop being readable

Nine findings on one file, you read. Ninety thousand findings across four hundred repositories, you do not — and that is the state an enterprise rollout arrives at at week one.

At that volume the platform's value is entirely in what it does to the list:

• Deduplication across repos, so the same vulnerable shared library is one item, not four hundred.
• Baithlining — accept the existing backlog, gate only on net-new findings, so a team is not blocked on day one by a decade of debt.
• Ownership routing, so each finding lands on the team that owns the code, automatically.
• False-positive suppression that persists and is shared, so one triage decision does not get re-litigated on every branch.

These are the features nobody demos and everybody lives in. A free scanner run across 400 repos produces 400 separate result sets and no way to reason about them together. The enterprise tier is, more than anything else, a triage engine with a scanner attached.

Step 5 — Where the enterprise tools genuinely lead on detection

Two capabilities are real and hard to reproduce free, and worth naming so the decision is honest:

• Reachability / dataflow at depth. Whether a vulnerable dependency's function is actually called, and whether tainted input truly reaches a sink across many files and frameworks. Snyk and Semgrep sell this in their paid tiers; Checkmarx and Veracode have built their engines around it for years. It is the difference between "35 mediums" and "5 of those 35 are reachable" — a completely different remediation queue. No free tool tells you which five.
• Language and framework breadth. The free tools are strong on the popular stacks. A shop running COBOL, ABAP, legacy C++ or a dozen languages at once finds that the commercial engines simply cover more, maintained.

If your risk lives in reachability or in a language Semgrep's community rules barely touch, that is a detection reason to buy — and it is separate from the governance reasons above.

Step 6 — The cost nobody puts on the slide

Enterprise SAST is priced per developer or per application, annually, and the licence is the small number. The real cost is:

• Tuning. An out-of-the-box enterprise scanner on a large codebase produces a false-positive rate that will get it switched off unless someone spends months tuning it. That someone is a salary.
• A human who owns it. Policy, triage rules and suppressions do not maintain themselves. A tool with nobody accountable for it decays into a dashboard nobody opens.
• Developer friction. A gate that blocks pull requests had better be right, or engineers route around it — and a bypassed gate is worth less than no gate, as every chapter in this track has said.

The honest comparison is not "Semgrep free vs Veracode $$$". It is "Semgrep plus a security engineer who writes rules and works the queue" versus "Veracode plus a security engineer who tunes policy and works the queue". The engineer is in both columns. Below a certain scale the free-tool column wins outright, because the platform's governance features solve problems you do not have yet.

Step 7 — How to tell you have outgrown the free tier

Concrete signals, in rough order of how decisive they are:

1. An auditor or regulator is asking for evidence you cannot produce from CI logs. This is the strongest signal, and often the only one that matters. If a CPS 234 or SOC 2 assessment needs a remediation-timeline report, buy the record.
2. You need to enforce a control a team cannot switch off. Central policy over local autonomy is a platform feature, not a template feature.
3. The finding list has stopped being readable — hundreds of repos, and no way to dedup, route or baseline across them.
4. Your risk is reachability or an unusual language stack, and the free rules genuinely do not cover it.

If none of those is true, the scanner comparison's conclusion holds: Semgrep plus your own rules, and spend the licence budget on the engineer who writes them and works the output. The enterprise platforms are excellent at what they do; most teams simply do not have the problem they solve yet.

What you learned

• Enterprise SAST is not primarily a better scanner. The measured detection gap over free tools is real but narrow — see the Snyk Code result.
• What it sells is governance: policy teams cannot switch off, audit-ready reporting, and triage at a scale where findings stop being readable.
• For a compliance buyer, the durable remediation record is the product — the same lesson every chapter in this track reached from a different direction.
• The two honest detection reasons to buy are reachability analysis and language breadth.
• The licence is the small cost. Tuning, an owner, and developer friction are the real ones, and they land whichever tool you pick.
• You have outgrown free when an auditor asks for evidence CI logs cannot give, when you must enforce a control centrally, when the list is too big to read, or when your risk is reachability. Otherwise, Semgrep plus your rules.