Actions
Forum Thread Details
  • State Not Answered
  • Replies 4 replies
  • Subscribers 471 subscribers
  • Views 123 views
  • Users 0 members are here
Related

How do you decide which CVEs actually matter in embedded products?

micheal.embedded

In embedded products, patching every CVE often isn’t realistic due to certification, long test cycles, limited update windows, or system stability risks.

I’m curious how others handle this in practice. When a CVE affects a component in your system, what factors determine whether it gets patched immediately, deferred, or accepted as risk?

Do you prioritize based on exploitability, attack surface, physical access assumptions, update cost, or something else?

Parents
  • 0

    Almost by definition critical vulnerability means it needs to be addressed. It boils down to assessing whether it is critical or not. For us it means everything critical gets addressed and then we address as many non-critical issues as we have time and budget to tackle. In some cases critical issues have to be addressed with operational procedures as opposed to hardware or software fixes. The actual decision about what is critical is usually assessed using a risk vs cost matrix (if managers are involved). If it is just engineers, they have their own priorities, based on what they are willing to sign off on.

Reply
  • 0

    Almost by definition critical vulnerability means it needs to be addressed. It boils down to assessing whether it is critical or not. For us it means everything critical gets addressed and then we address as many non-critical issues as we have time and budget to tackle. In some cases critical issues have to be addressed with operational procedures as opposed to hardware or software fixes. The actual decision about what is critical is usually assessed using a risk vs cost matrix (if managers are involved). If it is just engineers, they have their own priorities, based on what they are willing to sign off on.

Children
No Data