dpkg has a mechanism called Multi-Arch that allows packages with the same name to coexist for different architectures. From the perspective of collecting and managing package information, even if the package name is the same, it is necessary to manage them separately by architecture. However, the current scan result removes the architecture portion and manages packages in a map keyed only by package name. If we keep the map structure while supporting Multi-Arch, the architecture must be included in the key, but that would affect operations such as detection.
$ dpkg-query -W -f="\${binary:Package},\${db:Status-Abbrev},\${Version},\${source:Package},\${source:Version}\n" | grep "libc6:"
libc6:amd64,ii ,2.35-0ubuntu3.13,glibc,2.35-0ubuntu3.13
libc6:i386,ii ,2.35-0ubuntu3.13,glibc,2.35-0ubuntu3.13
$ vuls scan
$ jq -r '.packages.libc6' results/2026-02-20T11-30-22+0900/localhost.json
{
"name": "libc6",
"version": "2.35-0ubuntu3.13",
"release": "",
"newVersion": "",
"newRelease": "",
"arch": "",
"repository": "",
"modularitylabel": ""
}rpm also has a mechanism called installonlypkgs that allows multiple versions of the same package to coexist. This is commonly used for kernel packages. Currently, this problem with map keys is avoided by collecting only the running kernel.
$ uname -a
Linux vagrant 6.1.79-99.164.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Feb 27 18:02:23 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -qa --queryformat "%{NAME} %{EPOCHNUM} %{VERSION} %{RELEASE} %{ARCH} %{SOURCERPM} %{MODULARITYLABEL}\n" | grep "kernel"
kernel 0 6.1.79 99.164.amzn2023 x86_64 kernel-6.1.79-99.164.amzn2023.src.rpm (none)
kernel-modules-extra 0 6.1.79 99.164.amzn2023 x86_64 kernel-6.1.79-99.164.amzn2023.src.rpm (none)
kernel-libbpf 1 6.1.158 180.294.amzn2023 x86_64 kernel-6.1.158-180.294.amzn2023.src.rpm (none)
kernel-livepatch-repo-cdn 0 2023.9.20251208 2.amzn2023 noarch system-release-2023.9.20251208-2.amzn2023.src.rpm (none)
kernel-srpm-macros 0 1.0 14.amzn2023.0.3 noarch kernel-srpm-macros-1.0-14.amzn2023.0.3.src.rpm (none)
kernel-modules-extra-common 1 6.1.158 180.294.amzn2023 x86_64 kernel-6.1.158-180.294.amzn2023.src.rpm (none)
kernel-modules-extra 1 6.1.158 180.294.amzn2023 x86_64 kernel-6.1.158-180.294.amzn2023.src.rpm (none)
kernel 1 6.1.158 180.294.amzn2023 x86_64 kernel-6.1.158-180.294.amzn2023.src.rpm (none)
kernel-tools 1 6.1.158 180.294.amzn2023 x86_64 kernel-6.1.158-180.294.amzn2023.src.rpm (none)
$ vuls scan
$ jq -r '.packages.kernel' results/2026-02-20T11-30-22+0900/localhost.json
{
"name": "kernel",
"version": "6.1.79",
"release": "99.164.amzn2023",
"newVersion": "6.1.79",
"newRelease": "99.164.amzn2023",
"arch": "x86_64",
"repository": "",
"modularitylabel": "",
"AffectedProcs": [
{
"pid": "25159",
"name": "systemd-udevd"
}
]
}For both dpkg and rpm, solving this problem requires changing the package management structure in the scan results. Specifically, the map key must include not only the package name but also architecture and/or version. Alternatively, it may be preferable to abandon the map structure and switch to a list structure instead.
dpkg has a mechanism called Multi-Arch that allows packages with the same name to coexist for different architectures. From the perspective of collecting and managing package information, even if the package name is the same, it is necessary to manage them separately by architecture. However, the current scan result removes the architecture portion and manages packages in a map keyed only by package name. If we keep the map structure while supporting Multi-Arch, the architecture must be included in the key, but that would affect operations such as detection.
rpm also has a mechanism called installonlypkgs that allows multiple versions of the same package to coexist. This is commonly used for kernel packages. Currently, this problem with map keys is avoided by collecting only the running kernel.
For both dpkg and rpm, solving this problem requires changing the package management structure in the scan results. Specifically, the map key must include not only the package name but also architecture and/or version. Alternatively, it may be preferable to abandon the map structure and switch to a list structure instead.