Check G3 · provenance family · severity HIGH · automatic · one of the 22 GitLab checks
The question this check asks: does this project's popularity match its provenance? Not how many stars — whether star_count makes sense against how old the owning namespace is and how old the project is.
Stars are a purchased commodity on GitHub: CMU's ICSE 2026 study identified around 6 million suspected fake stars there, at roughly half a yuan each. That figure is GitHub's. No measurement of purchased stars on gitlab.com is among the sources this page is built on, and it does not invent one. What the check relies on is not a market estimate but a contradiction that holds on any host: a star count is easy to buy, and years of unrelated public history on the namespace behind it are not.
Scale is the thing to hold in mind. The 100 most-starred gitlab.com projects on 19 September 2026 span 350 to 7,175 stars, from gitlab-org/gitlab-foss at the top down; for comparison, the GitHub project FakeGit impersonated carried 67,000. RepoGates keeps the same thresholds on both platforms — 200 stars is 200 stars — which makes the traction finding a larger claim on gitlab.com than on GitHub: a year-old namespace with more stars than the platform's 100th most-starred project.
G3 produces two findings from the project record, weighted very differently, and both are the C3 page's rules on gitlab.com's fields: star_count stands in for stargazers_count, the project's created_at is the same field, and the namespace's age is the one G1 reads.
Traction mismatch. More than 200 stars on a namespace under a year old fires at severity HIGH and costs 20 points: the verdict reads REVIEW, the download is held, and the finding says “N★ on an account Nd old — check for purchased stars”. Both thresholds are policy parameters. One GitLab consequence follows from the input: the finding needs the namespace's age, and on a user-owned project without a GITLAB_TOKEN that age is not readable — so on such a project traction mismatch cannot fire, and G1 is listed as not checked to say why. A group-owned project has the input anonymously.
Star velocity. Stars arriving faster than twenty a day over the project's life, on a project with more than 300 stars, fires at severity MEDIUM and costs 4 points — and the default personal policy does not act on it. It is on the board as “N★ over Nd — implausible organic rate”; the download proceeds. It needs only the project record, so it runs on every gitlab.com project, token or not.
Neither fired on the 100 most-starred gitlab.com projects on 19 September 2026: the youngest was 627 days old and the largest count 7,175, a rate well under twenty a day, and the youngest group namespace was 514 days old. Neither finding blocks on its own; a fresh namespace with a sudden thousand stars is a BLOCK because of G1, with this check as the corroboration.
Hot projects. On GitHub, 24 of the 80 most popular repositories tripped the velocity finding in the Phase 0 controls, because a project that lands on the front page of Hacker News gains far more than twenty stars a day; that measurement is why velocity is 4 points and not acted on by default. On gitlab.com's top-100 it tripped nothing, and that is a fact about scale, not about the check: 7,175 stars over a project lifetime of years is a handful a day. The case traction mismatch cannot distinguish is the same on both hosts — a genuine first project by a new developer that takes off. The board shows the star count and the namespace's age in days, and the decision is yours.
Fakes that do not buy stars. On GitHub, the 2026 FakeGit repositories carried a few dozen stars each and none of the ones the provenance checks missed had more than 200, so there was nothing for traction mismatch to catch; the fresh-account half fell to the account-age check. The only gitlab.com pattern in the 2024–2026 record — recruiter-lure projects a victim is told to clone and run — does not need stars at all, because the victim arrives by invitation, not by search. Stars bought slowly on an old namespace pass both thresholds by construction. The check counts stars; it does not examine who starred, so a purchase that stays under the thresholds is invisible to it. And on a user-owned project without a token, the traction finding is not merely quiet but absent, as stated above.
RepoGates runs the same 22 checks on a gitlab.com project that it runs on a GitHub repository, from gitlab.com's public API, under the key gl/{namespace…}/{project}. What that API withholds from an anonymous caller — fork status, a user namespace's account age, and OpenSSF Scorecard, which does not cover gitlab.com — is listed as not checked, never assumed. A self-managed GitLab is another hostname and is not assessed. The repository's code is not read on this tier: a PASS means the provenance and the declared execution surface are clean.
Without installing anything: the project record answers the count and the date in one GET — the path URL-encoded — and a group's record answers its own:
curl -s 'https://gitlab.com/api/v4/projects/NAMESPACE%2FPROJECT' | jq '{star_count, created_at}'
curl -s 'https://gitlab.com/api/v4/groups/GROUP?with_projects=false' | jq .created_atHundreds of stars on a namespace created this year is the question. For a user namespace, the profile page's Member since is the date; the user record's created_at needs a token.
Are a lot of stars proof that a gitlab.com project is safe? No. Stars are a purchased commodity — CMU's ICSE 2026 study identified around 6 million suspected fakes on GitHub, and this page has no gitlab.com figure to set beside it. What is hard to buy is years of unrelated history on the namespace behind the project. That is why RepoGates weighs namespace age far more than stars and treats stars mainly as a contradiction to look for, with the same thresholds on both platforms.
My project took off this week — does that count against it? Barely. Stars arriving faster than twenty a day fire the velocity finding, which costs 4 points and which the default policy does not act on; on gitlab.com's scale, where the 100th most-starred project has 350 stars, that rate is rare. Only stars on a young namespace — more than 200 on one under a year old — cost 20 points and hold the download for a look, and that finding needs the namespace's age, which a user namespace gives only to a token.
Does RepoGates hold a download from gitlab.com in the browser? Not yet. The extension does not run on gitlab.com pages; the board and the download hold there are a later, separate store release. Today a gitlab.com project is assessed on request — through the verdict API (GET /v1/gl/score/{path}), the MCP server (check_repo with platform="gl") and the preflight, which judges a command line that names a gitlab.com project: git clone https://gitlab.com/…, glab repo clone, or a pasted project, archive or release-download URL.
C3 Star velocity and traction — the GitHub original · G1 Owner account age — the signal this one corroborates, and the input it needs · G2 Repository age — the other half of the velocity ratio · G4 Fork and lookalike — what bought stars are usually promoting.
Add RepoGates to Chrome Pricing
Numbers on this page: the 19 September 2026 measurement of the 100 most-starred gitlab.com projects, run anonymously through the same code as /v1/gl/score; CMU, ICSE 2026 (suspected fake stars on GitHub); Island, July 2026 (star counts on FakeGit repositories); the C3 page's Phase 0 controls where GitHub is cited; thresholds and weights from the product's policy and scoring tables.