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.
The binary is ground truth
Most software supply chain tools tell you what a vendor declared was in their product. Binarly tells you what’s actually there. Statically linked libraries don’t appear in package manifests. Vendors backport security fixes without changing version numbers, so hash-based and version-based matching misses patched components entirely. Any tool that works from metadata alone inherits every error and omission in that metadata. The Binarly Transparency Platform scans compiled binaries — firmware images, executables, containers, and libraries — and derives a ground-truth picture of what software is actually running: every component, every cryptographic asset, every known and novel vulnerability.Four problems traditional tools don’t solve
Lack of visibility. Without source code access, it’s difficult to know exactly what’s inside a compiled binary or firmware image — especially code from third-party vendors. Binary analysis removes that dependency entirely. Unknown threats. Most scanners only match known CVEs by version number. They miss zero-day vulnerabilities, entire classes of bugs, and malicious implants with no existing signature. The Binarly Analysis Engine detects vulnerability classes semantically, independent of CVE assignment. Alert fatigue. Version-based scanners report every CVE in every linked library, including vulnerabilities that can’t be reached in the specific binary. Reachability analysis and the Exploitation Maturity Score filter findings to what’s actually exploitable and actively targeted. The result is a prioritized list of findings teams can act on, not a backlog of theoretical risks. Complex supply chains. A single firmware image can contain code from dozens of suppliers. Statically linked dependencies are embedded directly in the binary and invisible to manifest-based tools. Binarly identifies every component regardless of how it was packaged.What Binarly detects
The platform identifies nine categories of findings within compiled binaries and firmware:- Known vulnerabilities — CVE matches with CVSS, EPSS, Exploitation Maturity Score, and reachability data
- Unknown vulnerability classes — zero-day patterns detected through semantic code analysis, independent of CVE assignment
- Dependency vulnerabilities — known vulnerabilities in embedded third-party components, organized by dependency
- Cryptographic material — weak keys, expired certificates, compromised keys, cryptographic protocols and algorithms
- Secrets — hardcoded API credentials, OAuth tokens, encryption keys, JWT tokens, and generic credentials
- Supply-chain failures — components built from tampered sources, compromised toolchains, and Boot Guard integrity issues
- Mitigation failures and weaknesses — missing stack canaries, CFI, NX/DEP, RELRO, PIE, Fortify Source, and use of unsafe functions
- Suspicious code — anomalous parsing behavior and obfuscation patterns that may indicate a modified or implanted binary
- Malicious code — confirmed malware implants, hooks, embedded executables, and firmware backdoors, classified using ATT&CK and MBC
Who uses it
Software producers
Hardware OEMs and software vendors integrating Binarly into CI/CD pipelines to validate compiled binaries before shipping. The goal: catch vulnerabilities in your own stack and in every third-party component before a product reaches a customer.
Software consumers
Enterprise security and procurement teams assessing third-party firmware and software before deployment. The goal: verify vendor claims against binary ground truth and reduce exposure to supply chain risk.
Research that validates the engine
Binarly’s detection engine is built on original vulnerability research. 204 public disclosures across 84 products and 15 vendors include LogoFAIL — a UEFI image parser vulnerability class affecting billions of devices — and PKfail, a Secure Boot Platform Key failure present in 200+ device models across 12 years of production hardware. This research isn’t separate from the platform. It produces the detection rules, validates the analysis methodology, and establishes that the Binarly Analysis Engine finds vulnerabilities that other tools miss.Next steps
- Use cases — how software producers and enterprise buyers put this into practice
- The Binarly advantage — the specific capabilities that set Binarly apart from source-code scanning tools