Check G1 · provenance family · severity CRITICAL · automatic · one of the 22 GitLab checks
The question this check asks: how old is the gitlab.com namespace that owns this project? Not the project — the group or user account behind it. A project can be new for good reasons; a maintainer who did not exist three months ago is a different kind of new.
Account age is check number one on GitHub because the FakeGit campaign of 2026 ran on roughly 6,600 fabricated accounts, most of them created shortly before the repositories they owned. An account with no prior public history is the cheapest thing in that operation to manufacture and the hardest to hide: created_at is a public field and it does not backdate. G1 is the same check, run by the same code, on a gitlab.com project. The reasoning carries over. The numbers do not, and this page does not borrow them.
They do not carry over because no gitlab.com campaign of the FakeGit shape exists in the 2024–2026 record. What GitLab's own threat-intelligence team published on 19 February 2026 is a different pattern: 131 accounts banned in 2025 for distributing North Korean malware through recruiter lures — an average of 11 a month, signed up with Gmail addresses in almost 90% of cases — and in more than 80% of those projects the payload was not on gitlab.com at all, only a concealed loader that fetched it from elsewhere, most commonly Vercel. GitLab did not state how old those accounts were. So there is no catch rate to publish for this check on GitLab; the GitLab intelligence page has what is known, and nothing more.
G1 reads the owning namespace's created_at and compares it with two thresholds. A namespace under 90 days old is CRITICAL and costs 45 points — a BLOCK on its own under the default personal policy, the finding reading “maintainer account is N days old — FakeGit used ~6,600 fresh accounts”. A namespace under a year old is HIGH and costs 18 points — a REVIEW at 82, the badge still green, the gate warning rather than blocking. Both thresholds are policy parameters (owner_age_crit_days, owner_age_high_days); the strict organisation profile raises the critical line to 180 days. All of that is the C1 page's, unchanged.
What changes is where the date comes from. A gitlab.com project belongs to a group or to a user, and the two answer an anonymous caller differently. A group's record (/api/v4/groups/:id) returns created_at to anyone, and G1 reads it — the namespace the project sits in directly, so for a project inside a subgroup it is the subgroup's date. A user's record (/api/v4/users/:id) answers 403 without a token, and the public users list carries no creation date. On a user-owned project the check therefore has no input, and the report says so: G1 is listed as not checked, with the reason “owner account not visible — a user namespace's age needs a GitLab token”. That row is not a PASS; it is an absence, stated, and the verdict does not assume the account is old. With a GITLAB_TOKEN (a personal access token with read_api) on the backend the user record is read as well, and the check runs on both kinds. A group-owned project needs no token.
Measured on 19 September 2026 over the 100 most-starred gitlab.com projects, anonymously, through the same code as /v1/gl/score: 71 are group-owned and G1 read all 71 — the youngest group was 514 days old, the median 3,034 — so the check fired on none; the other 29 are user-owned and were listed as not checked, exactly the 29. The same engine on GitHub's 100 most-starred repositories the same day blocked one of them on this check, an owner account under the critical age.
A newcomer's first project — the same case as on GitHub, where 50 young, legitimate, well-starred repositories produced 3 critical-grade hits, the 6% cost the C1 page states. No young-legitimate control has been run on gitlab.com: the top-100 has no project under 627 days old and says nothing about newcomers. The check cannot tell a fresh account with a real project from a fabricated one, because on the day of the download there is no difference to see. What it does is put the number on the decision — “maintainer account is 41 days old” — so the judgement is yours, and an override records the reason on your machine.
A second case is GitLab's own shape: a group created last week by an organisation that has been on gitlab.com for a decade is still a week-old namespace, and fires. G1 reads the age of the namespace that owns the project, not of the people in it or of the parent group above it. Groups nest up to 20 levels deep on gitlab.com; the date read is the innermost one's.
Aged, purchased or compromised accounts, exactly as on GitHub, where roughly half of the FakeGit campaign sat on accounts with years of prior history and passed this check by construction. On gitlab.com the more pressing gap is the one above: without a token, every user-owned project goes through G1 unread. A fabricated user account meets this check as a listed skip, not as a finding, until a GITLAB_TOKEN is set — and that is the only thing that closes the gap. The rest of the operation, whatever the account's age, is the job of the release-asset check, the execution-surface checks and the agent-surface checks.
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: a user namespace's profile page at gitlab.com/USERNAME says Member since and the month. A group's record answers to anyone, so open it in a tab or ask from a shell — a subgroup's path is URL-encoded, gitlab-org%2Fsecurity-products:
curl -s 'https://gitlab.com/api/v4/groups/GROUP?with_projects=false' | jq .created_atA user's created_at needs a personal access token — the public list gives the id, the signed-in record gives the date:
curl -s 'https://gitlab.com/api/v4/users?username=USERNAME' | jq '.[0].id'
curl -s -H 'PRIVATE-TOKEN: TOKEN' https://gitlab.com/api/v4/users/ID | jq .created_atThen compare with the project's own created_at. A namespace and a project created in the same week, with nothing else in the namespace, is the shape this check exists for. A group created in 2013 — gitlab-org's was — is not; and if it is still shipping something you do not trust, that is what the other 21 checks are for.
Does a new gitlab.com account mean the project is malicious? No. Every developer's first project sits on a new account, and on the day of the download the check cannot tell a first project from a lure. On GitHub the same threshold cost 3 of 50 young, legitimate, well-starred repositories a block — 6%, stated rather than hidden; on gitlab.com's 100 most-starred projects no group owner was under a year old, and no newcomer control has been run. The decision shows the namespace's age in days so you can judge it, and an override records why.
Why is a user namespace listed as not checked? Because gitlab.com does not tell an anonymous caller when a user account was created: /api/v4/users/:id answers 403 without a token, and the public users list has no created_at. A group's record answers it to anyone. In the top-100 run the 71 group-owned projects were read and the 29 user-owned were listed as not checked — never as “old enough”. A GITLAB_TOKEN with read_api on the backend makes the user record readable too.
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.
C1 Owner account age — the GitHub original · G2 Repository age — the project rather than the namespace; 12 points, HIGH · G3 Star velocity and traction — stars that outrun the namespace's age, a finding that needs this check's input · G9 Release-asset binaries — the delivery path this check cannot see.
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, and the same-day GitHub top-100 control; GitLab Threat Intelligence, 19 February 2026; the C1 page's Phase 0 figures where GitHub is cited; thresholds and weights from the product's policy and scoring tables.