The release notes say a vulnerability is fixed, but the version string did not change, or the chip vendor backported the fix without saying so. Buyers, operators and labs want proof, not a changelog. FDIE compares two releases down to their functions and tells you, from the code, what changed and what is still open.
The challenge
Vendors backport fixes without changing versions, and sometimes change versions without the fix. Matching by version alone gets both cases wrong.
A new SDK drop can bring back an old library, turn telnet on again or drop a hardening flag. Nobody notices until a customer or a lab does.
Operators, buyers and, for products sold in the EU, the EU CRA expect vulnerabilities to be fixed through security updates. You need to show what each update changed.
How FDIE helps
Compare two analysed releases of a product: components added, removed, upgraded and downgraded; vulnerabilities new, no longer matched, persisting and regressed; programs, findings, device checks and network services. Coverage gaps that limit the comparison are named.
Patch checks look at the disassembled functions where a fix would land and give each vulnerability a state: fix verified, patch candidate or still vulnerable. A backported fix shows even when the version string did not change.
Open findings and vulnerabilities from the previous release are checked against the new one by fingerprint, so you see what was fixed, what is still open and what came back. Your team closes what is fixed and keeps working on the rest.
Share the delta report and the retest report as signed PDFs, and update the VEX statements for the vulnerabilities the update fixed. The answer to "is it fixed?" becomes a document, not a promise.
How it works
Upload the release you shipped and the update, or let CI send each build.
Pick the two releases. FDIE lines up their components, vulnerabilities, functions, findings and checks.
Fix verified needs nothing more, a patch candidate goes to an engineer to confirm, and still vulnerable goes back on the fix list.
Export the delta and retest reports, update VEX and let the release gate say ship or hold.
Rules by market
For products sold in the EU, the EU CRA requires vulnerabilities to be fixed through security updates and EN 18031 a secure way to deliver them. UK PSTI requires you to publish how long a product gets them, and ITSAR in India covers secure software updates.
Certification mandatory since 1 July 2024
Article 14 reporting since 11 September 2026; the rest from 11 December 2027
Applies since 1 August 2025
In force since 29 April 2024
Version 3.1.3 of September 2024
Evidence and gap finding, not certification: the lab or certification body decides.
Deliverables
What changed between two releases, as a signed PDF.
The previous release's open findings, checked on the new one.
Fix verified, patch candidate or still vulnerable, read from the code.
Statements for the vulnerabilities the update fixed, in CycloneDX, OpenVEX or CSAF 2.0.
The new release's components in CycloneDX 1.6 or SPDX 2.3.
Ship or hold for the update, with the reasons.
Yes. Patch checks read the code, so a backported fix shows even when the version stayed the same.
The code changed where the fix would be, but the change cannot settle it on its own. Your team confirms it.
Two analysed releases of the same product: the one you shipped and the update.
Yes. Components that moved to an older version are listed as downgraded, and vulnerabilities that came back are marked as regressed.
No. Both releases are analysed from their images. Nothing is installed or run on a device.
A 45-minute call with our team. Bring one firmware image.