[Pre-Publication Disclosure] Reproducible Findings Regarding Clair in our SBOM Scanner Study

[Helen Yang]

Dear Clair team,

My name is Yunhe Yang, and I am a PhD student working with Prof. Mu Zhang at the University of Utah. My advisor and I are currently working on a research paper titled “On the Accuracy and Security Implications of SBOM-Based Vulnerability Scanners”. Our work studies container vulnerability scanners, focusing on scan-result consistency, false negatives, false positives, and the underlying mechanisms that lead to scanner disagreement.

Our methodology combines large-scale image scanning with controlled case analysis to distinguish issues related to package anchors, namespace applicability, upstream/downstream mappings, version constraints, and scope boundaries. During this research, we observed several reproducible behaviors in Clair that we would like to share before finalizing our paper.

We are contacting you in the spirit of constructive pre-publication communication, and we would greatly appreciate any clarification or feedback your team may be willing to provide.

The main findings we observed for Clair are as follows:

1. Constraint anchor missing

   In some cases, Clair correctly detects the package name and installed version, but the database entry does not appear to provide executable fixed-version information for the relevant namespace.

Example:

In `ibm-semeru-runtimes:open-8u442-b06-jre-focal`, Clair detects the affected package `sqlite3` for `CVE-2025-29088`, but the fixed version is empty or unavailable. This suggests that the Ubuntu Focal namespace entry may lack executable fixed-version information, or may not encode the necessary constraints for the vulnerability to be fully actionable.

2. Upstream vs. downstream mismatch

   We observe cases where a vulnerability is defined and tracked at the upstream component level, while downstream ecosystems encode it under distribution-specific package identities. In such cases, the vulnerability may become unmatchable in Clair's OS-package-driven workflow.

Examples:

* In `influxdb:1.11.8`, `CVE-2024-45336` appears to be an upstream Go standard library vulnerability, while downstream Debian-style tracking associates it with Go toolchain source packages such as `golang-1.24`. Clair omits the vulnerability from scan output.

* In `zookeeper:3.9.3-jre-17` on Ubuntu 22.04, Clair's database contains Ubuntu 22.04 entries for `CVE-2024-34156` under Go toolchain dpkg packages (`golang-1.x`) with fixed versions. However, the image is a Java runtime image and does not contain those Go dpkg packages. As a result, the vulnerability becomes unmatchable because the relevant installed package instance is absent.

3. Kernel CVE scope and attribution boundary

   We also observed that kernel vulnerabilities are treated as host-scoped during image scanning. Across our dataset, multiple kernel CVEs, including `CVE-2025-21760`, `CVE-2025-37851`, `CVE-2025-22002`, and `CVE-2024-53064`, appear in vulnerability databases but are not reported in scan outputs. We would appreciate confirmation on whether this behavior reflects an intentional scope of decision.

If helpful, we would be happy to provide concise reproduction details for the cases above.

Thank you very much for your time and for your work on Clair.

Best regards,

Yunhe Yang  

University of Utah  

yunhe...@utah.edu

[Hank Donnay]

Hello,

On Tue, Apr 21, 2026 at 08:25:59PM +0000, 'Helen Yang' via clair-dev wrote:
>[...]

>
>1. Constraint anchor missing
> In some cases, Clair correctly detects the
> package name and installed version, but the database entry does not
> appear to provide executable fixed-version information for the relevant
> namespace.

Yeah, this happens. There's nothing we can do if the vendor data doesn't
have "fixed in" information (or at least it's not structured in an
expected way).

>[...]

>
>2. Upstream vs. downstream mismatch
> We observe cases where a vulnerability is defined and tracked at the
> upstream component level, while downstream ecosystems encode it
> under distribution-specific package identities. In such cases, the
> vulnerability may become unmatchable in Clair's OS-package-driven
> workflow.

Yes, Clair assumes that packages shipped by a vendor or project have
corresponding security information from that vendor. In the cases where
dependencies are statically linked or bundled into an OS-level package
instead of expressed via OS-level packages, there's nothing to do but
trust the information provided by the vendor.

>[...]

>
>3. Kernel CVE scope and attribution boundary
> We also observed that kernel vulnerabilities are treated as
> host-scoped during image scanning. Across our dataset, multiple
> kernel CVEs, including `CVE-2025-21760`, `CVE-2025-37851`,
> `CVE-2025-22002`, and `CVE-2024-53064`, appear in vulnerability
> databases but are not reported in scan outputs. We would appreciate
> confirmation on whether this behavior reflects an intentional scope
> of decision.

Containers have no say in the kernel they're run on, so it's not useful
to report on software that cannot be changed in the container. There's
possibly some attack surface via the kernel headers themselves, but
that's never actually happened as far as we can tell.

If you think any of the behaviors you've observed are incorrect, please
open an issue on GitHub.

--
hank