New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve image introspection to let tools report CVEs & SBOM #70
Comments
Hello,
I never used this kind of tools but they doesn't seem to be supporting Nix (or nixpkgs).
Sorry, my answer is not really helpful, but this is related to the nginx closure (which comes from nixpkgs):
And I don't know why the FYI, here is the list of nginx image store paths, sorted by size:
|
Thanks @nlewo for your quick response.
I forgot to mention the source of these tools. These are standard tools used by cloud native enterprises. Following are their github repo locations: Query: Is there any specific tool that Nixpkgs recommend to scan these images or perhaps the store path? In fact none of the scanners that I know understand Nix store path. So the only way to integrate with existing scanners is to generate standard SBOM out of a nix realisation & let the scanners do the rest of the job.
AFAIK chainguard folks have been persistent in implementing various distroless images. You may be already aware that "distroless" is the name given to a container image that contains the application binary & its runtime dependencies & nothing else. For example, a distroless image will not have any build dependencies, package managers (s.a apt, apk, etc.), and utilities such as bash, etc. I will try to explain specifically about In order to build from source & produce the result as an apk file, they use melange. We can take a look at this melange file to understand how the GNU hello program is built from source & packaged into an apk file. If one has read the provided references they would have come across WOLFI which is the equivalent of nixpkgs. This is the melange yaml for nginx package found in WOLFI. The nginx package built (via melange file) here is referred to in apko file to produce the final OCI image(s). The list of other ready to consume OCI images can be found here. It will also help folks to read this blog to dive deep into WOLFI mechanics. Again my intention is not to advertise one over other. I am currently searching for an ideal package manager & better dev tools to generate OCI images that are minimal in size (preferably with 0 CVEs) & comply with SLSA guidelines. |
Looks like it will soon become possible to generate a SBOM from a Nix expression:
Sources: |
@nlewo Is there a way to get the CVE report using following tool: nix run github:tiiuae/sbomnix#vulnxscan -- ./result Can we build this nginx example as a regular nix build output? It will help us to feed the output to above tool which will generate SBOM on fly & further run against multiple scanners. |
@AmitKumarDas it is because vulnxscan fails if the Nix output path is a JSON file. I opened this vulnxscan issue. BTW, you could still get a result by using the
|
Thanks @nlewo
|
Hey @nlewo I am fine with closing this issue since most of my requirements are kind of solved. |
Hi Team,
Is there anything that can be done to introspect the built images. I was interested to check if existing SBOM tools & CVE scanners can derive some insights from the images generated via nix2container.
In addition, I wanted to understand the reason for the current size of the images. I believe they are not minimal & perhaps can be customised further s.t. the final image has less size.
E.g. I was doing a comparative study between the nginx image from chainguard
Note: nginx:x7fh59yyzwlrfsc98rw4bpkm4hcmg4dz was generated using nix2container
versus.
The text was updated successfully, but these errors were encountered: