Actually, reading it again from the bottom up, it sounds like this is the thought flow:
1. You want to know if your os is vulnerable
2. You need a vex feed (sbom? the vulnerability report itself?) for your os
3. sbomnix provides a mechanism for getting sbom from a flake, but not a full os, and that can be compared to the advisories. But here it reports a false positive.
4. (Logical jump: we can use vex as an additional layer to disable irrelevant advisories based on system config) Here's an example of adding a vex (edit: not-)vulnerability report to a package conditional on config (sshd)
5. `nixos-vex` is a module to make it easier to integrate these reports (removing the boilerplate from the example)
Maybe this is a TLDR?
- sbomnix already provides package sbom in standard format which produces a conservative set of reports (superset) for a system
- `nixos-vex` provides a mechanism for integrating conditional vulnerability reports into nix packages
- Someone (also nixos-vex?) starts adding vulnerability reports to existing modules like ssh
- Combine them to get full coverage
I guess the comparison to govulncheck was that this is also like reachability analysis, but this is completely different - reachability analysis is calculatedly correct. This requires hand-annotation that could have issues and produce false positives or negatives. And you need to add each report manually and keep it synced with the database. I feel like this could be better than nothing (how much effort would it take to maintain?) and the "default conservative" approach is good.
Is the idea you'd only do this for long-term unfixed issues, and for the ones that do get fixed you'd just tolerate a few extra system upgrades? But is it easier to add this annotation to nixpkgs than it is to get pam/sshd fixed upstream?
Edit: I think "Finally we have the payoff" came several paragraphs too early. `sbomnix` reporting a false positive isn't payoff, and isn't anything to do with vex.