Check C15 · execution surface family · severity HIGH · automatic · one of the 22 checks
The question this check asks: are there executables committed inside the source tree — files nobody can read as code and nobody can rebuild from what is there?
The OpenSSF Scorecard's Binary-Artifacts check exists for one reason, and the xz backdoor of 2024 (CVE-2024-3094) made it vivid: a released source tarball should contain only what is in version control, and anything you cannot rebuild from source is a place to hide a payload. The xz payload sat in test fixtures — opaque binary files that every reviewer scrolled past for years, because what is there to review in a fixture? A .exe, .dll, .so or .jar in a tree is the same proposition: it will do what it does, and the source beside it does not tell you what.
C15 reads the repository's file list — one API call, no clone — and fires when any path ends in .exe, .dll, .so, .dylib, .jar, .pyc, .class, .bin, .msi, .scr, .apk or .node. The finding is HIGH, costs 8 points, and names up to four of the files — “executables committed to source: vendor/x.dll, tools/y.exe”. A repository that trips nothing else scores 92, the badge stays green, the verdict is REVIEW — and the default personal policy sets this finding to allow: it is on the board, and the download proceeds. The strict organisation profile blocks. The evidence note in the scoring table:
“27/80 top repos carry binaries”
A third of the most popular repositories on GitHub: 27 of the 80 in our Phase 0 controls. Test fixtures, vendored native libraries, a Gradle wrapper, a compiled helper for a platform without a toolchain. That measurement is why the finding is recorded rather than acted on by default — the board tells you the files are there, and a team that wants the strict behaviour can have it and maintain the allowlist it implies.
It matches extensions. A binary renamed .dat, a payload inside an image or a font, an archive that is itself a container — none of those match, and the xz fixtures would not have either. It does not open the files, so it cannot say whether a .so is the library its name claims; a deep scan runs ClamAV and Trivy over the bytes. And it reads the tree, not the releases: the binary that FakeGit shipped was a release asset, which is C9 and is scored separately because it lives somewhere separate.
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: GitHub shows a binary file as "View raw" with no content, which is the tell. With the GitHub CLI:
gh api repos/OWNER/REPO/git/trees/HEAD?recursive=1 --jq '.tree[] | select(.path | test("\\.(exe|dll|so|dylib|jar|pyc|class|bin|msi|scr|apk|node)$"; "i")) | "\(.size)\t\(.path)"'Then ask, for each one, whether the repository could rebuild it from what is beside it. If not, it is something you are trusting on somebody's word.
Why does a committed binary not warn by default? Because 27 of the 80 most popular repositories carry one — test fixtures, vendored libraries, a wrapper JAR — and a gate that warns on a third of GitHub is a gate people switch off. The finding costs 8 points and the default personal policy records it on the board without holding the download. Strict organisation profiles block on it, which is the right setting for a team that can afford the allowlist work.
What is the difference between this and the release-asset check? Where the binary lives. C15 reads the source tree — files under version control. C9 reads the assets attached to releases, which are not in the tree and which is where the FakeGit payload actually was. A repository can be clean here and dangerous there; the two checks are scored separately for that reason.
Does RepoGates stop git clone? No. Browser-initiated downloads only.
C9 Release-asset binaries — the same question asked of the releases page · C14 Build scripts and wrapper JARs — the committed binary that runs on every build · C8 OpenSSF Scorecard — Binary-Artifacts, the second opinion.
Add RepoGates to Chrome Pricing
Numbers on this page: Phase 0 controls of 2026-08-14 (27 of 80 popular repositories); CVE-2024-3094 as published; weights and actions from the product's scoring and policy tables.