Check G7 · provenance family · severity HIGH · automatic · one of the 22 GitLab checks
The question this check asks: is anyone still looking after this project? Has it seen activity in the last year, and — if it publishes releases at all — has it published one? The GitHub check asks a third question, whether the repository has been archived, and on gitlab.com that one cannot be answered without signing in.
The OpenSSF baseline asks for commits within twelve months and a release within twelve months, because a dependency nobody maintains is a vulnerability nobody will fix. The repository vetting standard adds the owner's own requirement — a project you build on with no release in over a year is a support risk even if commits still land — and then says the important thing about the whole group: necessary, nowhere near sufficient. Maintenance tells you what you are taking on. It tells you nothing about what was put there.
GitLab changes the inputs, not the rule. Its project record carries one activity field, last_activity_at, and it moves on issue and merge-request activity as well as on pushes; the commits API publishes no totals, so counting commits in a window would mean paging through them. RepoGates reads the field. The consequence is that a project whose tree has not changed in years but whose issue tracker is answered reads as active, and the stale row fires less often here than on GitHub — a fact about the field, stated on this page rather than hidden behind it.
G7 is the same check as C7, run by the same code on a GitHub-shaped snapshot built from gitlab.com's API. It produces up to three findings, none of which blocks on its own.
Archived — on GitHub, the repository's archived flag, at severity HIGH for 12 points. The anonymous project record on gitlab.com omits archived altogether, so on this tier the row cannot fire. That is unknown, not "not archived": the verdict says nothing about archiving rather than clearing it, and no PASS is built on the flag's absence.
Stale — no activity in more than 365 days, measured from last_activity_at. Severity MEDIUM, 6 points, “no push in N days (OpenSSF: activity within 12mo)”. Verdict REVIEW at 94; the default policy warns. Evidence note: “OpenSSF activity window”.
Stale release — the project uses releases and the latest, by its released_at, is more than 365 days old. Severity MEDIUM, 6 points, “latest release is N days old — vulnerability/support risk if you build on it”. Projects with no releases do not fire this, and the source archives gitlab.com generates for every tag are not releases. Evidence note:
“owner requirement: no release >1y = support risk”
Both windows are policy parameters (stale_push_days, stale_release_days, 90 to 1,095). Nothing in this check adds points: a recent date is the absence of a warning, not a credit.
Measured on 19 September 2026 across the 100 most-starred gitlab.com projects — read anonymously, through the same code as /v1/gl/score — an old last release fired on 30 of the 100 (62 of them publish releases at all), the most common warning of any severity above a note; the stale row fired on 16, despite the wider activity field. GitHub's 100 most-starred, read the same day by the same engine as the control, tripped the release row 9 times. These are old projects: the youngest was 627 days, the median 3,025.
Finished software. A small tool that has needed no change for two years is not abandoned, it is done. On gitlab.com the release row is the one to read with care: inkscape/inkscape read REVIEW at 79 on 18 September with a stale release among its findings, and it is one of the busiest projects on the platform. The board shows which row fired and the number of days, and the decision is yours; a project you rely on and know to be complete belongs on your allowlist. The reverse case is a false reading in the other direction — a tree nobody has touched, kept "active" by a lively issue tracker — and it is the reason this check is hygiene, not evidence.
Malice, in either direction. No gitlab.com campaign of the FakeGit shape exists in the 2024–2026 record, so there is no catch rate to publish for this check on GitLab, and GitHub's numbers are not transferred here. What the record does hold is GitLab's own threat intelligence (19 February 2026): 131 accounts banned in 2025 for North Korean nation-state malware distribution, delivered by recruiter lure as projects to clone and run, with the payload stored somewhere other than gitlab.com in more than 80% of cases. The post does not state how old or how busy those projects were, so what this check would have said about them cannot be measured — and a compromised account's last push is last week in any case. A project's activity has no bearing on the release asset it just attached or the devfile it just added.
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's last activity is on its page and its releases are on its Releases page. The anonymous API answers two of the three questions, with every / in the project path written as %2F:
curl -s "https://gitlab.com/api/v4/projects/NAMESPACE%2FPROJECT" | jq '{created_at, last_activity_at, archived}'
curl -s "https://gitlab.com/api/v4/projects/NAMESPACE%2FPROJECT/releases?per_page=1" | jq '.[0] | {tag_name, released_at}'The archived field comes back null: it is not in the anonymous record, which is exactly why the row cannot fire. Then decide whether "done" or "abandoned" is the word — and remember that neither one is "safe".
Is an unmaintained project dangerous? It is a support and vulnerability risk if you build on it, which is different from a lure. Finished software exists, and a tool that has needed no commit for two years may simply be done. That is why a stale activity date and a stale release each cost 6 points and warn rather than block: they tell you what you are taking on, not what was done to you. The archived flag, which costs 12 on GitHub, is not in gitlab.com's anonymous project record, so that row stays silent here rather than clearing the project.
Why does an active project not score better? Because activity is the easiest thing in the world to fake, and on gitlab.com it is cheaper still: last_activity_at moves when an issue is opened or a merge request is touched, not only when code is pushed. A recent date is the absence of a warning, not a credit. Nothing in this check can raise a score, and nothing about recency distinguishes a maintained project from a fresh lure or a compromised account that just pushed.
Does RepoGates stop git clone of a gitlab.com project? No. RepoGates does not see git clone, glab, package managers or curl run from a terminal, and the extension's board on gitlab.com pages is a later release. What reads a gitlab.com project today is the verdict API, the MCP server and the RepoGates plugin's hook on Claude Code's Bash tool, which sends a git clone https://gitlab.com/… or glab repo clone command line to preflight before it runs and answers on this check's dimension — a refusal or a question for that one tool call, not a wall around git.
C7 Maintenance activity — the GitHub original · G6 Licence — the third question of the same baseline · G8 OpenSSF Scorecard — the hygiene check that never runs on gitlab.com · G2 Repository age — the other end of the timeline.
Add RepoGates to Chrome Pricing
Numbers on this page: the OpenSSF baseline as cited in the repository vetting standard; thresholds and weights from the product's policy and scoring tables; the 100 most-starred gitlab.com projects, and GitHub's 100 as the control, read anonymously on 19 September 2026 through the same code as the verdict API.