CodeQL finds vulnerabilities in code, StackAttest asks whether the deployed system holds
If you ship open source on GitHub, turn CodeQL on. It is available at no cost for public repositories, it is deep semantic analysis rather than pattern matching, and there is no argument on this page for leaving it off. What it answers is what vulnerabilities are in this code. StackAttest asks a different question: whether the deployed system enforces anything, and whether somebody outside the team can read the answer.
Which one fits your situation
CodeQL may be the better fit when the question is what vulnerabilities are in this source, in depth, on every pull request. GitHub's documentation describes databases built from your code and queried with QL, a default setup that turns scanning on without anybody writing a workflow, maintained query packs per language, alerts in the repository's security tab and on pull requests, and custom queries you can write yourself. On public repositories it is available at no cost, which makes the decision easy for anything open source.
StackAttest may be the better fit when the question is whether the running application is ready: not only what the source contains, but whether the deployed system refuses a request for another account's data, whether a rollback path exists and whether backups have been restored, each result carrying the strength of the evidence behind it, ending in a Passport you can send to somebody outside the team.
The same questions, asked of both
Each row is one question put to both instruments. The CodeQL column is drawn from GitHub's own documentation, and where their documentation does not say something, neither does this page.
What it is for
Finding vulnerabilities in source code by treating the code as data and running queries against it, on pull requests and on a schedule.
Establishing whether an application is ready to run in production, across source, runtime behaviour and operational readiness, with the strength of each result recorded.
Who it is built for
Developers and maintainers working inside GitHub, and the security teams who own code scanning across an organisation's repositories.
Founders, and the investors, accelerators and customers asking them for a technical answer they can check.
Scope
Source in the languages GitHub's documentation lists for CodeQL, analysed from a database built out of the repository. Availability differs between public repositories and private ones, which their documentation sets out.
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
Deep, and semantic rather than textual. Queries follow dataflow and taint across the extracted representation of the program, which is what lets one report an untrusted value travelling from where it enters to where it is used.
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. CodeQL analyses a database built from the code rather than a running deployment, and GitHub's documentation describes code scanning as static analysis.
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.
Custom queries
Yes. QL is a query language, and GitHub documents writing your own queries and packaging them for reuse. It is a larger thing to learn than a pattern, and it can express more.
No. Thirteen fixed controls, the same on every run, so that two reports are comparable to each other and to a report from another company.
Where it runs
In GitHub Actions through default or advanced setup, or through the CodeQL command line in another CI system, with alerts surfacing in the security tab and on pull requests.
As a run you trigger against a public URL, a connected repository, or a built and running instance of the application. Nothing has to live in your CI pipeline.
What a result looks like
A code scanning alert: the query that fired, the path the data took, the location in the file, and a state a maintainer can fix or dismiss with a reason.
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
On pull requests and on a schedule, with alerts tracked in the repository over time so a regression reopens rather than arriving as news.
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
An alert list in the security tab, and a check on the pull request telling a developer what to look at before merging.
A founder-controlled Passport: control results, evidence grades, what stayed uncovered, and a signed technical attestation.
Where it stops
It describes the code in the repository. Whether the deployment enforces what the code implies, whether a rollback path exists, or whether a backup has ever been restored are outside what a static analysis engine sets out to answer.
It is not semantic analysis. There is no query language, no dataflow graph to interrogate, and nothing here competes with a purpose-built analysis engine on its own ground.
Statements about CodeQL and GitHub code scanning on this page are drawn from GitHub's own public documentation at docs.github.com, read on 1 September 2026. Language support, setup options and availability change. Where this page and their documentation disagree, theirs is right.
Source analysis is the overlap, and CodeQL goes further into it
Some of the thirteen controls are settled by reading source, and they cover ground the maintained CodeQL query packs also cover: injection-unsafe data access, credential material in the repository, authorisation that is only enforced in the interface. On that ground both are doing the same work, and CodeQL's semantic analysis will usually see further along a dataflow path than a control-oriented pass does. Claiming otherwise would be easy for this audience to check and it would be wrong. What StackAttest adds is not more analysis of the same file. It is the runtime half, the operational controls, and a report addressed to somebody who is not on the team.
If your repository is public, turn CodeQL on
This page is not going to bury the useful advice underneath a sales argument. CodeQL is available at no cost on public repositories, GitHub's default setup switches it on without anybody writing a workflow, and the alerts land where the maintainers already work. If you are shipping open source, there is no version of this comparison that ends with you not using it. StackAttest is not a reason to leave it off, and a page that implied otherwise would be doing you harm to make a sale.
What a query engine answers
CodeQL treats your code as data. A query can follow an untrusted value across function boundaries to the place it is used, which is why it can report a genuine path rather than a suspicious-looking line. That is a different thing from matching a shape in a file, and it is why GitHub can maintain query packs that hold up across large codebases. If your question is what vulnerabilities are in this source, this is one of the strongest instruments available for answering it, and StackAttest does not attempt to compete on that ground.
The runtime half is the part source cannot settle
Source tells you what the program says. It does not tell you what the deployment does. A data access policy can exist in a migration and be switched off in the project actually serving traffic. An authorisation check can be present in the handler nobody calls and missing from the one that answers the request. A backup schedule can be configured and never restored. StackAttest builds and runs the application, probes it, and records whether the deployed system refuses a request for another account's data, which is a question no static engine claims to answer.
What somebody outside the team can do with an alert list
Not much, and that is not a criticism of the alert list. It is addressed to whoever is going to fix the code: it lives in the repository, it assumes access, and it stops being interesting the moment the work is done. An investor in diligence, an accelerator comparing a portfolio, or a first enterprise customer with a security questionnaire needs a different document, one that reports a result per control, the strength of the evidence behind each, and an explicit list of what nobody could establish. That is what a Passport is. It does not do the work an alert list does, and the alert list does not do this.
Using both
Most teams shipping on GitHub should have code scanning on and leave it on. It costs the pipeline a few minutes and it catches the class of bug that is hardest to see by reading. A validation is not a substitute for that and does not want to be. It runs when somebody outside the team asks a question, covers the running system and the operational controls that no analysis of source reaches, and reports what it could not establish rather than leaving the gap unstated.
What this page is not claiming
- Nothing on this page is a reason to turn code scanning off. If your repository is public, CodeQL is available to you at no cost and this is not an argument against using it.
- This is not a claim that StackAttest finds more than CodeQL. On the source they both read, a purpose-built semantic analysis engine goes further than a pass feeding thirteen controls.
- There is no query language here and no way to write your own analysis. The control pack is fixed at thirteen controls.
- Availability and licensing for private repositories are GitHub's to state and to change. This page does not restate them beyond saying that they differ from public repositories.
- 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 CodeQL alternative?
For part of what CodeQL does, and not for the rest. If you want deep semantic analysis of your source, CodeQL does that far more thoroughly than a pass feeding thirteen controls, and on a public repository it is available to you at no cost. If what you need is a readable answer to whether the deployed application is ready, that is a different instrument, and this is one.
Should I turn code scanning off if I use StackAttest?
No. They answer different questions and they run at different moments. Code scanning catches vulnerabilities in the source as it is written; a validation reports whether the running application holds up against a defined set of controls when somebody outside the team asks.
What does CodeQL do that StackAttest does not?
GitHub's documentation describes code databases queried with QL, dataflow and taint tracking, maintained query packs per language, custom queries you can write and package, default and advanced setup in Actions, and alerts tracked in the repository's security tab. StackAttest does none of those.
What does StackAttest do that CodeQL does not?
It builds and runs the application and probes the running system, covers operational controls such as backups and a rollback path, grades the evidence behind each result, names the controls it could not reach, and ends in a Passport a founder can publish and a reader outside the team can check.
Does CodeQL test the running application?
No, and it does not claim to. GitHub's documentation describes code scanning as static analysis of a database built from your code. Whether the deployed system enforces what that code implies is a separate question, and it is the one a runtime validation exists to answer.
Can I use both?
Yes, and most teams on GitHub should. Code scanning runs in the repository on every pull request. A validation runs when somebody outside the team asks whether the product is ready. Neither one blocks 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.