Vulnerability prioritisation
Start with the findings that matter.
A long CVE list is not a review plan. FDIE matches identified component versions against NVD CPE version ranges and OSV package ranges, adds exploit-probability scores and known-exploited flags, and combines them with checks on the binaries and configuration you actually ship.
Vulnerability prioritisation
Correlate known vulnerabilities
Matches use the identified version and the affected ranges in NVD (CPE) and OSV, so a component outside an affected range is not reported as vulnerable. An OSV lookup sends only a library's name and version, never the firmware or its files.
- See CVSS severity, EPSS exploit probability and CISA KEV status together.
- Keep the vulnerability data current with a daily feed refresh.
- A CVE match alone does not establish that a device is exploitable.
Vulnerability prioritisation
Check the binaries and configuration
Static checks cover how binaries are built and what the image contains, alongside the component findings.
- Review binary hardening such as stack protection, position independence and relocation settings.
- Find hardcoded credentials, private keys and weak cryptography in recovered files.
- Scan content with YARA rules and review exposed services and update mechanisms.
Vulnerability prioritisation
Decide with the evidence in view
Control-flow relationships and available runtime observations add context when a reviewer assesses whether a finding applies.
- Use reachability and call relationships as supporting evidence, not proof.
- Record a reviewer's decision and its reason with the finding.
- Turn reviewed decisions into VEX statements for release documentation.
FDIE · next step
Start with the findings that matter.
Correlate identified components with NVD and OSV, EPSS and CISA KEV, add binary hardening, secret and configuration checks, and review the evidence behind each result.
Paid at checkout. 14-day money-back guarantee on the first payment if three or fewer new images have been analysed.