Rules / GRN-C004
GRN-C004 new-binary
| Default severity | warn |
| Kind | diff rule: fires only when the trusted version had the property and the new version lost it, or the new version gained a risky property the trusted version lacked. |
| Status | Specified for 1.0, not yet implemented |
What it checks
The new version adds a native executable or shared library that is not a compiled extension module of a package path the trusted version already had, or the release changes from pure Python to containing binaries.
Why it matters
Garnet Guard can read Python source but not machine code. A new binary is content no reviewer can read in a diff, and it can run when loaded or executed.
Example finding
Illustrative; not from a real release. The rule is specified but not yet implemented.
examplelib 2.6.1 → 2.6.2: WARN
WARN GRN-C004 new-binary: 2.6.2 adds 1 native binary that 2.6.1 didn't have
- examplelib/bin/helper (ELF executable, 1,204,512 bytes)
How to resolve it
- Check the release notes and the repository for a new compiled component.
- Confirm the binary is built by the project's CI (its build logs or attestation).
- If it is expected, merge and add an ignore. Packages that always ship compiled wheels can ignore this rule for all versions.
Allowlisting
Once you've reviewed a release, ignore this rule for that package and version range.
Every ignore needs a reason and an expiry date; after until it stops applying and the
report notes that it expired.
[[garnet.ignore]]
package = "examplelib"
versions = ">=2.6"
rules = ["GRN-C004"]
reason = "ships compiled wheels from 2.6 on, see release notes"
until = "2027-06-30"
To change the rule's severity for every package instead:
[garnet.rules]
"GRN-C004" = "block" # "off" | "info" | "warn" | "block"
Suppressed findings still appear in JSON and SARIF output, marked with the ignore that
matched. The policy format is in SPEC §7; 0.1's garnet diff
doesn't read policy files yet.