From CVE scanning to actual vulnerability management
CVE scanning gives visibility into an embedded image. It doesn't tell you what to do about it — that takes product context, evidence-based triage, and proof that a fix actually reached the device.
Adding CVE scanning to an embedded Linux build is useful. It gives you visibility into the software in the image and the vulnerabilities associated with it. But the first time a scan produces hundreds or thousands of findings, another problem becomes obvious: knowing that a CVE exists is not the same as knowing what to do about it.
In one of the platforms we maintain, the release process now generates an SBOM, performs CVE scanning and keeps the results between releases. That means we can see what changed: which vulnerabilities disappeared, which were introduced, and which components are responsible. That is already a significant improvement over having no structured view at all.
But it is still only visibility.
A scanner creates visibility. Product context turns it into something actionable.
What changed?
SBOM and CVE data show which findings are associated with the software in this build.
Does it actually matter?
Check configuration, backports, exposure and how the component is used in the real product.
What should we do?
Update, mitigate, monitor, investigate or accept with a documented rationale.
Change the product
Implement, test and deploy the chosen remediation or mitigation.
Close the loop
Confirm the change reached the product and track the result across releases.
Visibility → Context → Decision → Action
Context is what makes the data useful
A scanner generally works from software names and versions. An embedded product has much more context than that. A vulnerable feature may not be compiled into the image. A vendor may have backported a security fix without changing the version in the way the scanner expects. A service may exist but not be reachable in the deployed product.
So the useful questions become different. Does the vulnerability actually apply to this build? Is the affected functionality enabled? Is the component exposed? Is there evidence that the vulnerability is being actively exploited? And, most importantly, what would exploitation mean for this particular product?
That leads to a much more useful model:
Visibility → Context → Decision → Action
The aim is not to make every decision automatically. It is to use evidence to remove obvious noise so that engineering attention is spent on the findings that really require judgement.
The action depends on the product
If a vulnerability matters, the obvious answer is often to update the software. In embedded systems that may still require validation, maintenance windows or coordination with the physical system the device controls.
Sometimes the permanent fix cannot be deployed immediately. In that case there may be a period where mitigation or monitoring is appropriate while the update is being prepared. That could mean reducing network exposure, disabling affected functionality or adding temporary detection for known exploit behaviour.
Monitoring is not a replacement for fixing the vulnerability. It is one possible control during the time between discovery and remediation.
A patch existing upstream is not the same as a patch running on the device. Detection can bridge that gap — it does not close it.
Vulnerability disclosed
A CVE is published. Fix status upstream is often still unknown.
Upstream ships a patch
The permanent fix exists. It hasn't reached this device yet.
Detection rule deployed
A narrowly-scoped signed update hot-reloads new detection content without a reboot — buying time while the real fix is validated.
Patch deployed to device
The permanent fix is validated, built and shipped through the normal update path.
We've proven the detection side of this end to end on real hardware — a real disclosed vulnerability, exploited, detected, and hot-reloaded twice without a reboot. See it on our vulnerability management page.
The final step also matters: did the fix actually reach the deployed product? A vulnerability-management process should therefore connect the finding to the engineering decision, the resulting update or mitigation, and evidence that the action was deployed.
The scanner is the easy part
None of the individual technologies involved here are particularly novel. SBOM tools exist. Vulnerability databases exist. Update frameworks and monitoring systems already exist.
The difficult part is making them useful together in the context of a real device: its exact build, hardware, configuration, update mechanism and operational constraints.
That is the difference between generating a CVE report and actually managing vulnerabilities.
We walk through this same loop end to end, on real hardware, with real CVE numbers, on our vulnerability management page.