Method
How the public reports were produced.
Each report comes from cloning a public repository at one commit, running the same analysis a customer runs, and publishing the result through a narrower projection — a separate function that has no field a security detail could travel in. Nothing about the method is specific to the projects chosen.
The steps
Cloned at one commit, and the commit is recorded
A shallow clone of one commit, into a directory this repository refuses to commit. Eight of the projects are pinned in our measurement corpus, so their reports are reproducible against a recorded result; for the rest the commit resolved at clone time is what the page shows. A report whose commit could not be determined is not published, because a page nobody can check against a version is a page nobody can correct.
Scanned with the engine a customer runs
The same adapters, the same rules, the same coverage accounting. Nothing is tuned per project and no finding is removed by hand — if a report reads badly, that is the output, and it is more useful to us published than hidden.
Projected through the public contract
Architecture and performance findings travel in full, with the file and the line. The security section carries counts by severity and nothing else: no path, no line, no symbol, no rule name, no fix. It is a different function from the one that builds a customer’s own report rather than a filter applied to it.
Checked, then published
The projected document is scanned for anything that should not be in it before anything is written. A separate gate proves the same thing on a fixture with a planted credential: the value, the file and the rule are all absent from what comes out.
When it refuses to publish
- Below 70% of calls traced. No map is drawn below that, and a page saying “we could not read enough of this project” reads as a verdict on their code when it is a statement about our reader.
- Any security detail surviving the projection. The publish stops on the document, not on the page.
- A page over the size ceiling. A report is a document, not a download.
- A repository whose maintainer has asked for removal. The row stays, marked removed, exactly so the script cannot cheerfully recreate the page on its next run.
A report also shows at most 25 findings of a kind and 120 parts of the architecture. Where a list is capped the page says so and prints the total separately, because a capped list is never a total.
How the projects were chosen
Widely used Next.js, Node and Python projects across a range of sizes, each with a written reason for being on the list. The list is a file in the repository rather than a decision in somebody’s head, and the repositories our measurement corpus holds back for honest accuracy numbers are deliberately not on it.
None of their code is in this repository, and none of it ever will be. What we keep about somebody else’s project is a name, a URL and a sentence about why it is here.
If you maintain one of these projects
This report was produced by scanning the public repository. Security findings are shown as counts only — no file, no line, no detail. If you maintain this project you can ask us for the detail, or ask for this page to be taken down, and we will do either. Ask us for the detail · Ask for a page to be removed
Why publish these at all
A demo is chosen by the person demonstrating. These are not: the projects are well known, the commit is on the page, and anybody can run the same analysis on the same code and disagree with us in public.