That sounds like a bug in the job or task. If it is sensitive or have special needs, then it should save its state during shutdown and restart the job or task after the reboot. Avoiding updates and reboots due to defective software is just compounding the problem.
That assumes are updates are labelled properly. What I’ve found is, some (many?) could be and some are mislabeled.
The problem is, a bug is “security related” if it obvious or has a working proof of concept. That is, it is not-serious unless proven otherwise. I feel that is the wrong end of the stick. Many bugs should be considered serious or security related unless it is proven otherwise.
As a maintainer and contributor to several packages, I can tell you I fix a lot of problems that probably should be considered serious or security related (and even have a CVE). But I don’t bother trying to develop a POC or get a CVE because it is a waste of my time. I’ve seen nearly every other project I monitor or contribute to do the same. Other project maintainers are in the same situation. We only have a limited number of cycles to spread among responsibilities.
The efficient use of time for maintainers is, identify the problem, fix the problem, push the fix, ask folks to test, and push a new release. Lather, rinse, repeat.
Hmmm… the Risk Management Frameworks I have worked with all place a priority on patches and updates. Patches and updates have their own line item.
An updated machine is one part of a defensive strategy. I’ve never seen a risk strategy skip the patches and updates.
Skipping the patches and updates is known to be a bad idea. Microsoft performed a study in the early 2000’s and found a machine was under attack within 30 seconds of being connected to the internet. Microsoft also found compromised machines were compromised using vulnerabilities that were 30 days or older. Patches and updates were available, they just weren’t applied.
Choice is good. If someone is savvy like you, then that is fine. You should have to do something special to get into a less secure/insecure state.
The vast majority of users are not like you. They need this stuff to just work out of the box. For the vast majority of users, they need to be in the more secure state out of the box.
A fellow I worked with at Cigital once told me, “developer driven security is some of the worse security you will encounter.” He was right. Apt, dnf, pkg, yum and friends are the embodiment of it. The package managers are insecure out of the box based on some crap developers have come up with. The developers are completely out of touch with reality. I’ll even go so far to say most of them have not read Peter Gutmann’s Engineering Security or Ross Anderson’s Security Engineering. Most developers have not reached the point they can identify the problem.
A great example of an [incorrect] assumption is, every user is savvy like you. We know they are not. Most users are not qualified to make security related decisions. Another [incorrect] assumption is, all users have buggy long running jobs or tasks that don’t save state and can’t be restarted. I seriously doubt most users have long running tasks with buggy software.
The need for a reboot is not negotiable. If a reboot is required, then it is necessary. One who chooses to forgo the reboot is running with unpatched, buggy software. One who chooses to forgo the reboot is simply making a bad decision. They probably have an equally bad excuse why.