While investigating a report of false positives in Clair, we came across another phantom issue due to the lack of provenance and reliance on heuristics in Claircore's Red Hat support.

Here's the data reported from Clair:

This appears incorrect because the packages already contain a fix for the flagged vulnerability. (In this case, CVE-2023-44487.) However, because the container name mapping points to two different package names (in these cases, openshift/proj and openshift/proj-rhel9), both are associated with the container. When the cvemap.xml file is parsed, the names are treated independently. This results in two vulnerabilities with version ranges that have an infinitely early lower bound. As an example:

• Container's "name" label: "openshift/foo"
• container-name-repos-map.json entry: ["openshift/foo", "openshift/foo-rhel9"]
• relevant cvemap.xml packages: openshift/foo:v1.0, openshift/foo-rhel9:v1.1

Two vulnerabilities will be produced, one for each cvemap.xml package. However, because the names are different, they will both produce a range with a lower bound of zero, and thus both match. This lower bound behavior is desired: consider a CVE in openshift/foo:v0.9 that has since gone out of support.

This is the same root issue as CLAIRDEV-45, only reproduced in the domain of containers instead of rpms. As long as Red Hat release artifacts don't have enough information to uniquely identify them in the same terms that are used in the security data, this phantom problem will be endemic.