Skip to main content
The Binarly Transparency Platform detects vulnerabilities through several methods: version-based detection, which matches identified components against known-vulnerable version ranges; rule-based detection, which analyzes the actual code semantics of a binary; and, for UEFI firmware, code-similarity and program analysis techniques that don’t depend on a version signal or a rule. These methods catch different things and are used together.

​
Version-based detection

The primary approach matches an identified component and version against known-vulnerable version ranges sourced through Vulnerability Data Sources. How the component and version are established in the first place is covered in Component and Version Identification, and what gets attributed to the result in Provenance. Version matching provides broad coverage across every ecosystem the platform identifies, and it produces false positives when a fix has been backported without a version bump.

​
Ecosystem filtering

To reduce false positives from backported fixes, the platform matches against the distribution’s own security notices instead of upstream version ranges, for the distributions listed under Distribution Sources. This recognizes a patched package even when its version number hasn’t changed. It depends on the image carrying package metadata, which is set out in How backported patches are resolved.

​
Rule-based detection

Rule-based detection analyzes the actual code implementation rather than relying on version numbers, so it can catch both known and unknown vulnerabilities. It works by matching semantic patterns across a binary’s disassembly, intermediate representation, and decompiled code, rather than checking for a specific byte sequence. VulHunt is Binarly’s semantic rule engine for this kind of detection, covering POSIX executables and libraries as well as UEFI modules. A VulHunt rule can, for example, identify a vulnerable function-call pattern directly rather than checking whether the binary’s reported version predates a fix. FwHunt rules provide the same kind of semantic matching scoped specifically to UEFI firmware, including firmware-specific vulnerability patterns such as unsafe SMM callouts.

​
Rule sourcing

Binarly’s research team authors and ships VulHunt rules as part of the platform. FwHunt rules can also be written and deployed by customers through the Custom Rule Manager, alongside YARA rules for malicious code detection.

​
Code-similarity and program analysis

For UEFI firmware, where a reliable version signal often isn’t available, the platform also detects vulnerabilities through two additional techniques that don’t rely on a version number or a predefined rule:
  • Known vulnerabilities are matched by comparing the module’s code against reference builds of the component, which identifies it without a version string. See Hybrid identification for UEFI components.
  • Unknown vulnerabilities are surfaced through program analysis, including dataflow analysis, symbolic execution, and partial emulation, to identify potentially vulnerable code paths that match no known pattern.
Both are scoped to UEFI modules and complement the semantic rule-based detection VulHunt and FwHunt provide.

​
Patch detection

Both detection methods also produce an informative patch/known-vulnerability finding when a fix for a known vulnerability is already present in the component, rather than a vulnerability finding itself. This lets you confirm a patch landed without having to re-derive it from a version number alone.