Questions

Short answer: ask it to judge findings, not to find them. That is what AI Review does, on every paid check.

A Security Check reads your git history. The secret scan goes through the full history, else the last 12 months, else the latest commit, and the report says which. An assistant reads the files in front of it, so a key you deleted from the code but not from the history is out of its sight.

It does not need to be told what to look for. Our own 83 rules and 27 mobile config checks run on every check, including Firebase rules, Supabase row-level security, iOS network security, Android manifests, signing keys and Expo secrets. An assistant checks what the prompt points it at.

It gives the same answer twice. Scanner versions are pinned, so the same commit gives the same findings. That is what makes "Since your last scan" on the Projects page mean something: a finding that disappears is one you fixed.

Its data is recent. Dependencies are checked against a vulnerability database we rebuild every week. An assistant only knows about the vulnerabilities published before it was trained.

It keeps the noise down. Secrets in test and docs folders start at Low. A reCAPTCHA site key is explained, not flagged. A Stripe publishable (pk_) key is reported with its card-testing caveat. A comment telling the scanner to ignore a line does not silence a finding. And the coverage page lists what we do not detect.

There is nothing to set up: no command-line tools to install and no raw output to read. The free check gives you plain-language findings and a launch verdict; fix prompts come with AI Review.

Where an assistant wins: reading your code, it can sometimes spot a logic flaw, such as a missing permission check in your business rules, that no fixed rule has a pattern for. Use both.

Four things, on every Security Check: credentials committed to the repo, including git history (secrets); known CVEs in the packages you depend on (SCA — software composition analysis); misconfiguration in Dockerfiles, Kubernetes manifests and Terraform (infrastructure-as-code, IaC); and flaws in your own source — injection, unsafe rendering, weak crypto, path traversal and more (SAST — static application security testing).

Two boundaries worth stating precisely. Configuration scanning only runs when those files exist in your repository, and it checks for misconfiguration, not vulnerabilities in a container base image — that is a different kind of scan we do not run. Dependency scanning is CVE detection against what is pinned in your lockfiles, not license-compliance checking.

No. Scanning reads files and never builds, installs or executes anything from your repository — no npm install, so no postinstall script ever runs on our machines.

That is not a limitation we are apologising for; it is the boundary the whole service rests on. We hold other people’s repository tokens, and a service that executes untrusted code alongside them is one bad repository away from a very bad day.

Nowhere, for a Security Check. The scanners run on an ephemeral worker, read your files, and the worker is destroyed.

AI Review — bundled automatically onto a paid scan once it finishes — never sees your whole repository either. It reads the findings that scan already produced, each with the few lines of code where it was found, sent to Anthropic, and returns false-positive analysis, risk order and a fix prompt.

The credential scan runs first, and anything it matches is masked before a single byte reaches an AI provider. Files that exist only to hold credentials are never sent at all, whatever the scan found.

The ordering matters more than it sounds. Run it the other way around and our own finding — a live key committed to your repo — becomes the mechanism that leaks it to a third party.

Yes, in your files and in your git history. Publishable keys are flagged too, at a lower severity.

Yes. Rules written for row-level security flag policies open to anyone, RLS switched off on a table, and policies that trust user_metadata.

Yes. The secret scan reads your git history, not just the latest files. Very large repositories fall back to the last 12 months, or to the latest commit only, and the report says which.

Yes, from your lockfile, with the vulnerabilities attackers are known to exploit marked. Development dependencies are skipped.

No. Database connection strings for Postgres, MongoDB, Redis or RabbitMQ are not detected today.

Partly. Only pinned (==) versions are checked. A lockfile such as poetry.lock, Pipfile.lock or uv.lock is read in full.

No. Dockerfiles, Kubernetes manifests and Terraform are checked. Compose files are not.

No. Nothing is built, installed or run, so every finding comes from reading files. A problem that only shows up at runtime is outside what a Security Check can see.

No — and we never will. A clean report means nothing blocking was found by these tools, on that commit: a good sign, not a guarantee.

