Frameworks, inventories & disclosure
FDIE organises firmware findings into technical control checks, component inventories and reviewed vulnerability decisions. Product teams can prepare a clearer assessment record while keeping legal applicability, manual checks and organisational duties in view.
Technical evidence in context
FDIE’s mapped technical checks cover areas such as credentials, cryptography, update mechanisms, hardening and supported runtime observations. Framework views connect those checks to the available firmware evidence and highlight work that needs a person.
The maintained mapping inventory includes ETSI EN 303 645, EN 18031 parts 1 to 3, OWASP FSTM, NIST SP 800-193, NIST IR 8259A, IEC 62443-4-2, IEC 81001-5-1, FDA section 524B and TEC 31318. Check the configured edition, category and mapping before using a result in an assessment.
A mapped check supports a particular technical question. Hardware properties, operating procedures, privacy practice and lifecycle obligations may need evidence outside the firmware image.
Product, firmware identity, framework edition and applicable requirements.
Mapped checks, recognised components, observations and assessment coverage.
Applicability decisions, manual checks and evidence beyond the firmware image.
The result, responsible reviewer and reasoning for the product assessment.
Assessment workflow. Technical evidence supports the responsible team’s wider conformity review.
Look below the grade
A score is only interpretable with its assessed scope. Read the underlying check, evidence and disposition, then investigate manual and unassessed areas before drawing a product-level conclusion.
| State | Meaning for the reviewer | Next action |
|---|---|---|
| Pass | The assessed technical check met its configured condition | Retain the supporting evidence and confirm applicability |
| Fail | The assessed check found a condition needing attention | Investigate impact and assign a corrective action |
| Manual review | A human decision or additional evidence is needed | Record the assessment and its basis |
| Not applicable | The check is excluded for the recorded scope | Validate the reason for exclusion |
| Unassessed | The required evidence or supported analysis was unavailable | Plan the missing assessment; do not count it as a pass |
Weighted scores and raw pass rates can use different denominators. Compare equivalent scopes and assessment versions. Neither a grade nor a collection of passed technical checks is a certification, regulatory approval or complete conformity assessment.
Deliverables with a defined purpose
An engineer investigating a component, a customer requesting an SBOM and an assessor reviewing a control need different artifacts. FDIE supports exports that preserve the available identity and assessment context, with analyst review before distribution.
CycloneDX and SPDX describe recognised components and available versions, identifiers, licences and relationships. Use them for supply-chain review and component follow-up.
Check extraction and identification coverage before calling an inventory complete.
CBOM output records supported cryptographic evidence for a focused engineering review. Use it to locate recognised components or algorithms needing investigation.
Unrecognised wrappers, inaccessible regions and runtime-only use can remain outside the inventory.
VEX communicates reviewed applicability and the rationale associated with a vulnerability and product. It helps recipients distinguish a candidate match from the team's assessed position.
A not-affected decision needs a defensible reason and should be revisited when its assumptions change.
CRA disclosure review
A candidate CVE, a KEV entry or a runtime observation can start an investigation. The responsible product team determines whether an obligation applies, when it became aware and what action is required.
FDIE provides a separate disclosure-review workflow for assessment reasons, awareness times and submission references. The record helps coordinate the work; it does not independently determine legal reportability or send a notification to an authority.
Identify the affected product, release, responsible owner and available vulnerability evidence.
Document applicability, awareness context and the reason for the disclosure decision. Bring legal and regulatory expertise into the decision where needed.
The responsible team completes any required submission and retains its reference and follow-up in the review record.
TARA and MITRE EMB3D
Recognised components, services, boot evidence and runtime observations can help organise candidate threats. The product team adds the assets, trust boundaries, physical access and operating assumptions that the image cannot establish by itself.
Use the resulting record to focus engineering and assessment work. Keep inferred threats distinct from demonstrated vulnerabilities and preserve the human decisions that turn a generated starting point into an assessment.
No. It produces technical evidence for a wider assessment. Applicability, conformity and any independent certification remain separate decisions.
The score should be read with the assessed scope, mapping version, individual evidence and unassessed controls. It is not a standalone assurance statement.
FDIE self-service and Enterprise include the product capabilities. Deployment, resources, support and contract terms differ; image and analysis compatibility still apply.
FDIE · next step
Start with an authorised image, select the relevant framework scope and review the findings, manual work and export formats with the people who will use them.
Paid at checkout. 14-day money-back guarantee on the first payment if three or fewer new images have been analysed.