dependency-track
dependency-track copied to clipboard
cpe:2.3:a:perl:perl is incorrectly mapped to debian package perl instead of perl-base
Current Behavior
In Debian, the perl executable is contained in the package perl-base, and not perl - cf https://packages.debian.org/bookworm/amd64/perl-base/filelist
Since most of the time, either both or neither package is installed, the difference is marginal.
However, in order to minimize the target surface, we added apt-get -y remove --purge perl to our Dockerfile, thinking that this would remove the perl binary. Two things we learned by doing that:
- the perl executable was still there
- but DependencyTrack no longer reported the perl vulnerabilities
So my understanding is that cpe:2.3:a:perl:perl is incorrectly mapped to debian package perl instead of perl-base.
Steps to Reproduce
- create a Dockerfile:
FROM python:3.12
RUN apt-get update && \
apt-get -y remove --purge perl && \
apt-get -y autoremove --purge && \
rm -rf /var/lib/apt/lists/*
- create a BOM file for this image, e.g. with syft:
syft your-image -o cyclonedx-json > sbom.json
- upload the sbom to DependencyTrack
- check the vulnerabilities
Expected Behavior
Vulnerabilities like CVE-2023-47100 are reported, because the perl executable is installed in this image.
Dependency-Track Version
4.10.0
Dependency-Track Distribution
Container Image
Database Server
N/A
Database Server Version
No response
Browser
Google Chrome
Checklist
- [X] I have read and understand the contributing guidelines
- [X] I have checked the existing issues for whether this defect was already reported
Can you share the exact component entry of the offending component from the BOM you're testing with?
Sure, I've uploaded the SBOM of the mentioned Dockerfile to this gist: https://gist.github.com/mephinet/8488ac1812b763b8d55ff0e52137b919
The entry of perl-base (with the licenses block removed for clarity):
{
"bom-ref": "pkg:deb/debian/[email protected]%2Bdeb12u1?arch=amd64&upstream=perl&distro=debian-12&package-id=e7c6c7e67b78f445",
"type": "library",
"publisher": "Niko Tyni <[email protected]>",
"name": "perl-base",
"version": "5.36.0-7+deb12u1",
"cpe": "cpe:2.3:a:perl-base:perl-base:5.36.0-7\\+deb12u1:*:*:*:*:*:*:*",
"purl": "pkg:deb/debian/[email protected]%2Bdeb12u1?arch=amd64&upstream=perl&distro=debian-12",
"properties": [
{
"name": "syft:package:foundBy",
"value": "dpkg-db-cataloger"
},
{
"name": "syft:package:type",
"value": "deb"
},
{
"name": "syft:package:metadataType",
"value": "dpkg-db-entry"
},
{
"name": "syft:cpe23",
"value": "cpe:2.3:a:perl-base:perl_base:5.36.0-7\\+deb12u1:*:*:*:*:*:*:*"
},
{
"name": "syft:cpe23",
"value": "cpe:2.3:a:perl_base:perl-base:5.36.0-7\\+deb12u1:*:*:*:*:*:*:*"
},
{
"name": "syft:cpe23",
"value": "cpe:2.3:a:perl_base:perl_base:5.36.0-7\\+deb12u1:*:*:*:*:*:*:*"
},
{
"name": "syft:cpe23",
"value": "cpe:2.3:a:perl:perl-base:5.36.0-7\\+deb12u1:*:*:*:*:*:*:*"
},
{
"name": "syft:cpe23",
"value": "cpe:2.3:a:perl:perl_base:5.36.0-7\\+deb12u1:*:*:*:*:*:*:*"
},
{
"name": "syft:location:0:layerID",
"value": "sha256:15bb10f9bb3af155537c0f594b736881ca625d0e9bcd6f948588f78aec30a710"
},
{
"name": "syft:location:0:path",
"value": "/usr/share/doc/perl-base/copyright"
},
{
"name": "syft:location:1:layerID",
"value": "sha256:15bb10f9bb3af155537c0f594b736881ca625d0e9bcd6f948588f78aec30a710"
},
{
"name": "syft:location:1:path",
"value": "/var/lib/dpkg/info/perl-base.md5sums"
},
{
"name": "syft:location:2:layerID",
"value": "sha256:ba3cf852801e40535756e0c1aa830cc439dea8e440bd7f70bf9cd6a7b924e19e"
},
{
"name": "syft:location:2:path",
"value": "/var/lib/dpkg/status"
},
{
"name": "syft:metadata:installedSize",
"value": "7638"
},
{
"name": "syft:metadata:source",
"value": "perl"
}
]
}
The component's CPE says:
cpe:2.3:a:perl-base:perl-base:5.36.0-7\\+deb12u1:*:*:*:*:*:*:*
but the CVE only lists:
cpe:2.3:a:perl:perl:*:*:*:*:*:*:*:*
So those can never match.
You could try enabling OSV for the Debian ecosystem. That way, we might be able to leverage the component's PURL instead, and you'd be getting vulnerability data specifically for Debian. Whereas the official CVE only refers to the generic perl package.
Hi @nscuro, I requested enabling the Debian ecosystem for OSV. Might take a while (I'm on a shared instance and not an admin) - I'll keep you posted once I have new results. However, checking for instance https://osv.dev/vulnerability/CVE-2022-48522, I see that the purl pkg:deb/debian/perl?arch=source is specified there, which seems wrong to me...
Hello @mephinet, the problem you end up with is the fact that Linux distros map their issues to the source packages, thereby producing a few or some false positives (that is, not all binary packages created from a source package may be affected). The source package of "perl-base" is "perl". On the other side of the potential match, Syft specifies the pURL as pkg:deb/debian/[email protected]%2Bdeb12u1?arch=amd64&upstream=perl&distro=debian-12. In this pURL, the "upstream=perl" query parameter is nothing else than the source package name. We had cured this problem on our side by inserting "virtual upstream packages" with the name of the source package in such cases; I hope it will be fixed in DT one day. Unfortunately, with curing the "diverging source package names" false negative problem, you will very likely run into a false positive problem - that is, DT does not yet honour the release track of the Linux distro (in this case, debian-12), ignoring its specification both in the OSV data and in the component pURL. You will not experience this problem in case you are on the highest track OSV lists, though - only if you use e.g. "stable" or "oldstable" release tracks.