A component baseline
Recognised packages and binaries with their available identity, version, path and analysis evidence for the exact image reviewed.
Firmware and connected devices
Make firmware security part of every product release.
Connected-device manufacturers inherit components from operating systems, vendors and internal teams. FDIE helps identify what can be recovered from a release image, investigate relevant vulnerabilities and compare the evidence when the next firmware version is ready.
A practical scenario
A supplier delivers an updated image with a claimed security fix
The product team needs to know what changed, which components remain exposed and whether an earlier assessment still applies. A version label and a CVE total are only part of the answer. Review the release pair, available function evidence and supplier explanation together.
- Bring to the review
- Authorised current and candidate firmware images, product and version context, and any supplier release or patch information.
- Work towards
- A reviewed component delta, investigated patch candidates and a release record with remaining findings and coverage gaps.
The team's working process
A firmware review from image intake to release evidence
Qualify the image and establish a baseline
Check extraction, recovered files and supported analysis modes. Inspect the identified components and unresolved versions before interpreting the vulnerability matches. Record unsupported or encrypted regions as assessment gaps.
Investigate static and runtime evidence
Review credentials, cryptography, hardening, update mechanisms and candidate vulnerabilities. Use supported runtime observations where they add context, while keeping device-specific reachability and physical behaviour in the wider test plan.
Compare and prepare the deliverable
Use Delta Intelligence and available FunctionDiff evidence for the candidate release. Reassess earlier triage decisions, verify relevant changes and export recognised inventories, reviewed VEX or assessment reports for the release stakeholders.
The result of the work
Evidence for the next product decision.
A focused release comparison
Added, removed and changed evidence directs engineering attention to the areas that need fresh investigation.
A customer review package
An appropriate inventory and assessment output with its scope and reviewed decisions, ready for the recipient's own product-security process.
A focused evaluation
Test the workflow with evidence your team already understands.
Use a representative product and two releases that your engineers understand. Include a known component or patch change and inspect how the analysis represents it. Agree the useful deliverables and the additional hardware or manual testing the product needs.
Agree the participating team, input scope and expected deliverable before expanding the rollout. The most useful evaluation shows how a real owner investigates and acts on the result.
Practical questions
Planning for firmware and connected devices.
Do we need the source code?
FDIE starts from the firmware image. Source, symbols and supplier information can help an investigation, but the product workflow is built around available image evidence.
Does a supported CPU guarantee a complete assessment?
No. Packaging, extraction, ABI, stripped metadata and hardware dependencies influence the methods that can run.
Can a product team start self-service?
Yes. The published FDIE self-service plan is paid at checkout, with a 14-day money-back guarantee on the first payment if three or fewer new images have been analysed. Dedicated and on-premises requirements are arranged through Enterprise.
FDIE · next step
Start with one authorised firmware assessment.
A reviewed component delta, investigated patch candidates and a release record with remaining findings and coverage gaps.
Paid at checkout. 14-day money-back guarantee on the first payment if three or fewer new images have been analysed.