chore(dev): add vulnix CVE scan with a baseline whitelist

[sshine]

flake/vulnix.nix:

• Scans build closures of the checks.packages linkFarm and devShells.default.
• Passes .drv paths via unsafeDiscardOutputDependency; building lowers scan surface.
• Not a flake check: NVD feeds need network and closures need the daemon, neither in the sandbox.

flake/vulnix-whitelist.toml:

• A baseline, not an assessment: 30 entries, 121 CVEs, 32 derivations, generated to start green.
• Worth lies in change detection; entries key on name-version and cve matches only as a subset.
• Re-triage by hand: --write-whitelist absolves every current match in one go.

CI:

• Own workflow on manual dispatch, so the cold-cache NVD download never blocks a pull request.

[sshine]

I'm not sure how relevant CVE reporting is to kubenix. I was contacted by some security startup proposing to CVE scan my open-source projects, and I figured this is pretty easy for pure Nix.

We can let this PR hang until I have determined what a systematic approach is to removing the gigantic whitelist. I need this for $DAYJOB, so I'll probably be motivated to get back to it.

[adrian-gierakowski]

mkShell derivation cannot be built.

I thought this limitation has been removed

[Copilot]

Pull request overview

Adds an on-demand vulnerability scanning entrypoint to the flake using vulnix, along with a baseline whitelist and a dedicated GitHub Actions workflow so scans can run outside of sandboxed flake checks.

Changes:

• Adds a new flake app (nix run .#vulnix) intended to scan the build-time closures of checks.packages and devShells.default.
• Introduces a baseline vulnix whitelist TOML file to gate the scan and enable change detection over time.
• Adds a manual-dispatch CI workflow that installs Nix, caches the NVD feed, and runs the scan.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
flake/vulnix.nix	Adds a flake app wrapper to run vulnix over selected derivation closures with a whitelist.
flake/vulnix-whitelist.toml	Adds a baseline whitelist snapshot for initial “green” runs and future diff-based re-triage.
.github/workflows/vulnix.yml	Adds a manually triggered CI job to run the scan with NVD feed caching.
CHANGELOG.md	Documents the new nix run .#vulnix workflow and CI invocation approach.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[adrian-gierakowski]

Other than this I have no other comments. AI review comments look reasonable, could you please respond to them, either by fixing or motivating why the comment is no valid? Thanks!

[sshine]

I thought this limitation has been removed

Yes, this comment is wrong. It refers to an artifact of history.

The code in question:

# vulnix reads .drv files, so instantiating is enough; asking for the
# outputs would also build them, and mkShell derivations cannot be built.
drvPath = package: builtins.unsafeDiscardOutputDependency package.drvPath;

vulnix identifies vulnerable packages by reading name-version pairs out of .drv files: build recipes, not build results. So the app has to hand vulnix a list of .drv paths. The "cannot" should be a "should not"; scanning the build-time closure rather than the output closure leads to 1541 derivations rather than 68.

I'll clarify the comment to say that mkShell shouldn't be built rather than it can't.

AI review comments look reasonable, could you please respond to them

For some reason, I have not yet encountered a Copilot review comment that wasn't 100% useless and hallucinated. I think agentic code review needs to first and foremost look at the CI log. If, for example, nix run .#vulnix was run, it wouldn't have to say it might not work.

I'd like to look into what's the most satisfying review agent. Atuin uses Greptile and CodeRabbit, and they're almost as annoying, but they have found things; partly because of relying on extensive CI, e.g. reporting performance regressions, and giving a 4/5 or 5/5 score on whether the PR actually achieves what it claims.

[adrian-gierakowski]

I wonder if it would make sense to run it whenever deps are bumped in .github/workflows/update-flake ?

[sshine]

Yea, I also thought of running it on flake.lock changes. But let's say there is a new CVE; should the action fail? Then external factors would block merging.

Updating the whitelist as part of bumping the lockfile (extending the list of CVEs not accounted for) would be an option. But I think it might just lead to more automation traffic.

If we were to fail CI because of something CVE-related, it could be if something is removed from the whitelist, matching against NVD should not make it reappear. (Since removing a whitelisted CVE means we've dealt with it by bumping or removing a dependency.) When something can fail, it makes sense to introduce a cache again.

The CI automation is interesting. I'd like to work on bringing the number down, though. terranix's is even worse because it has some really dumb dev deps, like CUPS (the printer system).