> ## Documentation Index > Fetch the complete documentation index at: https://docs.binarly.io/llms.txt > Use this file to discover all available pages before exploring further. # Hardening Analysis > How the Binarly Transparency Platform detects missing security mitigations and binary weaknesses in compiled binaries. 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 | Finding Type | Description | Finding Classes | | ---------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | **Mitigation Failure** | A security hardening control is missing or misconfigured | [`mitigation/*`](/resource-center/finding-classes#mitigation-classes) | | **Weakness** | A condition that reduces the difficulty of exploitation or expands attack surface | [`weakness/*`](/resource-center/finding-classes#weakness-classes) | 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](#uefi-firmware-hardening). | Check | What is reported | Analysis method | | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------- | | [**NX / DEP**](https://en.wikipedia.org/wiki/Executable_space_protection) | Whether the NX bit is set | ELF flags | | [**PIE**](https://en.wikipedia.org/wiki/Position-independent_code) | Whether the binary is position-independent | ELF flags | | [**RELRO**](https://man7.org/linux/man-pages/man8/ld.so.8.html) | Whether the Relocation Read-Only protection is enabled (Full, Partial, or None) | ELF segment analysis | | [**Stack canaries**](#stack-canaries) | Per-function coverage percentage | Symbols and cross-references analysis | | [**FORTIFY\_SOURCE**](https://www.gnu.org/software/libc/manual/html_node/Source-Fortification.html) | Whether FORTIFY\_SOURCE is present at binary level | ELF symbols | | [**CFI**](#cfi) | Per-function coverage percentage | Instruction and intrinsic scanning | | [**RPATH**](https://man7.org/linux/man-pages/man8/ld.so.8.html) | Whether RPATH is set, and all path entries | ELF dynamic section | | [**RUNPATH**](https://man7.org/linux/man-pages/man8/ld.so.8.html) | Whether RUNPATH is set, and all path entries | ELF dynamic section | | [**Stripped**](https://man7.org/linux/man-pages/man1/strip.1.html) | Whether symbol information is retained | ELF symbol table | | [**Unsafe functions**](#unsafe-functions) | Which functions, call count, and safe alternatives | Symbol analysis | ### 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. | Check | checksec | BTP | | ----------------------------- | ---------------------------------------------- | ----------------------------------- | | NX | ✓ | ✓ | | PIE | ✓ | ✓ | | RELRO (Full / Partial / None) | ✓ | ✓ | | Stack canaries | Binary-level (present/absent) | Per-function with coverage % | | FORTIFY\_SOURCE | Distinguishes fortified vs fortifiable count | Binary-level only | | RPATH | Present + all entries (colon-separated) | Present + all path entries | | RUNPATH | Present + all entries (colon-separated) | Present + all path entries | | Stripped | ✓ | ✓ | | CFI | Symbol-based (single + multi-module Clang CFI) | Instruction-byte-based per-function | | Unsafe functions | — | Call counts + safe alternatives | | CET — IBT (x86/x86\_64) | ✓ via `.note.gnu.property` | ✓ | | CET — SHSTK (x86/x86\_64) | ✓ via `.note.gnu.property` | — | | BTI (ARM64) | ✓ via `.note.gnu.property` | ✓ | | PAC (ARM64) | ✓ via `.note.gnu.property` | — | | SafeStack | ✓ via `__safestack_init` symbol | — | ## 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)](https://kspp.github.io/Recommended_Settings) 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. | Check | What is reported | | ---------------------------------------------------------------- | ----------------------------------------------------- | | **Memory protection policy** | Policy misconfiguration type and details | | **PEI StackGuard** | Misconfiguration present or absent | | **DXE StackGuard** | Misconfiguration present or absent | | [**RSB (Return Stack Buffer) stuffing**](#rsb-stuffing) | Absent or incomplete | | **Intel microcode — outdated** | Detected version | | **Intel microcode — vulnerable** | Detected version and list of known vulnerabilities | | **AMD microcode — outdated** | Detected version | | **AMD microcode — vulnerable** | Detected version and list of known vulnerabilities | | **Secure Boot dbx (forbidden signatures)** | Outdated revision detected | | **Secure Boot bypass via known signed applications** | Identified application names | | **Secure Boot Setup Mode** | Whether Setup Mode is enabled | | [**AMI non-production test key**](#non-production-test-keys) | Test key identified | | [**Insyde non-production test key**](#non-production-test-keys) | Test key identified | | [**Phoenix non-production test key**](#non-production-test-keys) | Test key identified | | [**PKfail — leaked AMI platform key**](#pkfail) | Leaked key identified | | **Boot Guard Key Manifest verification** | Verification failure details | | **Leaked Boot Guard key** | Identified key (Key Manifest or Boot Policy Manifest) | | **Insyde FDM firmware integrity bypass** | Vulnerable Flash Device Map configuration details | | **Intel Flash Descriptor** | Writable (unprotected) flash region details | | **UEFI platform configuration** | Weak configuration details | ### 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. ## Related * [Supported Platforms](/user-guides/about/supported-platforms) — Full platform and architecture coverage table * [Secure by Design findings](/user-guides/image-scans/all-about-details#secure-by-design) — Reviewing mitigation and weakness findings in the platform UI * [Finding Classes Reference](/resource-center/finding-classes) — Full list of mitigation and weakness classes * [Finding Types & Classes](/resource-center/finding-types) — How finding types group classes for filtering * [Detection Methods](/resource-center/detection-methods) — Overview of BTP's detection pipeline * [Accuracy & Confidence in Findings](/resource-center/accuracy-confidence)