Static analysis finds what it has rules for. AI Review adds judgement on top of what a scan already found — flagging likely false positives and prioritising the rest — but neither a scan nor a review is proof of absence. Anyone selling you the other answer is selling you something.

It is also true for that commit only, which is what Pro's weekly monitoring is for.

Neither, on purpose — once a check has been AI-Reviewed. You get the fix stated as an instruction, carrying the file, the symbol, the rule that fired and the constraint the fix has to satisfy — written to be pasted into the assistant that wrote the code in the first place.

It already has your repository open and your conventions in context. Handing it the intent beats us pushing a branch you then have to audit — which would put you back where you started, reviewing code you did not write.

No. Doing it properly means evaluating a rendered page — computed contrast, focus order, ARIA against the accessibility tree — and none of that exists in source code.

Getting real results would mean building and serving your repository inside our runner, which is exactly the thing we refuse to do. The alternative was linting templates and calling a thin subset "WCAG compliance". Neither trade was worth it, so we do not offer it here.

It has its own home instead — codexmotive.com/audit — built to do it properly against a running application. Two tools because it is two boundaries: the thing that makes this one safe to point at a private repository is the same thing that makes accessibility testing impossible inside it.

Your first Security Check. Unlimited repositories, plain-language findings, and a launch verdict — no card, no API key of your own to set up. It runs scanners only; every Security Check you buy after it comes with an AI Review of what it found, bundled in, up to your plan's AI Review allowance.

Every Security Check after the first is metered — this changed from an earlier version of this product, which deliberately did not meter scans at all. That reasoning held while a scan cost us a container and two minutes and nothing else; it stopped holding the moment the product started selling checks directly, because an unmetered good cannot be a paid one.

Monitoring, and a monthly allowance. Pro scans up to 5 GitHub repositories again every week and emails you when a new High or Critical issue appears. It also includes 20 Security Checks and 20 AI Reviews a month, cheaper per check than buying packs. Every plan runs the same scanners.

The scan finds the class of problem that takes a new app down: authorisation enforced only in the browser, database rules that let any signed-in user read anyone's rows. AI Review re-reads those findings, drops the ones that are not real, and puts the rest in order with a fix prompt to paste.

Pro scans up to 5 of your GitHub repositories again every week, the same full Security Check as one you start yourself. A public repository needs nothing more; a private one needs a read-only access token, and we never scan with a token that can write.

The first scan sets the baseline and sends nothing. After that you get an email only when a scan finds a High or Critical issue we haven't seen in that repository before: from your own changes, or from a package you already use that has since been found to have a flaw. The email says how many issues and what kind; the details stay behind sign-in.

Monitoring scans don't use your monthly checks. Opening the AI review from the email uses one of your monthly AI Reviews.

It is weekly, not on every push and not real-time. After a change you care about, run a check yourself; that one does use a monthly check.

A Security Check is a scan — the scanners read your files and return every finding they produce, plain-language. On its own, it never produces false-positive analysis, a risk order across findings, or fix prompts. It is what your first, free check already gives you in full.

An AI Review reads that same scan's findings and the few lines of code each one points to, never your whole repository, and returns which ones look like false positives, which order to fix the rest in, and one combined prompt for your coding agent. It runs automatically once a paid Security Check finishes, whenever your plan bundles one in; there is nothing extra to ask for or buy. One review covers one whole scan, never one finding.

A single review reads up to 50 findings from the scan it covers. A scan that returns more than that still shows every finding in the report — the cap only limits how many of them the review itself reads and prompts for; the report screen always tells you exactly how many were covered.

Yes, for what you have not used. A Security Check or AI Review you paid for and never spent — from a pack or from a Pro allowance — is refundable if you ask within 14 days of paying for it.

Pro specifically: cancel within 14 days of first subscribing and the unused part of that period is refunded the same way. After that, a renewal charge you have used nothing from is refunded in full within 14 days of it; use any part of a renewal period and that period stays paid — cancelling still stops every charge after it.

The projects, the scan history and the stored repository tokens are destroyed.

Yes. You supply an access token with read access, stored encrypted, and it is validated when you connect the project rather than failing later in the middle of a scan.

Deleting the project destroys the token.