dpkg packages that are in deinstalled state should not be in SBOM

[mephinet]

What happened:
Many official docker images (provided by https://github.com/docker-library) are derived from buildpack-deps, which includes a large number of build-related packages, like gcc, git, subversion, perl, imagemagick, ... so programs that are useful for building the program (and maybe further dependencies), but won't be used at runtime.

In order to meet security regulations, this poses an issue, as many of these dependencies have vulnerabilities, e.g. at the time of writing CVE-2024-32002, CVE-2016-10144, CVE-2016-10145, CVE-2023-47100, CVE-2023-31486.

In order to get these vulnerabilities off the audit list, I'm apt-get removeing these packages once all RUN steps depending on any of those programs/libraries are done - so perl, git, ... is no longer part of the final container.

However, when scanning such an issue with syft, these packages are still reported as found.

What you expected to happen:
If a package is installed in an earlier layer of the image, and removed in a later layer, I expect the package to no longer be part of the BOM

Steps to reproduce the issue:

• create a Dockerfile with the following content:

  FROM python:3.12
  RUN apt-get remove -y perl git imagemagick gnupg && apt-get -y autoremove
  

• scan this image with syft
• check the created SBOM for perl, git, imagemagick, gnupg

Anything else we need to know?:

Environment:

• Output of syft version:
  Application: syft
  Version: 1.9.0
  BuildDate: 2024-07-11T17:32:46Z
  GitCommit: 4e09908
  GitDescription: v1.9.0
  Platform: linux/amd64
  GoVersion: go1.22.5
  Compiler: gc

• OS (e.g: cat /etc/os-release or similar):
  NAME="Arch Linux"
  PRETTY_NAME="Arch Linux"
  ID=arch
  BUILD_ID=rolling
  ANSI_COLOR="38;2;23;147;209"
  HOME_URL="https://archlinux.org/"
  DOCUMENTATION_URL="https://wiki.archlinux.org/"
  SUPPORT_URL="https://bbs.archlinux.org/"
  BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
  PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
  LOGO=archlinux-logo

[westonsteimel]

So the debian packaging cataloger works by looking at the /var/lib/dpkg/status file (among other location variations) to understand which dpkg files are installed. In this case, because --purge wasn't used in the remove command, config files were kept so the entirety of the dpkg contents are not removed and stay in that file; however, the status changes from
install ok installed to deinstall ok config-files

So changing the command to apt-get remove --purge -y perl git imagemagick gnupg && apt-get -y autoremove should get the behaviour you want.

Whether or not partially installed dpkg packages should be included in the sbom, particularly config-file only installs probably needs a larger discussion

[wagoodman]

I think the short-term answer is to remove these items from the SBOM -- they should not be represented as installed packages.

However, I agree that this opens up a longer-term question on how to deal with "deinstalled" or "config only" cases... I do agree that there should be some representation in the SBOM about this, but we'd need to be careful to not imply they are installed.

One way is to not create a relationship from the source to the package that was deinstalled; from an SPDX perspective there is convention here that this would imply that it is not installed. I'm not a fan of this approach though, since I feel that the common SBOM consumer is probably unaware of this convention and it would appear to be installed. We could do a syft-json only solution for this, but that would leave out supporting SPDX and CyloneDX, which also isn't great.

I'm open to more suggestions here!

[mephinet]

Thanks for shining a light at this issue! I wasn't aware that without adding --purge, the package was still part of debian's status files. Now that I've added --purge to the apt-get remove and apt-get autoremove commands, they are no longer part of the BOM - so my issue is fixed.
Thanks a lot for your quick and helpful replies! 😍

[willmurphyscode]

Hi @mephinet thanks for the issue. We will keep this open to track the request that @wagoodman made above