Has anyone here tried sbomnix together with grype? How well does it work? Last time I looked into vulnerability checking for Nix, stuff seemed rather unreliable, though I'm not sure I looked into sbomnix (or it already existed at the time).
This was really interesting. I may be slightly outside of this space, but I would have liked a little bit more explanation. I felt like this was skipping a lot of motivations, goals, and steps.
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 for your os
3. sbomnix provides a mechanism for getting vulnerabilities from a flake, but not a full os
4. Here's an example of integrating it into the existing sshd package
5. He created `nixos-vex` which is a collection of changes to report configuration-relative vulnerabilities.
Or actually, does the final `grype` combine the vex-described vulnerabilities with the sbomnix info? I guess `nixos-vex` must have taken the non-composable example he provided and turned it into a module that automatically aggregates the reports, and probably has a lot less boilerplate?
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.
7 comments
[ 5.6 ms ] story [ 45.9 ms ] threadsbomnix writes purl (package URL) and cpe fields in the sbom, see the baseline SBOM in nixos-vex: https://github.com/datosh/nixos-vex/blob/6c6bbba6d30cf474dcf...
The nix purls are not supported by anything, as far as I can tell :/ But grype does a good job matching the CPE data!
Grype does warn about some unknown CPEs, for nix build artifacts:
Do try the demo: https://github.com/datosh/nixos-vex/tree/main/demo/desktop It should show you what's working today, there are definitely areas to contribute to the respective projects!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 for your os
3. sbomnix provides a mechanism for getting vulnerabilities from a flake, but not a full os
4. Here's an example of integrating it into the existing sshd package
5. He created `nixos-vex` which is a collection of changes to report configuration-relative vulnerabilities.
Or actually, does the final `grype` combine the vex-described vulnerabilities with the sbomnix info? I guess `nixos-vex` must have taken the non-composable example he provided and turned it into a module that automatically aggregates the reports, and probably has a lot less boilerplate?
Maybe this is a TLDR?
- sbomnix already provides package vulnerability reports
- `nixos-vex` provides a mechanism for integrating conditional reports into nix packages
- Someone (also nixos-vex?) starts adding vulnerability reports to existing modules like ssh.
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.