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

  • 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.

  • 0

    My experience is five years old and may be stale dated.

    Our dev environment conditioned what happened in production. It also made it difficult to know the condition of dev with all the testing.

    Level of exposure was one deciding factor. Yeah sure it is possible but how possible in our environment. Having more than one mind to do the evaluation helped considerably. It help balance the focus of I might get fired if it happens here against we are to good for it to happen here.

  • 0

    Great question. Everything needs planning but common sense should still prevail.

    Wasn't it Warren Buffett who once said "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently."

    Hence be proactive. Trying to recover from the scenario where someone finds a critical bug that you've been ignoring, or worse, trying to hide and it's generally tickets.

    The goal isn't to have zero CVEs (which is impossible); it's to try to have zero surprises.

  • 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.