We Scanned 10 of the Biggest JavaScript Repos. Here's What We Found — Including Our Own Mistakes.

Before launching Thuban, we pointed it at Express, Next.js, Strapi, Signal Desktop and six more of the most popular open-source projects in the JavaScript ecosystem. This is the full, honest breakdown: the real findings, the borderline calls, and the five categories of false positives we found in our own scanner — and fixed before publishing this.

*9 production repos + OWASP Juice Shop, which is intentionally vulnerable and counted separately (see below).

Why we're publishing our own scanner's mistakes

Every developer's first objection to a code scanner is the same: "it's probably all false positives." Fair. Most scanners earn that reputation.

So instead of cherry-picking our best results, we're showing you the whole audit — including the moment our scanner flagged 213 issues in cal.com and 196 of them were wrong. We fixed the root cause, re-scanned, and cal.com dropped to 26 legitimate findings. That fix — and four others like it — shipped before this post did.

The results

*OWASP Juice Shop is a deliberately vulnerable training application. Thuban correctly flagged its planted vulnerabilities — a validation of detection capability, not a finding against the project. It is excluded from the 1,956 headline count.

The findings that matter

Strapi: SSL certificate validation disabled REAL

examples/complex/scripts/setup-v4-project.js — when database SSL is enabled, certificate validation is turned off:

ssl: env.bool('DATABASE_SSL', false)
  ? { rejectUnauthorized: false }
  : false,

This permits man-in-the-middle attacks on the database connection. Important context: this is in an example setup script, not Strapi's production runtime — but setup scripts get copy-pasted into production configs constantly. The fix is one line: rejectUnauthorized: true or a proper CA certificate.

Express: XSS-shaped patterns in official examples BORDERLINE

res.send('users ' + names.slice(from, to + 1).join(', '));

The specific example isn't exploitable — the output comes from a hardcoded array. But res.send(user_influenced_data) without sanitisation is the exact pattern that becomes reflected XSS when a developer swaps in real data. Express examples are how millions of developers learn Node. Of 25 taint findings in Express, 23 were in test files (expected); 2 were in examples.

Express: hardcoded password in the auth example EXPECTED

hash({ password: 'foobar' }, function (err, pass, salt, hash) {

Example code with hardcoded credentials gets copy-pasted. The comment says "foobar is the pass here" — but how many people change it?

n8n: 295 magic numbers NOISE

Our magic-number rule fired on JSON configuration files, which are naturally full of numbers. That's a scanner limitation, not an n8n problem — it's on our fix list for v0.4.7. We're counting it against ourselves, not them.

The 5 false positives we fixed in our own scanner

This is the section most scanner vendors would delete. We think it's the most important one.

What's still on our fix list

Full transparency — four known false-positive categories remain, targeted for v0.4.7:

Until then, any finding can be suppressed with // thuban-ignore.

What this proves

1. The scanner finds real issues. A genuine SSL misconfiguration in a 65k-star project's tooling. XSS-shaped teaching patterns in the framework everyone learns from. And it correctly identified every planted vulnerability in OWASP's deliberately vulnerable training app.

2. It's fast. 951 files, 10 repos, 19.8 seconds total. Roughly 2 seconds per repo.

3. We eat our own dog food. Five false positive categories found, fixed, and disclosed — before launch, not after your bug report.

Methodology: Thuban v0.4.6, default ruleset (69 rules), capped at 100 files per repo, scanned July 2026 from each repo's default branch. Juice Shop findings excluded from headline counts as intentional. Strapi finding disclosed to their security team prior to publication. Questions or corrections: we want them — open an issue.