Check G4 · provenance family · severity HIGH · automatic · one of the 22 GitLab checks
The question this check asks: is this the authentic project from its authorised source — or a fork of it, under someone else's namespace, that you reached by search or by recommendation?
The OpenSSF's Verify Authenticity rule says to confirm you have the authentic version from the authorised source and not a personal or attacker-controlled fork, and to reach the project from its own website rather than from search results or an AI recommendation. A fork is a complete copy with one difference you cannot see from the file list: whoever owns it can add a commit. A personal fork is usually months behind and harmless. A fork with one extra commit in the build script is the classic shape of a supply-chain substitution, and its README is identical to the original's because it is the original's. None of that changes with the host.
What the record shows for gitlab.com is thinner than for GitHub. No typosquat, fake-maintainer or trojanised-release campaign specific to gitlab.com was found in the 2024–2026 primary write-ups; the one documented pattern is North Korean loader projects delivered by recruiter lure, where the victim is invited rather than misled by a name. So the impersonation half of FakeGit — repositories borrowing the names of real projects, real AI Skills and real MCP servers — has no gitlab.com counterpart in the record, and this page does not claim one. The GitLab intelligence page has what is known.
G4 reads the project's fork relation — on GitHub the fork flag and its parent, on gitlab.com forked_from_project. A fork fires at severity HIGH and costs 15 points, so a project that trips nothing else scores 85, the badge stays green, the verdict reads REVIEW, the finding names the upstream (“this is a FORK of namespace/project — verify you want the fork, not upstream”), and proceeding is one click, recorded. It never blocks on its own. That is the C4 page's rule, unchanged.
What changes is the input. gitlab.com strips forked_from_project from the project record it gives an anonymous caller — measured on 18 September 2026, where the unauthenticated record carried 22 keys with the licence and no fork field, and every entry of a project's own /forks list lacked it too. A missing field is not a false one. So on this tier RepoGates does not set the flag to false and pass the check: it records the note “fork status unavailable — not part of the unauthenticated project record”, lists G4 as not checked, and the verdict says so rather than saying “not a fork”. On the 100 most-starred gitlab.com projects on 19 September 2026 that was the outcome on all 100. Whether a GITLAB_TOKEN restores the field has not been measured; if it does, the check runs as on GitHub.
Every legitimate fork — a maintained community fork of an abandoned project, a distribution's packaging fork, a colleague's branch — fires this check where it runs, and no flag can tell them from a substitution. That is why it is a warning at 15 points and not a block, and why the finding always carries the parent's name: the comparison is one click, and the decision is yours. On gitlab.com today the practical false-positive rate is zero for the wrong reason — the check is not running — and this page would rather say that than count it as clean.
Lookalike names. The check reads a fork relation. A fresh project named one letter away from a real one, in a namespace that looks like the real one, is not a fork and does not fire — on GitHub the Phase 0 measurement found C4 fired on none of the 7,648 FakeGit repositories for exactly that reason. On gitlab.com there is not yet a known-names list to compare against, so the lookalike half of this check's title is a roadmap item on both platforms, and this page will change when it ships. Until then a lookalike on gitlab.com is caught, if at all, by the namespace's age — where it is readable — by a release asset, and by where the link came from.
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, from the candidate's own record: you cannot — the anonymous record does not carry the field. The question is answerable from the other end. Take the project you believe is the original and page through its forks; the candidate is either in that list or it is not:
curl -s 'https://gitlab.com/api/v4/projects/UPSTREAM%2FPROJECT/forks?per_page=100' | jq '.[].path_with_namespace'Then, per the OpenSSF rule, reach the project from its own website or its package on a registry you already trust, and download from whatever project that links to. A search result or an assistant's answer is where you started, not where you verify.
Is a fork dangerous? Not in itself — forking is how open source works. The risk is downloading a fork when you meant the original: a personal fork that is months behind, or an attacker-controlled fork with one extra commit. That is why the check warns rather than blocks — 15 points, a REVIEW — and names the upstream so you can compare. On gitlab.com it can only do that where the fork field is readable, which today means with a token, if a token restores it.
Why does every gitlab.com project say not checked on G4? Because the field the check reads, forked_from_project, is not part of the project record gitlab.com gives an anonymous caller — measured on 18 September 2026 and again on all 100 of the most-starred projects the next day. RepoGates does not treat a missing field as “not a fork”; it lists the check as not checked with the reason, and the verdict is built from the checks that ran. Whether a GitLab token restores the field has not been measured.
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.
C4 Fork and lookalike — the GitHub original · G1 Owner account age — the check that would catch an impersonating namespace, where its input is readable · G3 Star velocity and traction — stars that outrun the namespace, the bought-popularity variant of impersonation · G22 AI-agent provenance — when the lookalike reached you through an assistant.
Add RepoGates to Chrome Pricing
Numbers on this page: the anonymous gitlab.com API reads of 18 September 2026 and the 19 September 2026 measurement of the 100 most-starred gitlab.com projects, run through the same code as /v1/gl/score; the C4 page's Phase 0 result where GitHub is cited; OpenSSF Verify Authenticity; weights from the product's scoring table.