Rendered at 20:44:04 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
codethief 21 hours ago [-]
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).
datosh 4 hours ago [-]
I would be interested to hear from other folks as well! I tested a few combinations and sbomnix+grype gave me the best results.
This was really interesting, but very hard to follow. 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 (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.
datosh 4 hours ago [-]
Thanks, and I appreciate your feedback.
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?
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.
sbomnix 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 (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.
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.