Counted from our database · refreshed every 5 minutes

Audit AI in numbers

What the open-source scanner has actually seen on auditai.sh, counted by one SQL query and shown unedited. Our own test repositories are left out. Small numbers stay small here.

As of 12 Sep 2026, 00:23 UTC · counting since 11 Sep 2026

What the scanner has looked at

1public repositories scannedDistinct GitHub repositories. Each one counts once, however often it was scanned.

1scans run1 pasted into auditai.sh and 0 pull-request checks by the GitHub App, one per push.

17entry points analyzedRoute handlers, server actions and dynamic pages found in the latest scan of each repository.

7database queries tracedSupabase, Drizzle and Prisma calls reachable from those entry points: the code the rules actually check.

What the rules found

2open findingsRule matches in the latest scan of each repository, minus the ones the repository marked as intentionally ignored. The scanner marks every one "likely": a rule matched and nothing in the code contradicted it. None is proven until a sandbox proof runs.

2high severity100% of open findings. A safety net such as row level security is off or lets too much through.

By rule

Rule	Findings	Share	Real / false positive / unsure	Precision from votes
`supabase.mass-assignment-from-request-body`Writes the request body into a table without an allow-list of columns.	1	50%	no votes	no decided votes yet
`supabase.rls-policy-without-caller-predicate`Has an RLS policy that lets rows through without checking the caller.	1	50%	no votes	no decided votes yet

Share is the rule's part of all open findings. Precision is real ÷ (real + false positive), from votes on report pages; unsure votes are listed but never counted. n is the number of real and false-positive votes behind a figure. Votes on earlier scans of a repository count too, so a rule can have votes and no open findings.

Sandbox proofs

A finding is proven only when we reproduce it. "Prove it" on a report runs the app in an isolated sandbox with two synthetic tenants and tries the attack before and after the fix.

Nobody has requested a proof yet. Until someone does, every finding above stays "likely".

Are the findings real?

Anyone reading a report can mark each finding as real, false positive or unsure. This is the public, self-reported view of precision; it is not checked by us, and people who vote are not a random sample.

No votes yet. The first ones will show up here, next to the rule they are about.

Methodology

What is counted

Scans stored by auditai.sh: public GitHub repositories pasted into the site, and GitHub App checks on pull requests of public repositories. Every figure comes from one read-only SQL query over scans, proof requests and votes.
Entry points, queries and findings use the latest scan of each repository, so re-scanning does not inflate them. "Scans run" counts every scan.
A finding is a match of one of the open-source rules. Nothing on this page comes from a language model.
Proofs come from the "Prove it" queue; votes from the buttons on report pages.

What is left out

Our own repositories: everything under github.com/audit0, including the intentionally vulnerable test apps we scan on every change.
Findings a repository suppressed with an auditai:ignore comment.
Private repositories: never stored, never counted. Scans in the CLI or in Claude Code and Cursor through MCP run on your machine; we never see them.
Anything that identifies a repository: no names, links or code on this page.

The rules, and a vulnerable and a secure test app for each, are open source: what each rule catches · rule source. Numbers are regenerated at most every five minutes.

Add your repository to these numbers

Public repositories, read-only, no sign-up.

Scan a public repository