Actions
Forum Thread Details
  • State Not Answered
  • Replies 4 replies
  • Subscribers 474 subscribers
  • Views 199 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

    I'm trying to assess the risk, with a "score" given to all parameters.
    For instance, if it affects a one off demonstration project that is seldom connected to the network, I'm 99% sure I'll simply ignore the CVE.

    But if it impacts devices located at client's location and the CVE may given unwarranted access to their network, then I'm in favor of issuing an update (OTA, ideally). But then, it's the client's responsibility to apply it, and we've all seen what happens in real life.

    The update cost is rarely taken into account, because the liability clauses in the contract mean that I would bear the cost of any wrongdoing arising from me not acting against a reported issue.

    In the end, if it's a CVE that needs physical access, the default password not changed, and allows to simply change the appearance of the GUI, well, tough luck. I mean, if there is already physical access for the attacker, there are much more interesting things to compromise than defacing a product.

    I've also had a Java CVEs that required remote access to give root access to the attacker. Very much an issue, quite high CVE index (8-9) but I never patched it. Why? Because the device does not have any network interface whatsoever, so the attack cannot happen to begin with. But that's a rare situation, now that everything is (has to be?) connected.

Reply
  • 0

    I'm trying to assess the risk, with a "score" given to all parameters.
    For instance, if it affects a one off demonstration project that is seldom connected to the network, I'm 99% sure I'll simply ignore the CVE.

    But if it impacts devices located at client's location and the CVE may given unwarranted access to their network, then I'm in favor of issuing an update (OTA, ideally). But then, it's the client's responsibility to apply it, and we've all seen what happens in real life.

    The update cost is rarely taken into account, because the liability clauses in the contract mean that I would bear the cost of any wrongdoing arising from me not acting against a reported issue.

    In the end, if it's a CVE that needs physical access, the default password not changed, and allows to simply change the appearance of the GUI, well, tough luck. I mean, if there is already physical access for the attacker, there are much more interesting things to compromise than defacing a product.

    I've also had a Java CVEs that required remote access to give root access to the attacker. Very much an issue, quite high CVE index (8-9) but I never patched it. Why? Because the device does not have any network interface whatsoever, so the attack cannot happen to begin with. But that's a rare situation, now that everything is (has to be?) connected.

Children
No Data