2. We want the vulnerability report, which is usually generated from the SBOM (versioned list of software components). The VEX feed helps to supress false-positives when generating the vulnerability report
3. Yes. It works for any flake (including full OS) or store path.
4. Yes
5. It is not just removing the boilerplate from your config, but to centralize triage decisions. If we codify the decision if a vulnerability affects a specific configuration, this check is free. I would love to contribute this back to the nix ecosystem, because package maintainers are in a better position to write these conditions.
> But is it easier to add this annotation to nixpkgs than it is to get pam/sshd fixed upstream?
It is possible to improve the scanner implementations and CVE databases to remove these false-positives without VEX, e.g., making better use of package URLs and/or CPEs, but this requires tooling support and better data sources.
In the meantime we have to make due with VEX and craft statements for systems we need deploy today.
Regarding your thought flow:
1. Yes, this is the overarching question
2. We want the vulnerability report, which is usually generated from the SBOM (versioned list of software components). The VEX feed helps to supress false-positives when generating the vulnerability report
3. Yes. It works for any flake (including full OS) or store path.
4. Yes
5. It is not just removing the boilerplate from your config, but to centralize triage decisions. If we codify the decision if a vulnerability affects a specific configuration, this check is free. I would love to contribute this back to the nix ecosystem, because package maintainers are in a better position to write these conditions.
> But is it easier to add this annotation to nixpkgs than it is to get pam/sshd fixed upstream?
Some CVEs are not patchable, because they don't exist in NixOS. See this OpenSSH CVE that only exists in RedHat products: https://access.redhat.com/security/cve/cve-2026-55653
It is possible to improve the scanner implementations and CVE databases to remove these false-positives without VEX, e.g., making better use of package URLs and/or CPEs, but this requires tooling support and better data sources.
In the meantime we have to make due with VEX and craft statements for systems we need deploy today.