Pre-RFC: CycloneDX BOM taxonomy

I propose that we publish an official document describing a nix namespace for CycloneDX and register that namespace at cyclonedx-property-taxonomy.

CycloneDX is a modern standard for the software supply chain. At its core, CycloneDX is a general purpose Bill of Materials (BOM) standard capable of representing software, hardware, services, and other types of inventory. CycloneDX is an OWASP flagship project, has a formal standardization process and governance model through Ecma Technical Committee 54, and is supported by the global information security community. - https://cyclonedx.org/guides/OWASP_CycloneDX-Authoritative-Guide-to-SBOM-en.pdf

This namespace would be used for attaching Nix-specific properties to BOM components.

The Spack package manager already has a namespace registered so the CycloneDX working group probably expect us to do the same - Spack SBOM example.

I imagine the document that we produce would just be markdown describing a list of properties that we use. We wouldn’t attempt to restrict the namespace to only the properties that we describe. This document would be for the sake of interoperability between tools.

The Namespace

A Nix namespace is already used by Genealogos for describing NAR archives as BOM components using nix:narinfo - example sbom.json.

From looking at the code it seems they define the following:

  • nix:narinfo:store_path
  • nix:narinfo:url
  • nix:narinfo:nar_hash
  • nix:narinfo:nar_size
  • nix:narinfo:compression
  • nix:narinfo:file_hash
  • nix:narinfo:file_size
  • nix:narinfo:deriver
  • nix:narinfo:system
  • nix:narinfo:sig
  • nix:narinfo:ca
  • nix:narinfo:references

I’m making this proposal because I am working on a tool that produces lockfiles that contain the information necessary to build Fixed-Output-Deriviations. The properties that I’m using are:

  • nix:fod:method - value of "fetchzip" or "git", etc
  • nix:fod:path - value of Nix store path
  • nix:fod:ref - Git ref, where applicable
  • nix:fod:rev - Git rev, where applicable
  • nix:fod:sha256 - FOD hash (use self-describing digests?)
  • nix:fod:url - URL to fetch

I don’t have the code to demonstrate it yet but it should be possible to import a BOM with fromJSON and generate FOD expressions from this.

Use outside Nixpkgs

A nix namespace could be used in the BOMs of external projects to describe development environments or created by CI to describe test environments.

Use within Nixpkgs

These BOMs could be used within Nixpkgs as a lockfile format as they are, but I consider them too bloated. They could instead be used as an intermediary format from which we extract minimal lockfiles from, or as format to which we render lockfiles to for consumption by auditing tools.

Issues and PRs

4 Likes

If we make a canonical taxonomy document I think we should just put it in Nixpkgs somewhere. If there was a root of all Nix projects it would be Nixpkgs.

The narinfo property was not very carefully considered. So we are open to changing or unifying further. For instance, I’m relatively convinced a nix:store_path property would also make sense, regardless of what source the path comes from.

1 Like

This is a PR now doc/interoperability: new chapter and section on CycloneDX by ehmry · Pull Request #316626 · NixOS/nixpkgs · GitHub.

1 Like