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 