What our 300-repository TS/JS scan did and did not show

\n\nAI has changed how software is built. It has not changed what production software must survive.

Founders are shipping faster. Agencies are delivering more work with smaller teams. Cursor, Claude Code, Copilot, Windsurf, and ChatGPT are turning rough ideas into working applications in days instead of months. That is real leverage. It is also a new operating pattern for security — one where a large slice of the codebase is generated, accepted, patched, and deployed inside a conversational workflow.

The old security model assumed code was mostly written by humans, reviewed by humans, and shipped through a process that at least pretended to be deliberate. The new model is different. Code may work, may pass tests, may even look clean — and still fail in recognizable ways that generic scanners were never designed to catch:

• It wires authentication and skips authorization.
• It uses permissive defaults because examples do.
• It suggests packages that do not exist.
• It leaks stack traces because that makes debugging easier.
• It uses Math.random() or timestamps in places that need cryptographic randomness.
• It copies example secrets, placeholder tokens, and test credentials into real code.
• It builds SQL strings using interpolation because the code is shorter.

Verglos was built to test that exact thesis. To make sure the thesis was defensible, we ran a bounded scan campaign against the population Verglos was built for.

The campaign, defined

Three hundred repositories were selected from the top of Verglos's ideal-customer profile: SaaS, admin dashboards, AI applications, agent frameworks, CRM/CMS/ecommerce, workflow automation, self-hosted business apps, and developer tooling. The list is bounded to TypeScript and JavaScript because that is what Verglos currently scans; the previous mixed-language sample is now retired.

Every target had at least 1,000 GitHub stars. The median star count landed in the tens of thousands. Real targets: n8n-io/n8n (198k stars), langgenius/dify (150k), Mintplex-Labs/anything-llm (64k), FlowiseAI/Flowise (55k), danny-avila/LibreChat (41k), appsmithorg/appsmith (40k), ToolJet/ToolJet (38k), Budibase/budibase (28k) — real production-relevant codebases the AI-era buyer is most likely to fork, ship, or embed.

The goal was not to produce a perfect academic benchmark. The goal was more practical:

If a founder, agency owner, or CTO used a fast security scanner built for AI-era software, would it find meaningful risk quickly enough to change behavior?

The answer was yes.

Public proof for this campaign is published in the Verglos CLI repository:

• Aggregate scan analysis
• Campaign summary report
• Selected per-repo HTML/JSON reports
• Methodology and source-query notes

The short version

We attempted to scan 300 repositories. 293 scans completed successfully. Seven failed during scanning — Node engine mismatches, unusable clones, oversized monorepos hitting the 180-second timeout, or scan-side hangs.

Across the 293 successful scans:

• Average security score: 69.2 / 100
• Median security score: 85 / 100
• 48 repos scored 100 / 100
• 127 repos scored 90+
• 114 repos scored below 70
• 24 repos scored 0
• 107 repos had at least one critical finding
• 145 repos had at least one high finding
• 169 repos had at least one critical or high finding

That is 57.7% of successfully scanned repos with a critical or high security finding. These are the codebases the AI-era buyer is most likely to fork, ship, or embed.

For reference, the prior mixed-language ICP top 300, scanned last quarter at verglos@1.5.1, came in at 45.6%. Two things changed between the runs — sample composition (mixed-language → TS/JS-only) and scanner version (1.5.1 → 1.5.2, which added a handful of Cryptography and Data Exposure detectors). So the 12-point jump is not a controlled comparison. It is a directional signal that the modal serious-finding rate in this population sits well above one-in-three.

The central finding of the research:

Serious security issues are the norm, not the exception, in the modern TypeScript and JavaScript app-layer. A codebase cannot be assumed safe because it is popular, active, well-designed, or technically impressive.

Security posture needs evidence.

What Verglos scanned for

Verglos is a security scanner built for AI-generated code. It does not only ask whether a dependency is vulnerable or whether a token appears in a file. It also asks whether the codebase shows AI-era failure modes.

The scan campaign covered these areas:

• Secrets
• Dependency vulnerabilities
• Git-history secrets
• Security misconfiguration
• Injection risks
• AI-generated code patterns
• AI provenance
• Slopsquat and hallucinated packages
• Dangerous package scripts
• Reportable risk scoring

The useful distinction is this. Traditional scanners mostly ask is there a known bad thing in this codebase? Verglos also asks does this codebase look like it was produced by an AI-assisted workflow, and are the risks clustered around the things AI commonly gets wrong?

That distinction matters because AI code does not merely create more of the same bugs. It creates a different operating pattern. The code arrives faster, often with less review, and with repeated failure modes that are specific enough to detect.

The numbers

Across all successful scans, Verglos reported:

• 633 critical findings
• 1,955 high findings
• 2,384 medium findings
• 847 low findings
• 8,883 informational findings

Findings by detector category:

Open data table

Category	Findings	Repos with ≥1
Cryptography	7,599	196
Data Exposure	3,216	163
Security Misconfiguration	1,904	194
Input Validation & Injection	1,035	89
Authorization	691	53
Dependency & Supply Chain	257	68

These totals are not equally severe. Some findings are informational, some are medium risk, and some deserve human review before being treated as confirmed vulnerabilities.

But the distribution is still commercially important. Security risk was not rare. It was not limited to abandoned toy projects. The scan repeatedly found patterns that would matter before client handoff, enterprise procurement, investor diligence, or production launch.

The most common serious patterns

The most common serious findings were not exotic. They were the mistakes that show up when a working prototype becomes production software too quickly:

• SQL built from string concatenation or unsafe dynamic query pieces
• Security-sensitive tokens generated with weak randomness
• API keys, private keys, and other credentials committed to source or history
• Wildcard CORS on backends that also expose authenticated routes
• Missing ownership checks on record lookups
• Server-side eval() and similar dangerous execution surfaces
• Stack traces and internal errors returned to HTTP clients
• Path traversal, XSS, SSRF, vulnerable dependencies, and hallucinated package names

The aggregate counts and category breakdown are published in the campaign analysis. The full pattern breakdown covers each shape with code examples and the model-behavior explanation.

This is exactly the kind of list that matters to a founder. Not because every single finding means the company is breached — static analysis does not work that way. The point is that these are the issues that block trust. They make a client ask harder questions. They make a technical buyer hesitate when the founder says we built this quickly with AI.

The buying question is not only has this been exploited? The more common buying question is can you prove you looked for the obvious risks before asking me to trust this software? That is where Verglos fits.

Popular does not mean safe

The scan found severe findings in repos that look mature from the outside.

Some examples from the campaign:

• n8n-io/n8n — score 0, with 37 critical and 47 high findings (HTML report, JSON)
• mastra-ai/mastra — score 0, with 59 critical and 41 high findings (HTML report, JSON)
• nocobase/nocobase — score 19, with 49 critical findings (HTML report, JSON)
• activepieces/activepieces — score 0, with 18 critical and 83 high findings (HTML report, JSON)
• nexu-io/open-design — score 0, with 124 high findings (HTML report, JSON)
• diegosouzapw/OmniRoute — score 0, with 18 critical and 102 high findings (HTML report, JSON)
• danny-avila/LibreChat — score 0, with 99 high findings (HTML report, JSON)
• steedos/steedos-platform — score 0, with 93 high findings (HTML report, JSON)
• teableio/teable — score 50, with 91 high findings (HTML report, JSON)

These results should be interpreted carefully. A static finding is not automatically a confirmed exploitable vulnerability. Context matters. Some findings may be mitigated elsewhere. Some may exist in development-only code, examples, fixtures, or unreachable paths.

But that caveat does not erase the business signal.

If a repo can look strong from the outside and still produce large numbers of critical or high-confidence static findings, then founders need a better default than trust-by-appearance. The new default should be trust-by-evidence.

Real examples, not just counts

The campaign did include concrete examples across mature open-source apps: permissive CORS on authenticated backends, unsafe dynamic SQL shapes, browser injection sinks, and credentials captured in git history or bundled assets.

The public artifacts include both the aggregate proof and selected report files: the campaign summary, selected HTML/JSON reports, analysis, and methodology. Teams that own affected code should run their own scan and review the current repo state directly.

AI percentage alone is not enough

Verglos also estimated AI-authored code indicators across repositories.

In this campaign:

• 104 repos had an AI-authored estimate of at least 20%
• 38 repos had an AI-authored estimate of at least 50%
• 38 repos had an AI-authored estimate of at least 90%

That is a real shift from the earlier mixed-language sample (71 / — / 24). The TS/JS-only, high-star cut leans harder toward the AI-assisted end of the market — unsurprising, since that is where recent starter kits, agent frameworks, and Copilot-style tooling now cluster.

This does not mean high AI usage automatically equals insecure software. Some high-AI repos scanned cleanly. Some low-AI repos had severe findings.

That is a critical point for positioning. Verglos should not shame people for using AI. AI-assisted development is not the problem. Unverified AI-assisted development is the problem.

The valuable line is not your code is AI-generated. The valuable line is:

Your AI-authored areas carry these specific risks, and here is a dated report proving they were checked.

That is the shift. AI provenance becomes useful when it is tied to security posture, risk density, and evidence.

Why this matters for founders

Most founders do not buy security because they enjoy security. Security is usually a grudge purchase. People care when something blocks them.

For AI-built software, the blockers are predictable:

• A client asks whether the app was tested before handoff.
• A larger customer asks for security evidence.
• A procurement team asks whether the product has a SOC 2 report.
• An investor asks whether the AI-built prototype is safe enough to put real users on.
• A technical cofounder or contractor leaves, and the founder needs to know what they inherited.

This is why Verglos should not be positioned as another scanner. The scanner is the free top of funnel. The product is the evidence.

The strongest positioning from this research is:

Verglos is the security evidence layer for AI-built software.

The scan tells you what is wrong. The report gives you something to show. The attestation turns the scan into a dated, verifiable artifact. That is what a founder can buy.

Why this matters for agencies

Agencies and dev shops are the strongest early buyer because they have a recurring gate: client handoff.

Every agency shipping AI-assisted work has the same silent anxiety: we delivered faster, but can we prove the code is safe enough to hand over?

A generic scanner gives them a pile of findings. That can help the developer, but it does not necessarily help the agency owner.

The agency owner needs:

• A clean report
• A score
• A summary a client can understand
• Proof that critical findings were checked
• A dated artifact for the project archive
• Ideally, a white-label report with the agency's brand and a third-party verification footer

That is not just security tooling. That is business infrastructure. It reduces handoff anxiety. It gives the client confidence. It lowers agency liability. It turns AI-assisted development from trust us into here is the evidence.

Why generic scanners miss the category

Snyk, GitHub, Semgrep, Socket, Gitleaks, TruffleHog, npm audit, and OSV all solve important problems.

But most of them were built around a different assumption: code is code, regardless of who wrote it.

Verglos starts with a different assumption:

If code was AI-generated or AI-assisted, the security model should account for that.

That assumption creates different product decisions:

• AI provenance is part of the report.
• AI-authored files can be scored separately.
• AI-specific patterns are first-class findings.
• Slopsquat detection matters before install, not only after dependency resolution.
• MCP guardrails can stop risky code before the agent writes it.
• The final artifact matters because the buyer needs proof, not just alerts.

This is the difference between a scanner and an evidence layer. The full comparison covers each of Snyk, GitHub AS, Semgrep, Socket, and Gitleaks / TruffleHog against Verglos on ten specific capabilities.

The product implication

The scan campaign validates the current Verglos business direction:

1. Keep the scanner free and fully unlocked.
2. Show file paths, line numbers, and findings for free.
3. Lead with AI provenance and AI-specific failure modes.
4. Build the paid product around attestation, verification, history, white-label reports, and remediation workflow.
5. Use MCP to move from after-the-fact scanning to before-write prevention.

The business should not depend on hiding findings. That would make Verglos feel hostile in a market where many scanners are free.

The business should depend on the thing free scanners do not give: signed, dated, verifiable security evidence for AI-built software.

What to do about it

If you own one of the affected codebases, or if you ship software built with an AI-in-the-loop workflow, the practical steps are short:

1. Run the scan yourself. npx verglos is free, local, and unlocked. Every finding, every domain, every line-number is visible without an account.
2. Read the report as a triage list, not a certification. Static findings need human judgment on reachability, mitigation, and dev-vs-prod scope. The report gives you the starting point.
3. Fix the crits first. Wildcard CORS on authenticated routes, Math.random for tokens, and hallucinated package installs are the fastest-to-fix, highest-blast-radius issues in most scans.
4. Archive the report at handoff. If you are shipping to a client, an acquirer, or a procurement lead, the archived scan is the artifact that turns trust me into inspect this.
5. Wire the scan into CI. Runs on every merge, catches regressions, and produces a dated evidence trail as a byproduct.

The big takeaway

AI-assisted development is not going away. It will become the default way software is built.

That means the market needs a new security ritual. Not a 200-page audit. Not a six-month compliance project. Not a tool that only a security team can operate.

It needs a fast, founder-readable check:

• What did AI likely write?
• What risky patterns are present?
• Are there critical or high issues?
• What must be fixed before launch or handoff?
• Can we prove this was checked?

That is the category Verglos can own.

The scan of 300 world-class TS/JS repos did not prove that every AI-built app is unsafe. It proved something more useful:

When we bounded the sample to the actual population Verglos is built for — the highest-star, most-forked, most-referenced TypeScript and JavaScript app-layer code — the critical-or-high rate climbed from 45.6% to 57.7%. Serious findings are the modal outcome. AI-built software needs an evidence layer by default.

That is the opening.

Methodology notes

• Sample. The 300 targets were selected by scoring 2,955 GitHub search candidates on: log-star base, ICP keyword hits (SaaS/starter/CRM/CMS/ecommerce/dashboard/AI/agent/MCP), recency, and penalties for awesome-lists / roadmaps / tutorials / interview prep. Only language:TypeScript and language:JavaScript repos survived the filter. Fork, archived, and disabled repos were excluded up-front.
• Scanner. verglos@1.5.2 run with --no-telemetry, one shallow clone per target, single-shot scan, clone deleted after each report.
• Reports. The public evidence package includes the aggregate analysis, campaign summary, and selected per-repo HTML/JSON reports.
• Comparison baseline. The prior mixed-language ICP 300 was scanned at verglos@1.5.1. Where numbers are compared to "last quarter," the reference is that campaign.
• Failed scans. 7 of 300 targets did not produce a report — Node engine mismatches, oversized monorepos hitting the 180-second timeout, or clones that returned no scannable JS/TS surface.

Where Verglos fits

The scanner is a free top-of-funnel. Every finding, every domain, every line — free forever. The product is the evidence layer above it: dated attestation reports, public verify URLs, white-label client reports, SBOM exports, and MCP integrations that stop risky code before an agent writes it. The full positioning is in the security evidence layer note. The pattern breakdown is in the AI vulnerability patterns note. The comparison against generic scanners is in Verglos vs Snyk, GitHub, Semgrep.

Run the check:

npx verglos

Local. No account. Report in under a minute. The evidence that the check happened is the point.\n