sbomnix: go and rust dependencies

[henrirosten]

Dependencies from rust and go projects are missing because they fetch their dependencies directly, so the dependencies are not included in the dependency trees produced by nix-store --query --graph, which is what sbomnix uses internally.

For rust, this should be fixed with: NixOS/nixpkgs#217084, but the problem still persists for all other ecosystems that fetch their own dependencies.

All suggestions for how to improve the dependency lookup for sbomnix are welcome.

[nikitawootten]

I'd like to add that derivations that utilize Yarn2Nix for JavaScript projects suffer from the same problem. It seems Yarn2Nix produces plenty of intermediate *.drvs but nix-store --query --graph of the output does not include them.

Edit: This issue may be separate of the issue described in the initial issue, however it seems there is a potential solution for those using Yarn2Nix as well as some potential improvements to the dependency fetching process.

When I nix-build the derivation in this example it prints a nix store path. nix-store --query --graph does not include my package's NPM dependencies, however running nix-store --query --deriver on the output store (and repeatedly rerunning the command on the new output until unknown-deriver is returned) seems to produce the derivation that contains the full graph of intermediate derivations, in this case including NPM packages.

Maybe this approach of traversing the "deriver" edge could be a good starting point for other package helpers as well. Maybe some logic specific to each package helper would be needed (for example for Yarn2Nix searching the package graph for the derivation that contains all NPM dependencies).

[henrirosten]

Hello @nikitawootten and thanks for your comment!

When I nix-build your example, I get the following result symlink:

$ ls -la result
result -> /nix/store/w7cnx4dqdnmmb0gv7vpm8gk22n9v40b5-oscal-deep-diff-1.0.0

Now, nix-store --query --graph result generates a runtime dependency graph, because the result symlink points to an output path. (1)

If I run nix-store --query --deriver result, it prints the deriver for the output path:

$ nix-store --query --deriver result
/nix/store/bwvf3jjz3x2xzf1sd5i6gvr62pi4m1z6-oscal-deep-diff-1.0.0.drv

Indeed, nix-store --query --graph /nix/store/bwvf3jjz3x2xzf1sd5i6gvr62pi4m1z6-oscal-deep-diff-1.0.0.drv generates a buildtime dependency graph, because it is now applied to a derivation. (2)

The difference between (1) and (2) is explained in the nix-store --query documentation:

$ nix-store --query --help
...
  • --graph
    Prints  the  references  graph  of the store paths paths in the format of the dot tool of AT&T’s Graphviz package. 
    This can be used to visualise dependency graphs. To obtain a build-time dependency graph, apply this to a store 
    derivation. To obtain a runtime dependency graph, apply it to an output path.

sbomnix actually already makes use of that nix-storey --query feature in its --type argument.

Question: if you run sbomnix --type=buildtime ./result does the generated SBOM include the dependencies you were expecting?

[arianvp]

How about we standardise on either an sbom output or an sbom derivation in the passthru field? just like passhtru.tests .

We can then put language-specific sbom generators in there and merge the resulting sbom with the nix sbom

[arianvp]

I guess we need both buildTimeSbom and runtimeSbom but you get the idea.