The Vibe Security Index

Vendored scaffold — counted, published, not attributed

These figures are excluded from every other number on this page. They are here so you can check the size of what we removed rather than take our word for it.

Do not read this column as a security ranking. It measures how much of a component library each builder copies in. A builder that scaffolds the full shadcn/ui suite inherits the two files that generate nearly all of these findings; one that ships a handful of hand-rolled primitives inherits none of them. A 0% rate here means the builder vendors less code, not that it writes safer code — and since most of what is in this column is our own false positive, a high rate is closer to a statement about our rules than about anyone's security.

What this does not tell you

• Attribution is scaffold-level, not authorship-level. The marker proves the project was created from the builder's scaffold; it does not prove every line was generated by it. Humans edit these repos afterwards, and some of what is measured is human-written.
• The sample is public GitHub only. Apps that were never pushed, were pushed privately, or were deployed straight from the builder without a repo are invisible, and there is no reason to assume they are similar.
• GitHub code search caps at 1,000 results per query, so for builders with a larger universe the sample is drawn from the first 1,000 results in GitHub's relevance order, not uniformly at random from the whole universe.
• The 'vendored' bucket is broader than the word suggests: it covers copied UI component libraries, markdown documentation and committed AI-agent tooling directories — everything the builder's code generation is not accountable for. Those findings are reported, not discarded.
• Static analysis has false positives. Findings are not confirmed exploits, and a critical finding is a thing a human should look at, not a proven breach.
• Project size is a confound and it is not small: median scanned files per repository ranges from 57 (Bolt) to 113.5 (Lovable). A smaller project has fewer places for a critical finding to occur, so a builder whose users ship smaller apps scores better on every rate here without necessarily generating safer code. The per-builder median is published in the sample table so this can be read directly rather than inferred.
• The vendored-critical column is a fact about scaffold composition, not about security. It largely reflects how much of a component library each builder copies in: a builder that ships the full shadcn/ui suite inherits the two files that generate nearly all vendored findings, while one that ships a few hand-rolled primitives inherits none. A 0% vendored rate means the builder vendors less code, not that it produces safer code.
• Some rules fire on scaffold files the builder ships unmodified (a missing Content-Security-Policy on the stock index.html, for instance) where the real control lives in host headers the scanner cannot see. Those inflate the high-severity counts for every builder roughly equally and do not affect the critical-severity headline.
• Per-repo rows are anonymized by design. The numbers are reproducible by re-running the pipeline; the individual repositories behind them are deliberately not recoverable, because publishing them would disclose live vulnerabilities in other people's projects.
• Files over 1.5 MB are skipped, and repositories are scanned up to 8,000 files. 2 of 178 repositories hit the file cap and were measured partially, which understates their finding counts.
• Round size: 178 repositories across 4 builders. Differences of a few percentage points between builders are inside the noise of a sample this size.

The three that most change how the leaderboard should be read are repeated directly beneath it, because the limitations are the part most likely to be dropped when a chart gets screenshotted. This is the complete list.