I am looking at this kernel issue and apparently Kernel 5.16.2 fixes the issue. Longterm kernels (5.15.16, 5.10.93, 5.4.173) are also fixed..
Now in nixpkgs I can see linux: 5.10.92 -> 5.10.93 · NixOS/nixpkgs@6c1f854 · GitHub, I am however using linuxKernel.packages.linux_hardened.kernel and that seems to be stuck with 5.10.92? What exactly needs to be done here?
After a PR is merged many packages need to build on Hydra, populating the binary cache, before the Nix channel will advance. Not every package is set to blocking, so that’s not always the case.
If you’re on unstable channel I see it updated 9 hours ago, so I assume it’s there now. You can check the same at status.nixos.org and there’s also a tool someone created for tracking PRs: Nixpkgs PR progress tracker
Thanks for the useful resources. I also found NixOS - Security Team. Ok, there is a link to GitHub issues that have a security tag but what I miss are some security advisories for high profile issues. It doesn’t have to be elaborate, perhaps just a quick one-liner: unprivileged user can escalate privileges with this, here is a link to the pull request and here is how you can check whether you are affected.
Also for CVE-2021-4034 it took me a while to find
polkit: fix local privilege escalation in pkexec by mweinelt · Pull Request #156750 · NixOS/nixpkgs · GitHub and that you can security.polkit.enable = false; as a workaround.
I understand this “am I affected” question is a bit harder to answer than in other distributions, but I can imagine that you could have some tool first checking your NixOS configuration (i.e., whether polkit is enabled) and then it could verify whether your nixpkgs contains commit ids (a and b) or (c and d).
It’s probably easier than on most distros. Your approach relies on metadata, which we can somewhat guarantee to be correct on NixOS, but is much harder to gather and actually assert on other distros - they have packages too, and ways to check if something is installed, it’s just their configuration story that’s a horrible mess 
For this reason, and because you can never be sure that metadata is correct, most CVE checkers are written to see if the exploit is usable. After all, it’s impossible to know whether a user impurely compiled their own polkit downstream even on NixOS.
With polkit it’d be a question of executing the binary and checking whether it tried to read something it shouldn’t if you set its first argv to NULL. I’m sure such checkers exist for this CVE, and they would work just fine on NixOS - modulo a patchelf if it’s pre-compiled.
If you still want to rely on metadata, you can use git log on the version of the nixpkgs repo you are using. You’ll note that the commit fixing this lists the CVE in its message. You can check which commit you are using either through flake.lock when using flakes, or some other arcane sorcery I’ve forgotten if you’re using channels.
Github’s search feature is sub-par, especially for keyword searches like this one. I would always suggest just using plain ol’ git and grep instead, or a web search engine if you desparately want to avoid the command line.
The commit policy makes no mention of listing CVE numbers currently, though. It’d be nice if it did, even if we can’t guarantee a CVE already exists when a commit is made. This would probably still catch most cases and be quite helpful when sleuthing later down the line 