I use #QualvoSec (https://github.com/gyptazy/QualvoSec).

You can find a the slides of my tech talk here: https://cdn.gyptazy.ch/tech-talks/QualvoSec_Security_Patch_Management/QualvoSec_A_Security_Patch_Management_Tool.html

In addition, also other distribution are/were affected. Even #Debian but luckily not stable ones. Please take a look if you might also be affected and update immediately. Securitypatchmanagement software like #QualvoSec may help you.

#QualvoSec Features:

* Not running as root
* Only specific commands allowed by sudo
* Clients pulling information from server
* Server provides only a static manifest
* Holding the patch windows
* No remote code executions
* A potential compromised server could not be able to execute code on clients
* Health monitoring endpoint on clients
* Minimalistic design
* Admin tool for creating, deleting and looking up of client patch windows
* Fully written in Python3
* Integrated packaging support by CMake
* CMake/CPack created .deb and .rpm files
* Support for Linux, BSD
* Support for AMD64, ARM64 and RISC-V hardware architecture

@[email protected]

Thanks for your feedback!

First, it doesn’t run as root and only allows specific needed commands that are needed on the platforms to perform upgrades (see also https://github.com/gyptazy/QualvoSec/blob/main/sudoers.d/qualvosec).

Next, the mgmt server does not have any access to the clients and only provides a static manifest (https://github.com/gyptazy/QualvoSec/blob/main/src/server/patch.yaml) holding the update schedules for the systems. In a worst case scenario, someone would be able to define another timeslot to perform upgrades on the nodes. No other code execution would be possible.

Regarding the last question:
I think this comes up to every operators own choice. Sure, you can use regular unattended updates but I think when you have a bunch of servers to manage validating and managing time windows might be more uncomfortable. Sure, you can use config management tools to push this to nodes, use them to get the configured patch windows etc. but that’s only usable for ops. Sure, you could write playbooks and abstractions layer around like Tower or Rundeck to gather the information by keeping in mind that everything gets collected by a code execution bridge.


Currently, I manage 43 personal systems a little bit more project systems with #QualvoSec benefiting from a static and centralized manifest holding the information which do not contain any sensible information. It does not allow the execution of other commands. As said before, it’s a centralized managing solution where it can easily be defined which system should be patched at which time slot. If there’s a reason for temporary stopping the patching, like a maintenance window, a special campaign where the system needs to be available, or something else this can just be placed there.

With the admin tool (and my case an abstraction layer for the parsing), customers can (re)define, temporary stop patching or define schedules from their webinterface, parsed by the admin tool which writes the manifest file. No ssh login, no cfg-mgmt run (with code executions). If a user or mgmt wants to look up schedules the same applies. Just parsing the manifest file by an abstraction layer to simply provide only the related resources.

That’s the background for creating this.