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.
In the light of recent supply chain attacks I have conducted a scan of the top 10k repos (by stars) using the GHA security scanner zizmor.
The results are quite sobering. Many of the recent supply chain attacks were preventable, since zizmor is pointing out the exact weaknesses that were used: unpinned dependencies, template injection, ... and many more.
Happy for any input and feedback on the data and presentation, as well as ideas on how we use this to improve the security posture of our open source community!
For me, it always starts with becoming a user first. By using the software, you're more likely to stumble upon bugs, missing features, or areas for improvement—perfect starting points for your first contribution!
In my case, I ran into a MIME type issue while serving a WebAssembly game with Hugo. That small frustration turned into my first pull request to the project.
Just came out of a deep rabbit hole after wondering: “Why does my laptop get hot watching YouTube?"
Thought I share my findings, mostly to have an easy reference to information that is distributed between ArchLinux forum, Chromium docs & random SO posts.
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!