Semgrep lets you write your own rules, StackAttest grades a fixed control set
Semgrep's distinguishing strength is that you can write your own rules, and a team that can express its invariants as patterns gets something a fixed control set cannot give it. That is a capability StackAttest does not have, and this page says so before it says anything else. What StackAttest does instead is test a defined set of controls against named standards and record how strongly each result was established.
Which one fits your situation
Semgrep may be the better fit when you have invariants nobody else's rule set knows about: an internal auth helper that has to wrap every handler, a deprecated client nobody may call again, a logging call that must never be handed a raw request body. Semgrep's documentation describes rules written around a pattern that resembles the code being matched, with metavariables, an ellipsis operator and taint mode, a public registry of community rules, a playground for writing and testing them, autofix declared inside a rule, and runs in the editor, in pre-commit and in CI.
StackAttest may be the better fit when you do not want to author rules at all and the question is whether the application is ready for production: a fixed set of thirteen controls mapped to named standards, tested the same way every time, each result carrying the strength of the evidence behind it, ending in a report a reader outside the team can check.
The same questions, asked of both
Each row is one question put to both products. The Semgrep column is drawn from Semgrep's own documentation, and where their documentation does not say something, neither does this page.
What it is for
Finding the patterns you care about in source code, including the ones only your team knows to look for, and finding them fast enough to run on every commit.
Establishing whether an application is ready to run in production, and recording how strongly each control result was established.
Who writes the rules
You can, and that is the point of the product. Semgrep's documentation describes rules written in YAML around a pattern that looks like the code it matches, tested in their playground, alongside a public registry of rules maintained by others.
We do, and you cannot change them. The control pack is fixed at thirteen so that two validations are comparable and a result means the same thing on every report. There is no rule authoring and no project-specific check.
Scope
Semgrep's documentation describes Semgrep Code for first-party source, Semgrep Supply Chain for dependencies with reachability analysis, and Semgrep Secrets for credential material, with language support listed per language at a stated maturity level.
Thirteen controls across application security, dependencies, runtime behaviour and operational readiness, mapped to OWASP ASVS 5, NIST SSDF, CWE, OWASP API Security Top 10, WSTG, SLSA. A defined floor, not a complete security review.
Source analysis
Its centre of gravity. Rules match syntax rather than text, so a pattern survives reformatting and renaming, and their documentation describes cross-file analysis in the commercial product.
A read-only repository validation feeding named controls: where credential material lives, whether authorisation is enforced server side, whether data access is injection safe, and what the dependency graph carries. Findings cite the file they came from.
Runtime testing
No. Semgrep analyses code rather than a running system, which is part of what makes it quick enough to sit in a pre-commit hook.
Runtime validation builds and runs the application in an isolated environment and probes it, including whether the deployed system refuses a read of another account's data.
Dependencies
Semgrep Supply Chain is described as scanning dependencies for known vulnerabilities, with reachability analysis used to say whether the vulnerable code is actually called.
One control of thirteen: what the dependency graph carries, recorded at a stated evidence grade inside a wider report. There is no reachability analysis.
What a result looks like
A finding tied to the rule that produced it, with the matched code, the rule's severity and message, and an autofix where the rule declares one.
A control outcome with an evidence grade from E0 unknown to E5 independently reproduced, and the controls a run could not reach listed as uncovered rather than passed.
Repeatability
As often as you like, in the editor, in a pre-commit hook and in CI, against whatever rule set you have configured at the time.
The same control pack on every run, so two validations are comparable and a change in the product is visible as a change in the result.
What you have at the end
Findings inside the developer workflow, and a rule set that encodes what your team has decided it will not do again.
A founder-controlled Passport: control results, evidence grades, what stayed uncovered, and a signed technical attestation.
Where it stops
A rule finds what a rule was written to find. Whether the deployed system enforces anything, whether a rollback path exists, or whether a backup has ever been restored are not questions a static analyser sets out to answer.
It cannot be taught your invariants. If the failure you are worried about is specific to your codebase, nothing in a fixed control pack is looking for it.
Statements about Semgrep on this page are drawn from Semgrep's own public documentation at semgrep.dev/docs, read on 1 September 2026. Language support and product boundaries change, and their documentation is the current statement of both. Where this page and their documentation disagree, theirs is right.
We both read your source, and one of us can be taught
Several of the thirteen controls are settled by reading code, and the classes they cover are ones the Semgrep registry also covers: credential material committed or reachable from client code, injection-unsafe data access, authorisation that only exists in the interface. On that ground the two are doing the same work, and a team already running Semgrep with a maintained rule set will often see the same things first. The difference is not depth of pattern matching, because that is Semgrep's strength and not ours. It is that our source pass is one input to a graded control result, sitting next to a runtime probe and operational evidence, inside a report addressed to somebody who is not on the team.
What Semgrep is good at
Semgrep's documentation is the best statement of what it covers: rules written around a pattern that resembles the code being matched, with metavariables, an ellipsis operator and a taint mode for dataflow, a public registry of community rules, a playground for writing and testing them, autofix declared inside the rule itself, and language support listed per language at a stated maturity level. Alongside first-party code analysis their documentation describes supply chain scanning with reachability analysis and a secrets product. It runs in the editor, in a pre-commit hook and in CI, which is where a rule has to run if anyone is going to keep it.
Custom rules are a capability we do not have
This is the honest centre of the comparison, so it goes near the top rather than in a footnote. If your team can express its own invariants as patterns, you get something a fixed control set cannot give you: a check for the thing that went wrong last quarter, enforced on every commit, written by the people who understand why it matters. StackAttest cannot do that. There is no rule authoring, no pattern syntax, and no way to add a fourteenth control because your architecture needs one.
A fixed control set is a different promise
Thirteen controls, the same thirteen every time, mapped to named standards, each result carrying the grade of the evidence behind it. The value of fixing the set is comparability: a result on one report means what it means on another, a reader who has seen one Passport knows how to read the next, and nobody can quietly narrow the checks before publishing. The cost of fixing the set is exactly the thing Semgrep is good at. Both of those are true at once, and which one matters more depends on who is asking you for something.
Rules find what somebody thought to look for
That is true of both products and it is worth saying plainly rather than implying it only applies to the other one. Semgrep finds what its rules describe, whether those came from the registry or from your team. StackAttest tests thirteen controls and nothing outside them. Neither is a search for the unknown, which is the work a person does in an adversarial engagement, and neither should be read as one.
Readiness is wider than source
A pattern in a file cannot tell you whether the deployed system refuses a request for another account's data, whether a rollback path exists, or whether a backup has ever been restored. Those controls are settled from a runtime probe or from an operator attestation, and the report says which, at what evidence grade, and which controls the run could not reach at all. That half of the question is where a validation is doing work no static analyser is attempting.
Using both
The two do not compete for the same slot. Semgrep sits in the development loop, catching the patterns your team has decided matter, on every commit. A validation runs when somebody outside the team asks whether the product is ready, covers the running system and the operational controls as well as the source, and ends in something you can send. If you already have a rule set you trust, keep it. Nothing here is a reason to stop running it.
What this page is not claiming
- StackAttest cannot be extended with your own rules. If the failure you need caught is specific to your codebase, a fixed control pack will not be looking for it, and Semgrep would be.
- This is not a claim that StackAttest finds more than Semgrep. On the source they both read, a well-maintained Semgrep rule set will often go further than one pass feeding thirteen controls.
- No price for Semgrep appears here. Their plans are published on their own site, and a number copied onto this page would go stale without either of us noticing.
- It is not a penetration test, and running it more often does not make it one. Deterministic checks and bounded runtime probes are not a person hunting for the failure nobody anticipated.
- Thirteen controls is a defined floor, not a complete security review. A clean result means the controls that were tested held at the evidence strength recorded, mapped to OWASP ASVS 5, NIST SSDF, CWE, OWASP API Security Top 10, WSTG, SLSA, and nothing wider than that.
- It is not SOC 2 and does not replace it. SOC 2 attests to organisational controls over a period; this validates technical controls in the software. They answer different questions for different buyers.
- It does not replace human due diligence. It gives a reviewer repeatable evidence to start from, which is a different job from being the reviewer.
- Controls a run could not reach are reported as uncovered rather than passed. A result you did not earn is worse than no result.
Questions
Is StackAttest a Semgrep alternative?
For part of what Semgrep does, and not for the rest. If what you want is static analysis you can extend with your own rules, Semgrep does that and StackAttest does not do it at all. If what you need is a readable answer to whether the application is ready for production, that is a different instrument, and this is one.
Can I write my own checks in StackAttest?
No. The control pack is fixed at thirteen controls, on purpose, because a report whose checks can be narrowed before publishing is not worth much to the person reading it. The cost of that decision is real, and it is the thing Semgrep gives you instead.
What does Semgrep do that StackAttest does not?
Semgrep's documentation describes custom rules in a pattern syntax, a public rule registry, a playground, taint mode, autofix declared in a rule, editor and pre-commit integration, supply chain scanning with reachability analysis, and a secrets product. StackAttest does none of those.
What does StackAttest do that a static analyser does not?
It grades the evidence behind each result, tests the running application for behaviour that source cannot settle, covers operational controls such as backups and a rollback path, names the controls it could not reach, and ends in a Passport a founder can publish and a reader outside the team can check.
Do the source findings overlap?
Yes, on the classes both look at: credential material in the repository or reachable from client code, injection-unsafe data access, authorisation enforced only in the interface. Semgrep reports those against whatever rules you run; StackAttest uses them to settle named controls at a stated evidence grade.
Can I use both?
Yes, and many teams should. Semgrep runs on every commit inside the team. A validation runs when somebody outside the team asks a question. Neither one blocks the other, and running one is not a reason to drop the other.
Related
Find out where your application actually stands
Start with the layer you can run today. The result says which layers ran and what they could not reach, so it is honest about its own limits.