Skip to main content
The Binarly Transparency Platform checks compiled binaries for missing security mitigations and code quality weaknesses through static binary analysis. Findings surface as two finding types: Mitigation Failure and Weakness.

​
Finding types

Mitigation failures are gaps in compile-time or runtime protections: a control that should be present and effective is absent or misconfigured. Weaknesses are conditions that make exploitation easier but don’t represent a missing control directly.

​
Linux userspace hardening

The following checks run against ELF binaries on Linux and POSIX platforms. For UEFI firmware, see UEFI firmware hardening.

​
Stack canaries

Most tools report canary protection as a binary-level flag: canary handler symbols are either present or absent. BTP traces the call graph from each non-extern function and reports the percentage that contain an actual call to a canary handler. A binary where handler symbols exist but coverage is incomplete still has unprotected surface. The per-function breakdown is available in the finding detail.

​
Unsafe functions

BTP identifies calls to unsafe functions (strcpy, sprintf, gets, and similar) using binary symbols and recovered function information. Each finding reports which functions are called, how many times, and what the safe alternatives are. Findings are classified under CWE-477 (Use of Obsolete Function) and CWE-676 (Use of Potentially Dangerous Function).

​
CFI

BTP assesses Control Flow Integrity at the per-function level by scanning for specific instructions and intrinsics rather than relying on compiler-emitted symbols or ELF notes. This identifies CFI gaps in binaries where symbol-based signals are absent or stripped.

​
Comparison with checksec

For several checks, BTP goes beyond binary-level flags: canary coverage is reported per-function via symbol analysis, CFI gaps are identified by scanning for specific instructions and intrinsics, and unsafe function calls are detected via symbol and recovered function analysis. These produce signals that flag-based tools cannot report. The table below shows where the two differ; CET SHSTK, PAC, and SafeStack are covered by checksec but not by BTP.

​
Linux kernel hardening

Linux kernels built with embedded config support store their configuration inside the binary. BTP extracts and parses this embedded config, then evaluates each CONFIG_* option against rules based on KSPP (Kernel Self-Protection Project) recommendations and Binarly custom rules. Checks are architecture-aware (x86, x86_64, ARM, ARM64) and kernel-version-aware: rules are only applied to the kernel versions they are relevant for. Each triggered rule generates a finding that reports the CONFIG option name, its current value, and the expected value.
Kernel hardening analysis requires the kernel binary to be built with CONFIG_IKCONFIG=y. If the embedded config is absent, no kernel hardening findings are generated for that binary.

​
UEFI firmware hardening

UEFI firmware executes before the OS loads and operates at a privilege level above the OS kernel. Misconfigurations at this layer can undermine Secure Boot, memory protection, and CPU vulnerability mitigations — regardless of what the OS has in place.

​
RSB stuffing

RSB stuffing is a Spectre mitigation for x86 firmware. Before transitioning between privilege levels, the firmware should overwrite the Return Stack Buffer with valid entries to prevent speculative execution from leaking data across SMM boundaries. Absent or incomplete stuffing leaves the firmware exposed to RSB underflow attacks.

​
Non-production test keys

IBV test keys (AMI, Insyde, Phoenix) are used during firmware development and should never ship in production images. When a production device boots or uses firmware components signed with a test key, the corresponding private key might be publicly available, which means an attacker can use this key to bypass Secure Boot or other mitigations.

​
PKfail

PKfail is a Secure Boot Platform Key failure where the private key used to root the Secure Boot chain was leaked or reused across vendors and device models. Binarly’s research identified affected firmware across hundreds of device models spanning 12 years of production hardware. A device with a compromised Platform Key has no meaningful Secure Boot guarantee.