Is your feature request related to a problem?
Some companies require running an MDM/Remote management solution for "security&audit purposes". One of the most trivial checks used by these solutions on traditional distros is usually to enumerate installed packages+versions and submit them to a centralized fleet management system which then acts (or doesn't act) on that info appropriately.
Nix provides neither simple nor robust enough way to enumerate installed packages.
Currently the only way (known to me) to enumerate packages is either parsing the entire nix store (such as nix-store -qR <gcroots...>) and guessing which derivations/outputs are "packages" or querying the Nix database with similar results but better performance.
The three main problems with both of these solutions are
- performance
- robustness
- identify derivations which constitute a "package"
(not to mention the difficulty to define what "package" is in the first place, see additional context)
Proposed solution
Nix should provide a way for 3rd party software to query installed packages, preferably in a fast and non-resource-consuming way.
To me the best solution would be a database, either as part of the Nix DB or a standalone database managed by Nix which could contain a table with a schema similar to:
CREATE TABLE StoreSbom (
id integer primary key autoincrement not null,
type text not null, -- "package", "library", "file", "config", ...
path text unique not null,
name text not null, -- name of the package
version text not null, -- version of the package
source text not null, -- "github", "nixpkgs", "pypi", ...
purl text, -- PURL string of the package
cpe text, -- CPE string of the package
installedTime integer not null,
);
Such a database would allow 3rd parties to make very simple and high-performance queries with little to no programming overhead.
Alternative solutions
Use a flat file or directory structure to provide SBOM, such as /nix/store/sbom.json. While the end result will likely be similar to the database approach, the performance considerations are very much in favor of a database rather than flat files both for creating the SBOM and querying it.
Additional context
There is already a PR in Nixpkgs to include PURL and CPE in the package metadata which I expect will be merged soon, so this data will be there to grab. name and version are already available for most nixpkgs packages at this time.
Current solutions (such as sbomnix or bombon) must generate the SBOM using various parsing techniques to identify installed derivations and guess whether the derivations are "packages" by making several assumptions and additional performance-heavy parsing (parse derivations, query local nixpkgs and other sources for metadata, etc.), making them rather slow and not easily integratable to 3rd party solutions.
Nix has access to all the necessary information to build and maintain the SBOM at runtime with very little performance overhead and could therefore rather easily maintain an SBOM on the fly and as such is in the ideal place to be the authoritative source of the data.
The definition of package in Nix is also a tricky thing but a good guess is imho better than having a lot of non-packages in the list. A good first filter is whether the derivation has a version set (in case of nixpkgs it's usually pname and version meta fields which both sbomnix and bombon seem to use as the primary source of certainty).
Generally a package could perhaps be defined "a derivation which content is akin to dpkg or rpm package" which is obviously very vague. I'm happy to discuss a more definitive definition. It's better to err on the side of caution and mark a non-package as a package rather than mistype an actual package as a non-package.
See also:
NixOS/nixpkgs#354012
NixOS/nixpkgs#409797
NixOS/nixpkgs#421125
https://discourse.nixos.org/t/nixpkgs-supply-chain-security-project/34345/34
https://discourse.nixos.org/t/list-all-installed-packages-version-for-audit-purposes/67280/2
osquery/osquery#8179
Checklist
Add 👍 to issues you find important.
Is your feature request related to a problem?
Some companies require running an MDM/Remote management solution for "security&audit purposes". One of the most trivial checks used by these solutions on traditional distros is usually to enumerate installed packages+versions and submit them to a centralized fleet management system which then acts (or doesn't act) on that info appropriately.
Nix provides neither simple nor robust enough way to enumerate installed packages.
Currently the only way (known to me) to enumerate packages is either parsing the entire nix store (such as
nix-store -qR <gcroots...>) and guessing which derivations/outputs are "packages" or querying the Nix database with similar results but better performance.The three main problems with both of these solutions are
(not to mention the difficulty to define what "package" is in the first place, see additional context)
Proposed solution
Nix should provide a way for 3rd party software to query installed packages, preferably in a fast and non-resource-consuming way.
To me the best solution would be a database, either as part of the Nix DB or a standalone database managed by Nix which could contain a table with a schema similar to:
Such a database would allow 3rd parties to make very simple and high-performance queries with little to no programming overhead.
Alternative solutions
Use a flat file or directory structure to provide SBOM, such as
/nix/store/sbom.json. While the end result will likely be similar to the database approach, the performance considerations are very much in favor of a database rather than flat files both for creating the SBOM and querying it.Additional context
There is already a PR in Nixpkgs to include PURL and CPE in the package metadata which I expect will be merged soon, so this data will be there to grab.
nameandversionare already available for most nixpkgs packages at this time.Current solutions (such as sbomnix or bombon) must generate the SBOM using various parsing techniques to identify installed derivations and guess whether the derivations are "packages" by making several assumptions and additional performance-heavy parsing (parse derivations, query local nixpkgs and other sources for metadata, etc.), making them rather slow and not easily integratable to 3rd party solutions.
Nix has access to all the necessary information to build and maintain the SBOM at runtime with very little performance overhead and could therefore rather easily maintain an SBOM on the fly and as such is in the ideal place to be the authoritative source of the data.
The definition of package in Nix is also a tricky thing but a good guess is imho better than having a lot of non-packages in the list. A good first filter is whether the derivation has a
versionset (in case of nixpkgs it's usuallypnameandversionmeta fields which both sbomnix and bombon seem to use as the primary source of certainty).Generally a package could perhaps be defined "a derivation which content is akin to
dpkgorrpmpackage" which is obviously very vague. I'm happy to discuss a more definitive definition. It's better to err on the side of caution and mark a non-package as a package rather than mistype an actual package as a non-package.See also:
NixOS/nixpkgs#354012
NixOS/nixpkgs#409797
NixOS/nixpkgs#421125
https://discourse.nixos.org/t/nixpkgs-supply-chain-security-project/34345/34
https://discourse.nixos.org/t/list-all-installed-packages-version-for-audit-purposes/67280/2
osquery/osquery#8179
Checklist
Add 👍 to issues you find important.