Skip to main content

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.

​
Why binary analysis is structurally different

Source-code scanning tools — including most SCA platforms — analyze what developers declared was in their software. They read package manifests, lock files, and import statements. Binary analysis starts from the compiled artifact — the thing that actually runs. It doesn’t require source code access and doesn’t depend on vendor-supplied metadata. Every component present in the binary is identified directly, regardless of whether it appears in any SBOM, package manifest, or documentation. This distinction matters most for four categories of content that source-code tools structurally cannot reach:
  • Statically linked libraries compiled directly into an executable without leaving a package manifest entry
  • Precompiled third-party components where source code was never available to the buyer
  • Transitive dependencies pulled in by third-party components and compiled into the binary, invisible to tools that only resolve declared direct dependencies
  • Backported patches where a vendor fixes a CVE without changing the version number, making version-based matching wrong in both directions

​
Primary focus

Binarly is purpose-built for firmware, embedded Linux, and compiled application binaries — the artifacts that actually ship or run. This is the only way to assess firmware, third-party components delivered without source code, and software where a vendor-supplied SBOM hasn’t been independently verified. The platform supports UEFI firmware, BMC firmware (OpenBMC, AMI MegaRAC), Embedded Linux, QNX, Android, Docker containers, Java (JARs, WAR/EAR, and JVM bytecode), Python applications, and Linux ELF binaries. Cross-architecture analysis covers x86, ARM, and XTensa.

​
Eight differentiating capabilities

​
Unknown vulnerability class detection

Most platforms detect known CVEs by matching component versions against a vulnerability database. Binarly also detects entire vulnerability classes by analyzing code behavior semantically. The Binarly Analysis Engine decompiles binaries, constructs call graphs, and performs data-flow analysis to identify patterns matching known CWEs — independent of whether a CVE has been assigned. This means Binarly can find vulnerabilities before a CVE is assigned, not only after.

​
Patented reachability analysis

Binarly’s reachability analysis (U.S. Patent 12,287,885) traces actual execution paths through a binary to determine whether vulnerable code is reachable by an attacker. The analysis is environment-aware: it accounts for the runtime context, not just whether a call path exists in the abstract. The result is a filtered finding list where every item has a defensible basis for prioritization — not a list of every theoretical vulnerability in every linked library.

​
Exploitation Maturity Score

The Exploitation Maturity Score (EMS) ranks findings using real-world evidence: public proof-of-concept code availability, ransomware group usage data, private telemetry, and CISA KEV catalog status. CVSS measures theoretical severity. EMS reflects whether attackers are actively exploiting a vulnerability. Combined with reachability analysis, EMS gives security teams a prioritized list grounded in current threat activity.

​
Patented CBOM and PQC compliance

Binarly generates a Cryptography Bill of Materials from binary analysis (U.S. Patent 12,153,686), inventorying every cryptographic algorithm, certificate, key, and protocol present in the binary. Cryptographic reachability analysis identifies which assets are actively used. PQC compliance checks map findings to NIST IR 8547 and CNSA 2.0 requirements across three readiness tiers, with migration timelines assigned to each finding.

​
Original vulnerability research

Binarly has published 204 public disclosures across 84 products and 15 vendors. LogoFAIL — a class of vulnerabilities in UEFI image parsers — affects billions of devices. PKfail exposed Secure Boot Platform Key failures across 200+ device models spanning 12 years of production hardware. The research produces the detection rules that run in the platform today. It also validates the methodology: the same analysis engine that found LogoFAIL is the one scanning your binaries.

​
UEFI firmware depth

UEFI firmware analysis goes beyond surface-level component inventory. Binarly parses UEFI volumes, modules, and driver execution order; detects image parser vulnerabilities (as demonstrated by LogoFAIL); identifies Secure Boot policy weaknesses; and flags hardening gaps at the firmware level.

​
Secrets detection

Binarly identifies hardcoded secrets — credentials, API keys, private keys, and cryptographic material — embedded in compiled binaries and firmware. Unlike pattern-matching tools that scan source files, secrets detection works directly on the binary artifact, finding secrets that were embedded at compile time or introduced through third-party components.

​
Malware and tampering detection

Binarly detects malicious implants, backdoors, and binary tampering at the firmware and application level. Analysis identifies code patterns consistent with known malware families and flags anomalies that indicate post-build modification — providing confidence that a firmware image or compiled binary hasn’t been compromised between build and deployment.