You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of the challenge of the local scanner is to create an inventory of all currently-installed packages.
This is similar to Nix-Security-WG/nix-security-tracker#8 on the server side, but different: locally we only care about the runtime closure of the package, which means the packages actually need to be build. Luckily that isn't a problem: since we're reporting on installed derivations, we can assume they have been downloaded/built anyway.
Possible existing components to build on here are:
In the future the things we do in the security tracker project might be upstreamed back into those tools or something new like Genealogos.
I have tested sbomnix /nix/var/nix/profiles/system will happily create an inventory of the current state of the system. This is great, because it means we can also do this when packaging the local scanner as a service: this saves us from needing to have a somewhat-circular reference to 'ourselves'/'our own inventory'.
Notably absent from the sbomnix output is that 'attribute path' of the derivation in nixpkgs. Not all derivations have an attribute path, but it is often informally used as "package name" (and sometimes distinct from the attribute name).
Future evolution of this component, but likely outside the scope of the initial milestone, include:
Look into vendored dependencies
Keeping the 'tree view' of the dependencies and applying filters (like "component X has a vulnerability but it is known that project Y which depends on X is not affected"). sbomnix will report on the dependencies between derivations in its CycloneDX output.
Taking into account applied patches. sbomnix will report on 'patches' in its .csv output
Catching any derivations installed by nix-env, in nix shells etc. Longer-term it might be interesting to for example scan all GC roots, or even all contents of the cache, but for the first milestone that seems reasonable to keep out of scope.
The text was updated successfully, but these errors were encountered:
For the long term, the easiest is to open a copy of the SQLite database of Nix to find about the valid paths on disk or to cooperate with the Nix store API.
Part of the challenge of the local scanner is to create an inventory of all currently-installed packages.
This is similar to Nix-Security-WG/nix-security-tracker#8 on the server side, but different: locally we only care about the runtime closure of the package, which means the packages actually need to be build. Luckily that isn't a problem: since we're reporting on installed derivations, we can assume they have been downloaded/built anyway.
Possible existing components to build on here are:
In the future the things we do in the security tracker project might be upstreamed back into those tools or something new like Genealogos.
I have tested
sbomnix /nix/var/nix/profiles/system
will happily create an inventory of the current state of the system. This is great, because it means we can also do this when packaging the local scanner as a service: this saves us from needing to have a somewhat-circular reference to 'ourselves'/'our own inventory'.Notably absent from the sbomnix output is that 'attribute path' of the derivation in nixpkgs. Not all derivations have an attribute path, but it is often informally used as "package name" (and sometimes distinct from the attribute name).
Future evolution of this component, but likely outside the scope of the initial milestone, include:
sbomnix
will report on the dependencies between derivations in its CycloneDX output.sbomnix
will report on 'patches' in its .csv outputnix-env
, innix shell
s etc. Longer-term it might be interesting to for example scan all GC roots, or even all contents of the cache, but for the first milestone that seems reasonable to keep out of scope.The text was updated successfully, but these errors were encountered: