Check G8 · provenance family · severity HIGH · automatic · one of the 22 GitLab checks
The question this check asks: what does the OpenSSF's own scanner say about how this project is run? On gitlab.com the answer is that it says nothing — Scorecard does not cover the platform — and this page is about what RepoGates does with a check that has no input.
The OpenSSF Scorecard is twenty checks, free, with no download, run by the OpenSSF on a schedule against the projects it covers. It measures process: branch protection, dependency pinning, signed releases, whether CI workflows run code from pull requests, whether binaries are committed. The repository vetting standard's rule for reading it is deliberately asymmetric — treat a low score as disqualifying and a high score as meaningless — because Scorecard measures hygiene, not malice, and a purpose-built malicious repository can score well on every line. Two of its checks are worth reading alone: Dangerous-Workflow, a CI pipeline that will run a stranger's code, and Binary-Artifacts, the same question as our own committed-binaries check answered by a second party.
None of it exists for gitlab.com. Scorecard's scheduled scan works from a project list its own README describes as derived from projects hosted on GitHub only, with expansion planned; the specification of its public API names github.com as the platform and nothing else; and the live answer, measured on 18 September 2026, is that GET /projects/gitlab.com/inkscape/inkscape returns 404 while the control, github.com/ossf/scorecard, returns 200 with a result dated 12 September and produced by Scorecard v5.5.0. That is not "unscanned", the state most GitHub repositories are in; it is a platform the service does not read.
G8 is the same check as C8, unchanged, with no input. On GitHub it asks the public Scorecard API for the latest result and fires HIGH for 8 points when Dangerous-Workflow or Binary-Artifacts scores under 5, and MEDIUM for 4 points when the overall score is under 3; a repository Scorecard has never scanned gets a note and no finding. On gitlab.com the request is never made — the adapter knows the answer is 404 and does not spend one of a scan's five or six requests on it. Every gitlab.com verdict lists G8 as not checked. It costs nothing: no finding, no points.
And it withholds nothing. G8 sits in the clone dimension beside owner age, repository age, licence, maintenance, the nested bare repository and submodules, and a dimension reads PASS only when every check in it ran — with two exceptions written into the rule: Scorecard, and the browser-only agent-provenance check G22, are no-input skips, listed on the verdict but never holding it back. Without that exception no gitlab.com project could ever read PASS on clone, and the verdict would be a statement about Scorecard's coverage rather than about the project. On the 100 most-starred gitlab.com projects, measured on 19 September 2026, G8 was not checked on 100 of 100; on GitHub's 100 most-starred, the control read the same day by the same engine, Scorecard had a result for 49.
None, on gitlab.com — a check that never runs cannot fire. What can mislead is the absence itself, in both directions. A reader used to the GitHub page might take "not checked" as a mark against the project; it is not, and it costs nothing. Another might take a missing Scorecard as clearance; it is not that either, and the vetting standard's own caveat about Scorecard — that projects on other forges score artificially low when it does run on them — is the reason a missing scan was never treated as evidence of anything.
Everything, on gitlab.com. What Scorecard would have told you about a GitHub repository, RepoGates answers elsewhere or not at all here. Binary-Artifacts — binaries committed to the tree — is asked from the file list under G15, which does run on gitlab.com and fired on 26 of the 100. Dangerous-Workflow — CI that will run a stranger's code — is a pipeline question, and on GitLab a pipeline runs on push and on a merge request, never when someone clones or opens the project; it is the maintainer's exposure, not the downloader's, and no check on this roster reads .gitlab-ci.yml for it. GitLab's own Security Dashboard and Vulnerability Report are not a substitute either: Ultimate-tier, fed by the project's own pipeline and reported to its owner, they tell a downloader nothing about someone else's public project.
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, confirm the gap from a terminal:
curl -s -o /dev/null -w '%{http_code}\n' https://api.securityscorecards.dev/projects/gitlab.com/NAMESPACE/PROJECTA 404 on gitlab.com is the platform, not the project. The Scorecard CLI does read GitLab: it takes a token in GITLAB_AUTH_TOKEN (and GL_HOST for a self-managed instance), and its checks table marks SAST, Dangerous-Workflow, Token-Permissions and Webhooks as unsupported there and the rest as validating or supported — so one of the two checks RepoGates reads closely does not exist on GitLab even when you run the tool yourself. RepoGates has not run it on gitlab.com and does not verify what it reports; a result you produce this way is yours to read, and a Binary-Artifacts failure is the one to compare against G15.
GITLAB_AUTH_TOKEN=… scorecard --repo=gitlab.com/NAMESPACE/PROJECTWhy is Scorecard not checked on gitlab.com? Because Scorecard does not cover the platform. Its scheduled scan is driven by a project list derived from GitHub only, its API's specification names github.com and nothing else, and a live request for a gitlab.com project answers 404 where the GitHub control answers 200. RepoGates does not make a request it knows will fail; it lists the check as not checked on every gitlab.com verdict, which is the honest word for a check with no input.
Does 'not checked' count against the project or hold back the verdict? Neither. It costs no points, because the absence of a scan is not evidence of anything. And it does not withhold the clone dimension: a dimension reads PASS only when every check in it ran, except for the two no-input skips — Scorecard here and the browser-only G22 — which are listed but never hold the verdict back. Otherwise no gitlab.com project could read PASS on clone, which would say something about Scorecard's coverage and nothing about the project.
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.
C8 OpenSSF Scorecard — the GitHub original · G15 Committed binaries — our own answer to Binary-Artifacts, from the file list, and it runs here · G7 Maintenance activity — the rest of the hygiene baseline · G1 Owner account age — the other check the anonymous API can leave unchecked.
Add RepoGates to Chrome Pricing
Numbers on this page: the OpenSSF Scorecard's README, API specification and live API as read on 18 September 2026; 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 on 19 September 2026. Check numbering follows the product's catalogue.