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. On our reference platform that's 2,418 kernel CVEs and 6 u-boot CVEs evaluated per build, 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 kernel CVE volume by roughly 10% automatically on our reference build, each dismissal cited with its reason. What's left is cross-referenced against CISA's known-exploited-vulnerabilities catalog and EPSS exploitation-probability scores: of 2,460 unpatched CVEs on that build, 2 are confirmed actively exploited.
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, not asserted: a real disclosed vulnerability (CVE-2026-73283, an OpenSSH restrict bypass) exploited against our own reference build, 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, verified live on hardware twice.
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 is hardware-verified end-to-end on our own reference build; secure boot is a related but separate piece of work, and is intentionally not claimed here — it's tracked honestly on the platform tracker.
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.