Open mephinet opened 1 month ago
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
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!
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! :heart_eyes:
Hi @mephinet thanks for the issue. We will keep this open to track the request that @wagoodman made above
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 remove
ing 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:
Anything else we need to know?:
Environment:
Output of
syft version
: Application: syft Version: 1.9.0 BuildDate: 2024-07-11T17:32:46Z GitCommit: 4e09908ba124dca7e6f1f6e7dc4f4663fae658ca GitDescription: v1.9.0 Platform: linux/amd64 GoVersion: go1.22.5 Compiler: gcOS (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