Weird SBOM generation of minified images

[PinkSheep]

Hello
I recently analysed the SBOMs of minified images with some surprising results. I was hoping someone is able to help me better understand how these results come together.

As an example lets take a look at the following image: ghcr.io/sbb-design-systems/sbb-angular/showcase:14.4.3. This image was minified with the mint slim command. The base image is the following nginxinc/nginx-unprivileged:stable which again is based on a debian base image.

Lets now generate the SBOM of said image with the open source tool syft (the result is the same with other SBOM generation tools):
syft scan ghcr.io/sbb-design-systems/sbb-angular/showcase:14.4.3 -o syft-json
The resulting SBOM weirdly still contains a lot of debian packages, which were removed when minifying the image. E.g. the adduser package is still in the SBOM, even though the binary is no longer available in the container. The reason for this seems to be the presence of the following file: /var/lib/dpkg/status which still contains references to the installation of adduser:

Package: adduser
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 452
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: all
Multi-Arch: foreign
Version: 3.137ubuntu1
Depends: passwd
Suggests: liblocale-gettext-perl, perl, cron, quota, ecryptfs-utils (>= 67-1)
Conffiles:
 /etc/adduser.conf 4869da5f5f508dfbc341342a272c36c8
 /etc/deluser.conf 11a06baf8245fd8d690b99024d228c1f

My question therefore is if there is a reason the file /var/lib/dpkg/status was not removed when minifying the image? Seems like it is throwing a lot of SBOM generators off.

Cheers

[kcq]

Normally /var/lib/dpkg/status would be removed.

The only default case when it wouldn't removed is when the containers are designed to install debian packages at runtime. Some containers have entrypoints that bootstrap the container with extra components (installing additional packages, downloading new data files, etc). By default, Mint/DockerSlim will keep newly created files. If you install a new package in the entrypoint container logic everything in the install package flow will be kept as well. The --include-new flag controls this behavior. If you set it to false then anything that's not already in the container when it starts will not be kept.

Another possible way to explain /var/lib/dpkg/status is the --include-path flag. It's possible ghcr.io/sbb-design-systems/sbb-angular/showcase:14.4.3 was created with the --include-path /var/lib/dpkg/status flag set to intentionally keep the debian package metadata, but this needs to be done intentionally by the user.

[PinkSheep]

Hi @kcq
Thanks a lot for your answer, looks like you are correct and setting --include-new false did indeed help. /var/lib/dpkg/status is no longer present in the minified Image when using the flag.
Cheers

[kyubisation]

Hello @kcq and @PinkSheep
I am the maintainer of ghcr.io/sbb-design-systems/sbb-angular/showcase:14.4.3.
Neither do we install packages at runtime, nor do we specifically keep the status file. Due to this, I'm afraid it is not clear to me why this file is kept.
But I will add the --include-new false flag, which should solve the issue as mentioned.
Thank you everyone for the help!