Check C9 · provenance family · severity HIGH · automatic · one of the 22 checks
The question this check asks: are the files attached to this repository's releases executable programs or archives — .zip, .exe, .dll, .jar, .dmg, .msi — rather than source?
Source review and most code scanning look at the repository's files. A payload attached as a release asset is never in those files. In the FakeGit campaign of 2026 the trojan (SmartLoader) lived in release ZIPs under otherwise ordinary-looking repositories: 211 repositories, 335 assets, 14,084,688 downloads, every one of them through a browser's download button. That path is the reason RepoGates exists — the FakeGit intelligence page has the campaign in full.
A tool project whose value lives in a downloadable program deserves suspicion by default, and a warning is the honest amount of it.
C9 fires when the releases API lists an asset with one of the extensions above. It costs 10 points at severity HIGH, so a repository that trips nothing else scores 90 and reads REVIEW. One shape is graded lower: a .tar.gz or .zip whose name matches a wheel beside it — flask-3.1.3.tar.gz next to flask-3.1.3-py3-none-any.whl — is a Python source distribution, the ordinary Python release shape, and costs 5 points at MEDIUM, named as such. An archive with no wheel to vouch for it stays HIGH. It never blocks a download on its own — the evidence note in the scoring table says why:
“the FakeGit delivery path, but 95% of legit binary-shipping tools fire it — moderate weight, panel explains”
Combined with a young owner account, a repository created days ago, or inorganic stars, the same asset is part of a BLOCK. On its own it is a reason to read the release notes before you run what you downloaded.
Almost every legitimate desktop tool, CLI, game mod and firmware project ships a binary release. In our Phase 0 measurement, 95% of the legitimate binary-shipping repositories in the control set fired this check. That is why it warns, and why the board names the asset rather than just the verdict: you can see which file it is talking about.
It sees release assets. It does not open them, does not scan them for malware, and does not see what a binary does when run. A deep scan reads the repository's files in a sandbox; it does not execute release assets either. And RepoGates as a whole gates browser downloads only — it does not see git clone, package managers, curl, or fetches made by AI agents outside the browser.
Without installing anything: open the repository's Releases page and look at the asset names under the latest release. If the project is a library and the assets are .exe or .zip files with no matching source tag, ask why. With the GitHub CLI:
gh release view --repo OWNER/REPO --json assets --jq '.assets[].name'Then compare the release's tag against the commit history. A release whose assets appeared without a corresponding change in the source is the pattern FakeGit used.
Does a binary release asset mean the repository is malicious? No. About 95% of legitimate tools that ship a program fire this check. It is one signal among 22, scored as a warning.
Why do release assets matter more than the source tree? Because a payload in a release ZIP is never seen by source review or by most code scanning. That is where FakeGit put it.
Does RepoGates stop git clone? No. Browser-initiated downloads only.
C15 Committed binaries — binaries inside the source tree rather than attached to a release · C16 Install scripts — a script that fetches and runs something · C2 Repository age — the age that usually travels with this one; two warnings together still read REVIEW, and it is a young owner account (C1 Owner account age) that makes the download a block.
Add RepoGates to Chrome Pricing
Check numbering follows the product's catalogue. The Phase 0 report referred to this check as C8; it is C9 on the board and in the verdict API.