Generating Software Bill of Materials from Derivation

Development
1

I’m looking into generating SPDX and/or CycloneDX spec Software Bill of Materials (SBOM) from Nix derivations. I have a few questions and proposals.

  • Is anyone aware of any work on this already?
  • If there isn’t already tooling on this, I could write some tooling for this but does anyone have any thoughts on the approach to take to pull the right info from derivation/nix environment required for generating an SBOM? Not just from nix-env but from things like nix built containers?
  • This is part of some supply chain security and software factory work as part of the Cloud Native Computing Foundation (CNCF). We would like to work with the Nix community as Nix’s approach to reproducibility, traceability, determinism, etc. is huge for supply chain security. Is anyone interested in collaborating on this?
8 Likes
2

Related topic

4 Likes
3

Thanks. Glad to know I’m not the only one trying to solve a similar issue. I ran into the recursive issue when testing some of this out myself. The way I did it was I just dumped all nix package metadata to a json file and then queried it based on the info I was getting from derivations. I think I saw vulnix queries the nix database itself.

My basic approach has been to fetch all derivations through something like:

 nix-store -q --requisites <derivation>

Followed by then getting info about all packages

nix-env -qa --meta --json '.*' > pkgs.json

And then going derivation by derivation and creating a list of all packages and then looking up the metadata of those packages in my pkgs.json. It’s not efficient but has gotten the job done.

Additionally it would be nice to figure out an easy way to also fetch metadata about the NARs in the nix cache as well.

1 Like
4

So I did a very quick POC for generating SBOMs. It needs a bit of work to be fully compliant: mlieberman85/nixbom (github.com)

9 Likes
5

I think this is related.

6

cc @blaggacao as I recall him musing about a SBoM from Nix a while back.

7

My reasoning has been that in a completely flakified world, the flake.lock json could be tweaked to be a representation of a SBoM.

The runtime vs. build time deps question still applies and that a lot of packages are probably not most concisely declared in current nixpkgs.

We might need to start erroring out on packages that do not have a concise declarations of those XInputs.

1 Like