We Scanned 300 Open Source Repos. Nearly Half Had Critical or High Security Findings.

AI has changed how software gets built. It has not changed what production software must survive.

Founders are shipping faster. Agencies are delivering more work with smaller teams. Developers are using Cursor, Claude Code, Copilot, Windsurf, ChatGPT, and other AI coding systems to turn rough ideas into working applications in days instead of months.

That is real leverage. It is also a new kind of security problem.

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. A large amount of software is now generated, accepted, patched, and deployed inside a conversational workflow. The code may work. It may pass tests. It may even look clean.

But AI-generated code fails in recognizable ways:

• 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.

We ran a scan campaign across 300 public repositories in the startup, SaaS, admin dashboard, AI app, commerce, CMS, CRM, automation, and developer-tooling space. 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.

The Short Version

We attempted to scan 300 public repositories.

294 scans completed successfully. 6 failed during scanning.

Across the 294 successful scans:

• Average security score: 80.4 / 100
• Median security score: 96 / 100
• 100 repos scored 100 / 100
• 170 repos scored 90+
• 71 repos scored below 70
• 16 repos scored 0
• 73 repos had at least one critical finding
• 107 repos had at least one high finding
• 134 repos had at least one critical or high finding

That means 45.6% of successfully scanned repos had critical or high security findings.

This is the central finding of the research:

Serious security issues are common even in public, polished, product-like repositories. A founder cannot assume that a repo is 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:

• 395 critical findings
• 1,195 high findings
• 3,076 medium findings
• 428 low findings
• 3,252 informational findings

The most common detector categories were:

• Misconfiguration: 4,914 findings across 171 repos
• Secrets: 1,774 findings across 96 repos
• Injection: 772 findings across 67 repos
• AI patterns: 575 findings across 84 repos
• Dependencies: 218 findings across 60 repos
• Slopsquat: 18 findings across 13 repos

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 top critical findings included:

• SQL injection from string concatenation
• Exposed database URLs
• Exposed private keys
• Predictable tokens generated from Date.now()
• Predictable tokens generated from Math.random()
• Command injection through exec
• Secrets in git history
• Non-existent npm packages

The top high findings included:

• Use of eval()
• IDOR, where records are looked up by user-supplied IDs without ownership checks
• Exposed generic API keys
• Stack traces or error messages leaked in HTTP responses
• Wildcard CORS configuration
• Dynamic innerHTML usage
• Mass assignment from request bodies
• Vulnerable dependencies

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 are the issues that make a client ask harder questions. They are the issues that 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 38 critical and 47 high findings
• mastra-ai-mastra: score 0, with 75 critical and 39 high findings
• BuilderIO-builder: score 34, with 154 high findings
• medusajs-medusa: score 6, with 7 critical findings
• getsentry-sentry-javascript: score 14, with 9 critical findings
• nocobase-nocobase: score 19, with 49 critical findings
• labring-FastGPT: score 0, with 21 critical findings
• steedos-steedos-platform: score 0, with 93 high findings

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.

AI Percentage Alone Is Not Enough

Verglos also estimated AI-authored code indicators across repositories.

In this campaign:

• 71 repos had an AI-authored estimate of at least 20%
• 24 repos had an AI-authored estimate of at least 90%

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 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.

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 repos did not prove that every AI-built app is unsafe. It proved something more useful:

Serious security findings are common enough that AI-built software needs an evidence layer by default.

That is the opening.

Suggested Social Hooks

• We scanned 300 public repos. 45.6% had critical or high findings.
• AI code is not the problem. Unverified AI code is.
• The next security category is not another scanner. It is evidence for AI-built software.
• Founders do not need 400 findings. They need to know what blocks trust.
• Agencies using AI need a client handoff artifact, not another dashboard.

Suggested CTA

Run:

npx verglos

Get a security score, AI-provenance signal, and a local report in under a minute.