From CVE scanning to actual vulnerability management
A scanner produces thousands of findings. That's visibility — necessary, but it isn't vulnerability management on its own, and it doesn't close what's really the underlying problem for a shipped embedded product: the patch-latency gap between a fix existing upstream and it actually reaching a device in the field. The useful part starts when software inventory, vulnerability information, product context and engineering constraints come together — so somebody can make a decision and act on it.
That starts at the platform itself. A board frozen on the Yocto release it launched with stops getting upstream security fixes entirely — bringing old SoCs onto the same current Yocto release as new ones is part of this same problem, not a separate modernization project bolted on afterward.
Know what software is actually present
A software bill of materials (SPDX/CycloneDX) generated automatically per build, not reconstructed after the fact — plus CVE scanning against the real dependency set in that image, not a generic package list.
Determine what really applies
Not every CVE matching a package name applies to how it's actually built, configured, and exposed. Evidence-based checks — config-inapplicable, already-fixed, mismatched CPE — cut noise automatically, each dismissal cited with its reason. What's left is cross-referenced against CISA's known-exploited-vulnerabilities catalog and EPSS exploitation-probability scores, so attention goes to what's actually urgent.
Weigh it against product context
Severity and exploitability are half the picture. The other half is product context: how the device is actually deployed, what it's connected to, whether it's safety- or availability-critical, and what 'urgent' really means for that specific product — not a generic CVSS score read in isolation. Both halves decided together with your team, not handed over as a raw feed for someone else to work out.
Patch, mitigate, monitor or investigate
Fixes delivered through the secure update path we already maintain. Not every finding gets the same response — some get an immediate patch, some a compensating control, some a documented decision to accept and monitor.
Confirm it actually reached the product
Proven end-to-end on real hardware in our own engineering work, not asserted: a disclosed vulnerability exploited, detected in real time, and reported as a standard security-finding event (OCSF), confirmed indexed and searchable in downstream SIEM/SOC tooling. Detection content itself updates independently of a full firmware update — a second, narrowly-scoped signed update hot-reloads new rules without a reboot. Public, citable numbers from this pipeline are coming as bring-up completes on our NXP i.MX8M Nano reference platform.
The deeper loop
Visibility through Decision run today as part of our real engineering work, on any platform we maintain — not a roadmap item. Verification's detection-and- report pipeline has been proven end-to-end on real hardware in our own work; secure boot is a related but separate piece of work, and is intentionally not claimed here. Public, citable evidence for both — tied to a platform with no confidentiality constraints — follows once our NXP i.MX8M Nano reference build is ready.
The governing constraint throughout: security has to protect the product without preventing the product from doing its job. Embedded systems can't always patch immediately, and a control that ignores CPU, RAM, storage, bandwidth, latency, boot time, or power isn't a real answer on a constrained target — every claim here is backed by functional proof, resource-impact proof, and deployment evidence, not just a mechanism that runs in a lab.