A version check reports a CVE when a package's version sits inside the vulnerable range. Distributions often fix the CVE without changing the version, so the report lists a flaw that the device no longer has. The Patch Presence Check reads the compiled code in your firmware image and says whether the upstream fix is in it.
On 13 real OpenWrt images, a version-only scanner lists 118 CVEs for dnsmasq, dropbear, lua, zlib and expat. 22 of them (18.6%) are already fixed by a back-port. Each one costs an engineer time to disprove. A customer or regulator who asks for a VEX statement (Vulnerability Exploitability eXchange) needs evidence behind it, and a version string is not evidence of a fix.
TrustDyne finds the upstream commit that fixes each CVE, builds the package before and after it, and keeps hashes of the instruction patterns the fix changed. It then looks for those patterns in the binaries of your image and answers fix present, fix absent or not determined. It also reads the version inside each file and checks the project's own release history. Every answer goes into an OpenVEX document with an evidence bundle, both signed with TrustDyne's report key, so your customer checks them without our servers. On the 13 test images the checker answered 292 of 404 tests and none were wrong. It closed 11 of the 22 back-ported CVEs from the compiled code, and it never turned a vulnerable CVE into fixed. It covers dnsmasq, dropbear, lua, zlib and expat on x86-64, 32-bit x86, ARM, AArch64 and MIPS in both byte orders. Anywhere else it answers not determined. A match is an instruction-level comparison, not a formal proof, and a reviewer still decides.