Somewhere, someone has released a medical device running on Linux and they have installed unattended-upgrades or a similar thing xD

There's a few DIY insulin pumps, and surprisingly one of them recommends a full apt upgrade: https://openaps.readthedocs.io/en/latest/docs/Customize-Iter...

Or, they have released a medical device with customized Linux software and not shared the source as the license requires because it's "proprietary information".

And probably by accident, at that. Ubuntu's default apt configuration is rather... chatty.

Are you seriously recommending that people disable security updates as though that somehow makes anything better?

Automatic updates? Yes.

If the alternative is a medical device running in an untested configuration, that may well be worse.

Instead, updates should be verified by the manufacturer and pushed out on a schedule.

To elaborate on the parent's point, you should not be running automatic updates because you should be running manually verified and rigorously tested updates before you push a change in a safety-critical component. This is because an update to every device containing that component introduces a correlated failure mode. If the change is bad, you risk harming or killing everybody at the same time. This is in contrast to standard hardware failures modes which are much more likely to be uncorrelated, so the chance of harming everybody at the same time is (1 / FailureRate) ^ N. If a safety-critical system requires updates and can not verified and tested in context before being deployed it is criminally irresponsible to deploy such a system. Both automatic and no updates are similarly inadequate in much the same way that even though cardboard is stronger than tissue paper, neither is an adequate bridge building material for a car-carrying bridge.

tl;dr Both no updates and automatic updates are criminally irresponsible. If you can not verify and test updates in context for an appropriate amount of time to verify safety stop before you kill somebody.

"Security updates" are for things doing all kinds of network stuff - exposing ports, running untrusted code inside sandboxes, that sort of thing. Your insulin pump should absolutely not be doing any of those things.

Reproducibly insecure kernel probably sitting on that network.

That is the biggest engineering challenge for these products. Having timely, effective, accurate SOUP anomaly reviews are critical to ensure that you have patches for issues in the wild, so you don't end up in a situation where you are running vulnerable software for years and years.

This is also why you see a lot of RHEL and SLES in healthcare - commitments for EOL and support timelines are key, and drive a lot of planning for device makers.