Security updates are indeed sometimes slow to arrive, for the reasons that aidenn0 already described. However! One thing that's particularly interesting about the security update process for NixOS, is that it's an open collaborative effort: https://github.com/NixOS/nixpkgs/issues/23334

More eyeballs are definitely needed for handling security issues, especially since LWN stopped doing their reports, but the process itself is definitely one that has significant potential.

2. This will take a bit

First with the naive, as-described nix there are two options:

* For updates to propagate through all the build servers takes a day or two, so you can just be insecure for 48 hours

* Or, you can always build your packages yourself by setting your update channel to just be the head of the nix repository, but now you won't get binary caches for anything that has had its source updated since the last build. This actually works better than you might think, but is still a no-go for most people.

Both of those suck, so there is something called replaceDependency[1] that lets you define a package in terms of the already built-package and a new version of the library. This lets you quickly get a security update in a shared-library out to multiple slow-to-build packages quickly.

1: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-supp... The existing way is to use replaceDependency(), which takes an input as an already built package and as an output the same binary but with different RPATHs for the shared objects. This however is just stopgap, as other approaches are being discussed. Since I'm not running a server, I haven't followed it as closely as I perhaps should

They don't. NixOS does not have a concept of a released, stable distribution and therefore does not provide security patches backported to it.

You have to keep rolling forward with every new upstream release of the packages you use.

Perhaps it's OK for some people's desktops but most server environments rely or stable distributions with LTS support.