Check G2 · provenance family · severity HIGH · automatic · one of the 22 GitLab checks
The question this check asks: how old is this project at the moment you are downloading from it? Not the namespace — the project, from its own created_at in the gitlab.com project record.
A campaign has to make its repositories fast. On GitHub, FakeGit was creating roughly 300 AI-themed repositories a month at its April 2026 peak, and a victim met most of them within weeks of their creation — they needed to exist only long enough to be found, downloaded from, and taken down. That is why a young repository is worth a warning, and why the check is about the moment of encounter, which is the moment the verdict runs.
On gitlab.com the record is thinner, and this page says so. No gitlab.com campaign of the FakeGit shape exists in the 2024–2026 primary record; what GitLab's own threat-intelligence post of 19 February 2026 describes is 131 accounts banned in 2025 for North Korean malware distribution through recruiter lures, an average of 11 a month, with the payload off gitlab.com in more than 80% of cases. GitLab did not publish how long those projects lived, so there is no catch rate to publish for this check on GitLab, and the C2 page's 266 hits are GitHub's. The GitLab intelligence page has the whole of what is known.
It is the weaker sibling of the namespace-age check, and deliberately so: a new project is ordinary, a new maintainer with a popular project is not.
G2 reads the project's created_at — the same field, under the same name, in gitlab.com's project record as in GitHub's. A project under 30 days old fires at severity HIGH and costs 12 points; a project that trips nothing else scores 88, the badge stays green, the verdict reads REVIEW, the finding says “repository created N days ago”, and proceeding is one click, recorded. It never blocks on its own. The threshold is a policy parameter (repo_age_high_days, 7 to 180); the strict organisation profile sets 90. The evidence note in the scoring table is the C2 page's — “young repos are risky but common” — and the reasoning is unchanged: youth of the project alone was common enough on GitHub to be worth a warning and no more.
Measured on 19 September 2026 over the 100 most-starred gitlab.com projects, anonymously, through the same code as /v1/gl/score: the youngest was 627 days old and the median 3,025, so the check fired on none of them. That is the expected result on a top-100 by stars and not evidence about young projects; it says only that the date is read correctly and that the check is quiet where it should be quiet.
Every project, for its first month, on any host. There is no way to tell a three-week-old project from a three-week-old lure by the date, and the check does not try — it puts the number on the board so the other checks, and you, can weigh it. A young project in a group that has been on gitlab.com for years is the normal case and the gate merely mentions it. A young project in a young namespace is where the namespace-age check takes over — with one GitLab wrinkle: on a user-owned project without a token that check is listed as not checked, so a young project on a young user account reads as a REVIEW on this check alone, not a BLOCK. A GITLAB_TOKEN restores the pair.
Old projects with new contents. A project created years ago and repurposed — its history rewritten, or a release attached last week to something dormant — passes this check by construction. Age says nothing about what is in the tree or on the releases page; the release-asset check and the execution-surface checks are about content, and this one is not. A project transferred into a new namespace keeps its original creation date, so a transfer is invisible here too. And the one gitlab.com-hosted pattern in the record — a loader project that fetches its payload from elsewhere the moment it is run, the trigger a global invocation in a file executed as soon as the project runs, in GitLab's words — is not an age question at all; no creation date can see it.
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 is a plain GET that a browser tab can open — the path is URL-encoded, / as %2F — and it carries the three fields worth reading together:
curl -s 'https://gitlab.com/api/v4/projects/NAMESPACE%2FPROJECT' | jq '{created_at, last_activity_at, star_count}'Then compare created_at with the namespace's: a group's record answers it to anyone, a user's profile page says Member since. Created in the same week as the namespace, with a release already attached, is the shape this check exists to mention.
Is a new project a risk? Every project is new for its first thirty days, so on its own the answer is no — which is why the check costs 12 points and warns rather than blocks. It matters in combination: a project created this month, in a namespace created this month, shipping a binary release, is the shape the namespace-age check blocks on — provided that check has its input, which on a user-owned gitlab.com project means a token.
Why 30 days? It is the owner's example from the policy model and a policy parameter, not a constant — anywhere from 7 to 180 days, and the strict profile uses 90. It is the same number on GitHub and on gitlab.com, because the check is the same code reading the same field; what differs is the record behind it, and on the 100 most-starred gitlab.com projects the youngest was 627 days old.
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.
C2 Repository age — the GitHub original · G1 Owner account age — the check that blocks when both are young, where its input is readable · G3 Star velocity and traction — stars divided by this age · G9 Release-asset binaries — what a week-old project should not already have.
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; GitLab Threat Intelligence, 19 February 2026; the C2 page's Phase 0 and Island figures where GitHub is cited; thresholds and weights from the product's policy and scoring tables.