Inconsistent Clair scan results

[nikolaasdb]

Hi all,

I'm running Clair v4.3.6 in an OpenShift cluster. It is integrated together with Jenkins so that during build, Clair will scan the image.
We've noticed that everytime we build an image for the very first time, Clair will do its job. But the first scan result returns for example:

Clair scan result for <registry>/maven-build-image-jdk1.8:DEV-SNAPSHOT

Package                                  Installed version         Fix version          Severity    Name                
------------------------------------------------------------------------------------------------------------------------
urllib3                                  <1.25.9                                        Unknown     pyup.io-38834 (CVE-2020-26137)
urllib3                                  <1.26.5                                        Unknown     pyup.io-43975 (CVE-2021-33503)
urllib3                                  <1.25.9                                        Unknown     pyup.io-38834 (CVE-2020-26137)
------------------------------------------------------------------------------------------------------------------------

This image gets pushed on our registry and in a next step we pull that image to continue to our deployment step.
Here, it is the same image (just a different name tag) and the results are the following:

Clair scan result for <registry>/maven-build-image-jdk1.8:1.3.0


Package                                  Installed version         Fix version          Severity    Name                
------------------------------------------------------------------------------------------------------------------------
org.springframework.security.oauth:spring-security-oauth2 2.3.4.RELEASE             2.0.17.RELEASE, 2.1.4.RELEASE, 2.2.4.RELEASE, 2.3.5.RELEASE Critical    SNYK-JAVA-ORGSPRINGFRAMEWORKSECURITYOAUTH-173755
org.springframework:spring-beans         5.3.9                     5.2.20, 5.3.18       Critical    SNYK-JAVA-ORGSPRINGFRAMEWORK-2436751
org.springframework.cloud:spring-cloud-gateway-server 3.0.6                     3.0.7, 3.1.1         Critical    SNYK-JAVA-ORGSPRINGFRAMEWORKCLOUD-2415033
org.apache.hadoop:hadoop-common          3.2.0                     3.2.3                Critical    SNYK-JAVA-ORGAPACHEHADOOP-2443177
commons-collections:commons-collections  3.2.1                     3.2.2                Critical    SNYK-JAVA-COMMONSCOLLECTIONS-30078
org.apache.maven.shared:maven-shared-utils 3.0.0                     3.3.3                Critical    SNYK-JAVA-ORGAPACHEMAVENSHARED-570592

...
etc etc

I was wondering if there is a certain way, via an API call or something that it will first check if the index is complete before it returns a result?

Kind regards
Nikolaas De Burggrave

[crozzy]

Hi Nikolaas, thanks for the issue,

In v4.3.6 the CRDA remote matcher is enabled by default, this means that during every matching request there is a (couple of) API requests that can return these SNYK results. Unfortunately these API calls are rate-limited at a global level, hence why we disable the matcher by default in subsequent versions. There are 3 options:

• Upgrade the Clair version
• Manually disable the crda-matcher
• Request a dedicated CRDA API key here: https://github.com/quay/clair/blob/main/Documentation/concepts/matching.md#remote-matching

Let me know if you need help with one of these things, we are working on an OSV updater that should be able to replace a large part of the CRDA matching functionality, but it is currently in development.

[crozzy]

We're also working on https://github.com/quay/clair-action which will allow Clair to be run in CI workflows without the need for a cluster. It is currently not production ready but feel free to try it out and report feedback.

[nikolaasdb]

Thanks for the replies Crozzy.
Do you by any chance know when the quay version on quay.io/projectquay/clair would get updated to include the latest version?

[nikolaasdb]

Another thing we've noticed, but perhaps I should create a different discussion for this, is that on this same image scan, it returns
org.springframework:spring-beans 5.3.9 5.2.20, 5.3.18 Critical SNYK-JAVA-ORGSPRINGFRAMEWORK-2436751
When looking into the container, we can't find any use of spring-beans 5.3.9. In fact, the only spring-beans we found was version 5.3.18. And that version is supposedly the fix of SNYK-JAVA-ORGSPRINGFRAMEWORK-2436751 which would be in version 5.3.9. I'm not entirely sure what's up with that, but it's kind of hard to solve some critical error that shouldn't be there.

[hdonnay]

Could you upload the json format from clairctl report? Sharing the layer would also be helpful in cross-checking the reporting.