Binary files in a repository cannot be reviewed the way source can, so no one can easily confirm they match the code. They can be obsolete or subverted without anyone noticing. A binary in a dependency is a prompt to ask where it came from and whether it can be rebuilt.
What the Scorecard check says
OpenSSF Scorecard's Binary-Artifacts check determines whether the project has generated executable artifacts in its source repository. It rates the risk as High, with the stated concern of non-reviewable code. The documentation lists the problems:
- Binaries cannot be reviewed, which allows obsolete or maliciously subverted executables. Reviews generally cover source, since it is hard to audit an executable to see if it corresponds to the source.
- Over time the included executables might not correspond to the source code.
- Checked-in executables let the build process atrophy, which can lead to an inability to create working executables.
The documentation says users often use such executables directly, which leads to dangerous behavior, and suggests countering the problems with verified reproducible builds.
What counts, and what usually does not matter
The check covers generated executables. Many language systems produce them: machine code, Java class files, Python bytecode, minified JavaScript. Not every hit is dangerous.
| Finding | Typical situation | Concern |
|---|---|---|
| Gradle or Maven wrapper jar | Build tooling convention | Low, but verify checksum |
| Test fixture binary | Sample data for tests | Low |
| Prebuilt native library used at runtime | Shipped to you | Higher, ask for source and build |
| Minified bundle committed as the source of truth | Build step skipped | Medium |
| Unexplained executable | No documentation | High |
Judge by whether the binary ends up in what you run and whether the project documents how it was built.
How to review a flagged binary
- Find out where it is used. Is it in the published package or only in the repository?
- Look for build instructions or a script that regenerates it.
- Compare a checksum from the repository against what the project documents, if it documents any.
- If the package ships native code, see whether releases are built in a public workflow with an attestation, such as npm provenance or a PyPI attestation.
- Decide how much that matters. A native library loaded into your process can do anything your process can.
When you are the maintainer
If you maintain a package yourself, remove checked-in executables where you can, build them in CI from source, and publish a checksum or attestation for the artifacts. It makes your project easier to adopt and easier to trust.
Do not treat the check as a verdict
A zero on this check is not a sign of danger, and a clean score does not mean the package is harmless. It speaks to reviewability. Pair it with identity checks, maintenance, and review practice, then weigh the result by what the package can touch.
Try it yourself
Click through it at your own pace, or open it full screen. It shows how a built image is scanned, since compiled content is where review by reading source stops.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning and container scanning workflows alongside policies and gates. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a Gradle wrapper jar a problem?
It is a common convention. Verify its checksum and treat it as low concern unless something else looks off.
Can binaries be trusted if the package has provenance?
Provenance shows where it was built, not whether the contents are harmless. It helps, but it is not a guarantee.
Sources
- OpenSSF Scorecard check documentation
- npm Docs: Generating provenance statements
- PyPI Docs: Digital attestations
Last reviewed: 19 October 2026.
