arminc / clair-local-scan Goto Github PK

Hi @arminc,

Thanks for your useful work. I know it is not the correct repo, but I had no other way to contact you.

Do you think adding a tag latest on the clair-db would be possible ?

Thanks,

i am able to get the docker psotgres db runing
i.e.

docker run -d --name db arminc/clair-db:2017-03-15

but when i try

docker run -p 6060:6060 --link db:postgres -d --name clair arminc/clair-local-scan:v2.0.6

the container is created but the execution fails with the followig error.
{"Event":"pgsql: could not open database: dial tcp 172.17.0.2:5432: getsockopt: no route to host","Level":"fatal","Location":"main.go:96","Time":"2018-10-26 03:42:02.534312"}

i also tried stoping the firewall but that didn't help.

Currently an empty DB is used every time, using the previous day's DB should speedup the build time because it is only an update. Try it out and fix if so.

Hello,

It looks like the log has some warnings/errors because of the old clair version:

"Debian bullseye is not mapped to any version number (eg. Jessie-\u003e8). Please update me"
{"Event":"could not get NVD data feed hash","Level":"warning","Location":"nvd.go:137","Time":"2019-12-02 12:34:36.577362","data feed name":"2019","error":"invalid .meta file format"}

Both problems were fixed in the latest releases:
https://github.com/quay/clair/releases

Can you please do a release for clair 2.1.0 ?

Thanks

Can you make sure that your vulnerability report can be provided as a json file?

similarly to #3 , would it be possible to get a latest tag on the clair-local-scan image?

I followed your steps, which are:

docker run -d --name db arminc/clair-db:2017-03-15
docker run -p 6060:6060 --link db:postgres -d --name clair arminc/clair-local-scan:v2.0.3
clair-scanner nginx:1.11.6-alpine example-nginx.yaml http://MY_LOCAL_IP:6060 MY_LOCAL_IP

but I get the following error:

clair-scanner: command not found

Am I missing anything?

Thanks

Hi,

Looks like the clair db image is not updated anymore.
Last update is shown 2 months ago.

Is there a reason you are not updating?

https://hub.docker.com/r/arminc/clair-db/tags?page=1&ordering=last_updated

The container is run using docker run -p 6060:6060 --network clair-net --rm --name clair arminc/clair-local-scan:v2.0.6 but I don't see an executable anywhere.

While v2.0.6 can be seen in https://hub.docker.com/r/arminc/clair-local-scan/tags, v2.0.6 tag on Git does not appear.

Can you tag some ref (maybe b263b69) as v2.0.6?

Simple update to fix.... In the .travis.yml, set the db image to postgres:11.6-alpine. That one scans cleanly.

While filing #18 I noticed that travis seems to default to logging in and attempting to push. Perhaps we can do this on the master branch only? Also, I'm thinking we should build the image at travis instead of attempting to pull it?

arminc/clair-db has a root requirement, which is not recomennded for prod env (and such containers simply can't be run in Openshift). Why not switch over to safer bitnami/postgresql? And why not open-source the db Dockerfile as well (I could not find it)?

To replicate:
docker run --rm -it --name clair-db --cap-drop=all arminc/clair-db:latest
chown: /var/lib/postgresql/clair: Permission denied

similar problem in the official postgres:
docker run --cap-drop=all postgres
chmod: changing permissions of '/var/lib/postgresql/data': Operation not permitted

Without dropping all capabilities (using --cap-drop=all) and thus allowing root actions, both of the containers start to work.

In contrast bitnami's Postgres does not require root:
docker run --cap-drop=all -e POSTGRESQL_PASSWORD=pass123 bitnami/postgresql
[..] LOG: database system is ready to accept connections

There was no activity on this repo for 60 days, and so the CI has stopped. Can this be restarted? Thanks :)

Hi @arminc,

I am curious to understand why CVEs are changing from 1 day to another.

For instance, I ran some tests on image nginx:1.12 specifically, and I can see the following differences since yesterday:

From 2018-01-10 tag:

vulnerability:cve=CVE-2005-2541
vulnerability:cve=CVE-2007-5686
vulnerability:cve=CVE-2009-4487
vulnerability:cve=CVE-2011-3374
vulnerability:cve=CVE-2011-4116
vulnerability:cve=CVE-2013-0340
vulnerability:cve=CVE-2015-9019
vulnerability:cve=CVE-2016-2779
vulnerability:cve=CVE-2016-2781
vulnerability:cve=CVE-2016-9085
vulnerability:cve=CVE-2017-1000409
vulnerability:cve=CVE-2017-13726
vulnerability:cve=CVE-2017-15232
vulnerability:cve=CVE-2017-15422
vulnerability:cve=CVE-2017-15908
vulnerability:cve=CVE-2017-16879
vulnerability:cve=CVE-2017-17512
vulnerability:cve=CVE-2017-3738
vulnerability:cve=CVE-2017-7246
vulnerability:cve=CVE-2017-8872
vulnerability:cve=CVE-2017-9937
vulnerability:level=high

From 2018-01-11 (currently latest) tag:

vulnerability:cve=CVE-2005-2541
vulnerability:cve=CVE-2007-5686
vulnerability:cve=CVE-2010-0928
vulnerability:cve=CVE-2011-3374
vulnerability:cve=CVE-2012-3878
vulnerability:cve=CVE-2013-0337
vulnerability:cve=CVE-2013-0340
vulnerability:cve=CVE-2013-4392
vulnerability:cve=CVE-2015-9019
vulnerability:cve=CVE-2016-2779
vulnerability:cve=CVE-2016-9085
vulnerability:cve=CVE-2016-9318
vulnerability:cve=CVE-2017-15232
vulnerability:cve=CVE-2017-16879
vulnerability:cve=CVE-2017-17484
vulnerability:cve=CVE-2017-17512
vulnerability:cve=CVE-2017-17973
vulnerability:cve=CVE-2017-18018
vulnerability:cve=CVE-2017-7246
vulnerability:cve=CVE-2017-8804
vulnerability:cve=CVE-2017-9937
vulnerability:level=high

The following CVE disappeared:

vulnerability:cve=CVE-2009-4487
vulnerability:cve=CVE-2011-4116
vulnerability:cve=CVE-2017-1000409
vulnerability:cve=CVE-2017-15908
vulnerability:cve=CVE-2017-3738
vulnerability:cve=CVE-2017-8872

The following CVE appeared:

vulnerability:cve=CVE-2010-0928
vulnerability:cve=CVE-2012-3878
vulnerability:cve=CVE-2016-9318
vulnerability:cve=CVE-2013-0337
vulnerability:cve=CVE-2017-17484
vulnerability:cve=CVE-2017-17973
vulnerability:cve=CVE-2017-18018
vulnerability:cve=CVE-2017-8804

Does someone else noticed these changes ? Are you running some kind of curation while creating daily clair-db image or Is it coming from clair-server directly ?

Thanks,

Chris

I am trying to scan docker images within a Jenkins Pipeline.

It starts to scan the containers - but during the scan I get the following error:

> 2018/05/10 19:03:37 [INFO] â–¶ Start clair-scanner
> 2018/05/10 19:03:45 [INFO] â–¶ Server listening on port 9279
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing 45d88eda03f89f18139930e9d3cbf869bf84f1fd776ed0a059788e2022339ef9
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing 646268fce3365f94e1e0598ab42b24c1c66ae961486f21db3d1a875a208e4561
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing d675e7b72207aba07b6ca08d5515108ae0110add18f7154f8eb5f39462d6f8f7
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing 10166da365caa812d5b86cf22660102945b7dd9160ada1f0c35720cc83cb8b0b
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing 7c786034d2aaf5a9c0a53f76245b12cdb6ac1dd0db496f9a16bc0e9bc0c47eb1
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing dc3a502d001b613ee58bf016e426fbcebc949603038d55ae67f16bcc34da93f4
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing 4741280194f1c829546eb866dcf93fb209028c6ea13004c419bed2ea6f877685
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing a4b2413ffe86b60f7bd58dcb541d0e724888aa50217d36205aaa6668f7d1cec2
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing 07c72f7d9c7f3758bf05793b46b86cf49a916eefde9d41862e910997804531bc
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing 2c9d10e4452339983909d51c69f6f2f87f87861b8f5bf61d219ea46faa9c1c0c
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing fc7175b0ec6feced5b08acd82022319bb5b4f64faa941cbeb7a4b7d71dd76cf2
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing 1100c2c3857fbd328ee4de17e8e7643bee63199275dd4cee891bfc38f85bd882
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing f49d1014c081c85b3f640c932e3d28ba85bd7903510b154ef641a5a237be0442
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing 1ddea952412225a1bfaf72daae8cacbfac9a85c2bce4690d10da8cc6dddc4eb6
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing b9aba1ab7aaedd493316f0fd0bb015a807ed0f1c1467a604e5c7976b3209e141
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing ef9a326f6b6e9e85a9cd47c0cb4cb4421c70c5345251efc09e7086a3543e0d6d
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing 0d00b1796e75233dafa0231bddcb42e7ae8d1b9942fcf15f2f1e5b70682191b6
> 2018/05/10 19:03:45 [INFO] â–¶ Analyzing b8fdf2f68d3b37e2e21e47d8a0b6a4711996b368d454d20eabf6c740d44c4bef
> 2018/05/10 19:03:45 [CRIT] â–¶ Could not analyze layer: Clair responded with a failure: Got response 500 with message {"Error":{"Message":"database: an error occured when querying the backend"}}

The logs from the clair-local-scan process are below:

{"Event":"running database migrations","Level":"info","Location":"pgsql.go:216","Time":"2018-05-10 09:13:55.300877"}
{"Event":"database migration ran successfully","Level":"info","Location":"pgsql.go:223","Time":"2018-05-10 09:13:55.311560"}
{"Event":"starting main API","Level":"info","Location":"api.go:52","Time":"2018-05-10 09:13:55.311758","port":6060}
{"Event":"starting health API","Level":"info","Location":"api.go:85","Time":"2018-05-10 09:13:55.311945","port":6061}
{"Event":"notifier service is disabled","Level":"info","Location":"notifier.go:77","Time":"2018-05-10 09:13:55.312095"}
{"Event":"updater service started","Level":"info","Location":"updater.go:81","Time":"2018-05-10 09:13:55.312090","lock identifier":"4ad113ae-6bce-4626-8c0f-87fb615c92fb"}
{"Event":"updating vulnerabilities","Level":"info","Location":"updater.go:182","Time":"2018-05-10 09:13:55.316496"}
{"Event":"fetching vulnerability updates","Level":"info","Location":"updater.go:228","Time":"2018-05-10 09:13:55.316580"}
{"Event":"Start fetching vulnerabilities","Level":"info","Location":"oracle.go:119","Time":"2018-05-10 09:13:55.316685","package":"Oracle Linux"}
{"Event":"Start fetching vulnerabilities","Level":"info","Location":"alpine.go:52","Time":"2018-05-10 09:13:55.316716","package":"Alpine"}
{"Event":"Start fetching vulnerabilities","Level":"info","Location":"debian.go:63","Time":"2018-05-10 09:13:55.316788","package":"Debian"}
{"Event":"Start fetching vulnerabilities","Level":"info","Location":"rhel.go:92","Time":"2018-05-10 09:13:55.316779","package":"RHEL"}
{"Event":"Start fetching vulnerabilities","Level":"info","Location":"ubuntu.go:88","Time":"2018-05-10 09:13:55.316709","package":"Ubuntu"}
{"Event":"finished fetching","Level":"info","Location":"updater.go:242","Time":"2018-05-10 09:13:56.405694","updater name":"alpine"}
{"Event":"finished fetching","Level":"info","Location":"updater.go:242","Time":"2018-05-10 09:13:57.730565","updater name":"rhel"}
{"Event":"finished fetching","Level":"info","Location":"updater.go:242","Time":"2018-05-10 09:13:59.169152","updater name":"debian"}
{"Event":"Handled HTTP request","Level":"info","Location":"router.go:57","Time":"2018-05-10 09:14:26.937475","elapsed time":3591444,"method":"POST","remote addr":"127.0.0.1:50818","request uri":"/v1/layers","status":"201"}
{"Event":"Handled HTTP request","Level":"info","Location":"router.go:57","Time":"2018-05-10 09:14:26.958169","elapsed time":19395274,"method":"POST","remote addr":"127.0.0.1:50820","request uri":"/v1/layers","status":"201"}
{"Description":"insertLayer","Event":"Handled Database Error","Level":"error","Location":"pgsql.go:284","Time":"2018-05-10 09:14:26.970918","error":"pq: insert or update on table \"layer\" violates foreign key constraint \"layer_parent_id_fkey\""}
{"Event":"Handled HTTP request","Level":"info","Location":"router.go:57","Time":"2018-05-10 09:14:26.971115","elapsed time":12498044,"method":"POST","remote addr":"127.0.0.1:50824","request uri":"/v1/layers","status":"500"}
> end log of container 'clair-local-scan' in pod 'jenkins-slave-8nhlw-rpl7s'

We have also looked at the clair-db to see what the DB is doing and we get the following error.

2018-05-10 12:40:14.627 UTC [10243] ERROR:  insert or update on table "layer" violates foreign key constraint "layer_parent_id_fkey"
2018-05-10 12:40:14.627 UTC [10243] DETAIL:  Key (parent_id)=(6) is not present in table "layer".
2018-05-10 12:40:14.627 UTC [10243] STATEMENT:  
                                             INSERT INTO Layer(name, engineversion, parent_id, namespace_id, created_at)
                   VALUES($1, $2, $3, $4, CURRENT_TIMESTAMP)
                   RETURNING id

Any ideas what the issue could be?

when did coreos decide to start launching this application instead of their own version of claire?

The vulnerability data in clair_db images seems to be inconsistent/incomplete from time to time. In my case the metadata field for vulnerabilities appears to be null which turns all the criticality of all findings to Unknown.
I got a test case running a clair scan against WebGoat 8 which reliably produces for example a critical finding for CVE-2018-15686.

Here are hashes to known-good and bad versions of the clair_db image, an SQL query to sample and the results I get. Please have a look at the metadata column.

sample.sql.txt
[data-181c006f6ae7046929894c9050dbe6e1c2a403c04a5f3d346bd2a97087dbdad6-ok.csv.txt]

Good version: arminc/clair-db@sha256:181c006f6ae7046929894c9050dbe6e1c2a403c04a5f3d346bd2a97087dbdad6
(https://github.com/arminc/clair-local-scan/files/5260259/data-181c006f6ae7046929894c9050dbe6e1c2a403c04a5f3d346bd2a97087dbdad6-ok.csv.txt)

Broken version: arminc/clair-db@sha256:e64790326aaaa1b8b8329561b7fc0ec92e748bae228aa1b94f1f6a9d3b1aea89
data-e64790326aaaa1b8b8329561b7fc0ec92e748bae228aa1b94f1f6a9d3b1aea89-NOK.csv.txt

It would be great if you could check the corresponding logs of the scheduled pipeline for clair_db and shed some light on the cause of this issue.

Thanks in advance.

I have attached the logs of clair image running in docker:

{"Event":"running database migrations","Level":"info","Location":"pgsql.go:216","Time":"2024-04-03 23:35:19.489271"}

{"Event":"database migration ran successfully","Level":"info","Location":"pgsql.go:223","Time":"2024-04-03 23:35:19.590563"}

{"Event":"starting health API","Level":"info","Location":"api.go:85","Time":"2024-04-03 23:35:19.590767","port":6061}

{"Event":"starting main API","Level":"info","Location":"api.go:52","Time":"2024-04-03 23:35:19.590746","port":6060}

{"Event":"updater service started","Level":"info","Location":"updater.go:83","Time":"2024-04-03 23:35:19.590862","lock identifier":"8bcb6ef0-23d2-41de-a552-56995e957a12"}

{"Event":"notifier service is disabled","Level":"info","Location":"notifier.go:77","Time":"2024-04-03 23:35:19.590913"}

{"Event":"updating vulnerabilities","Level":"info","Location":"updater.go:192","Time":"2024-04-03 23:35:19.593161"}

{"Event":"fetching vulnerability updates","Level":"info","Location":"updater.go:239","Time":"2024-04-03 23:35:19.593236"}

{"Event":"Start fetching vulnerabilities","Level":"info","Location":"alpine.go:176","Time":"2024-04-03 23:35:19.593382","package":"Alpine"}

{"Event":"Start fetching vulnerabilities","Level":"info","Location":"oracle.go:119","Time":"2024-04-03 23:35:19.593319","package":"Oracle Linux"}

{"Event":"Start fetching vulnerabilities","Level":"info","Location":"debian.go:63","Time":"2024-04-03 23:35:19.593506","package":"Debian"}

{"Event":"Start fetching vulnerabilities","Level":"info","Location":"amzn.go:84","Time":"2024-04-03 23:35:19.593534","package":"Amazon Linux 2"}

{"Event":"Start fetching vulnerabilities","Level":"info","Location":"ubuntu.go:85","Time":"2024-04-03 23:35:19.593769","package":"Ubuntu"}

{"Event":"Start fetching vulnerabilities","Level":"info","Location":"rhel.go:94","Time":"2024-04-03 23:35:19.593768","package":"RHEL"}

{"Event":"Start fetching vulnerabilities","Level":"info","Location":"amzn.go:84","Time":"2024-04-03 23:35:19.593804","package":"Amazon Linux 2018.03"}

{"Event":"Debian bookworm is not mapped to any version number (eg. Jessie-\u003e8). Please update me.","Level":"warning","Location":"debian.go:134","Time":"2024-04-03 23:35:20.576537"}

{"Event":"Debian trixie is not mapped to any version number (eg. Jessie-\u003e8). Please update me.","Level":"warning","Location":"debian.go:134","Time":"2024-04-03 23:35:20.576691"}

{"Event":"finished fetching","Level":"info","Location":"updater.go:253","Time":"2024-04-03 23:35:20.576749","updater name":"debian"}

{"Event":"finished fetching","Level":"info","Location":"updater.go:253","Time":"2024-04-03 23:35:21.156694","updater name":"amzn2"}

{"Event":"finished fetching","Level":"info","Location":"updater.go:253","Time":"2024-04-03 23:35:21.784942","updater name":"rhel"}

{"Event":"finished fetching","Level":"info","Location":"updater.go:253","Time":"2024-04-03 23:35:29.109399","updater name":"alpine"}

{"Event":"finished fetching","Level":"info","Location":"updater.go:253","Time":"2024-04-03 23:35:31.975778","updater name":"amzn1"}

{"Event":"finished fetching","Level":"info","Location":"updater.go:253","Time":"2024-04-03 23:37:16.337711","updater name":"ubuntu"}

{"Event":"could not download layer: expected 2XX","Level":"warning","Location":"driver.go:136","Time":"2024-04-03 23:39:13.735951","status code":404}

{"Event":"failed to extract data from path","Level":"error","Location":"worker.go:122","Time":"2024-04-03 23:39:13.735992","error":"could not find layer","layer":"blobs/sha256/011b303988d241a4ae28a6b82b0d8262751ef02910f0ae2265cb637504b72e36","path":"http://172.17.0.1:9279/blobs/sha256/011b303988d241a4ae28a6b82b0d8262751ef02910f0ae2265cb637504b72e36/layer.tar"}

{"Event":"Handled HTTP request","Level":"info","Location":"router.go:57","Time":"2024-04-03 23:39:13.736134","elapsed time":2042046,"method":"POST","remote addr":"172.17.0.1:52040","request uri":"/v1/layers","status":"400"}

Could you tell me how to resolve :
{"Event":"could not download layer: expected 2XX","Level":"warning","Location":"driver.go:136","Time":"2024-04-03 23:39:13.735951","status code":404}

Looks like alpine-secdb was moved to https://git.alpinelinux.org/cgit/alpine-secdb and the redirect doesn't work.

When I use the Clair-scanner, cvss v2 score is used to detect for critical vulnerabilities. I want to use version 3

Hi,

Since today (using it since 1 year or more), I've noticed that the clar-scanner (clair-scanner_linux_amd64) is not working anymore, getting the following error:

 $ docker run -d --name clair-db arminc/clair-db:latest
 $ docker run -p 6060:6060 --link clair-db:postgres -d --name clair arminc/clair-local-scan:latest
 $ ./clair-scanner_linux_amd64 --ip 172.17.0.1 registry.access.redhat.com/ubi8/ubi
...
Could not analyze layer: POST to Clair failed Post http://127.0.0.1:6060/v1/layers: dial tcp 127.0.0.1:6060: getsockopt: connection refused

After some diggings, I noticed the container was stopped immediately after the scan with a fatal erorr (which I guess that's why the previous erorr with "connection refused" was shown, maybe after a retry after the container crash):

$ docker logs clair
...
panic: runtime error: slice bounds out of range [25:24

But If look before this error in the container log (even before scanning when the container is up & running), I noticed this error, which might be the root cause of that container crash "panic : runtime error: ...":

$ docker logs clair
...
2021-04-21T09:12:40.4501447Z {"Event":"could not pull ubuntu-cve-tracker repository","Level":"error","Location":"ubuntu.go:174","Time":"2021-04-21 09:12:38.463262","error":"exit status 128","output":"Cloning into '.'...\nfatal: unable to access 'https://git.launchpad.net/ubuntu-cve-tracker/': The requested URL returned error: 503\n"}

When I try to locally do a "git clone on https://git.launchpad.net/ubuntu-cve-tracker/" I get the same error:

git clone https://git.launchpad.net/ubuntu-cve-tracker/
Cloning into 'ubuntu-cve-tracker'...
fatal: unable to access 'https://git.launchpad.net/ubuntu-cve-tracker/': The requested URL returned error: 503

But If I do a web-browse on this one https://git.launchpad.net/ubuntu-cve-tracker/ it works, where also I noticed that there are other way of mirroring this git repository for ubuntu-cve-tracker: git://git.launchpad.net/ubuntu-cve-tracker , which works:

git clone git://git.launchpad.net/ubuntu-cve-tracker
Cloning into 'ubuntu-cve-tracker'...
remote: Enumerating objects: 682122, done.
remote: Counting objects: 100% (682122/682122), done.
remote: Compressing objects: 100% (69081/69081), done.
Receiving objects: 100% (682122/682122), 105.11 MiB | 1.37 MiB/s, done.
remote: Total 682122 (delta 620026), reused 673859 (delta 612686)
Resolving deltas: 100% (620026/620026), done.
Updating files: 100% (39942/39942), done.

Because of this it seems that the scanner is not working (even when I tried with different versions/tags of clair-local-scan).
Can this remote repository for ubuntu-cve-tracker be changed to the above one which works, until Ubuntu will fix their issue with the https one?
If there's another issue, can you please have a look into it ?

Thank you in advance.

Kind regards,
Bogdan Velcea

Hi @arminc,

the cron Travis build of the arminc/clair-db docker image is failing since 7 days.
When I have time, I will also have a look into the reasons, but currently I cannot.

Thanks and cheers,
usr42/Balthasar

Hi everyone,

I would like to manually maintain and seed the Claid-DB, could you kindly please share the steps necessary for this task

Thanks

2.0.2 has been released on March 19. Could you please update?

Please could the documentation be updated with any alternatives to docker --link, as this is marked as deprecated in Docker itself (see https://docs.docker.com/network/links/) and doesn't exist as an option for podman?

It appears that --link allowed a shared network (which is not an issue with podman, and clair could be launched as a pod) but also pushes environment-variables from the database container to the application container... which could likely be replicated manually. This would be an easier job if any guidance could be offered in terms of which values are actually needed?

The last update to check.sh has converted a warning in the logs into an exit 2. This prevents the db from being uploaded to DockerHub.

This means we no longer get security updates. There haven't been any since 10/29/20.

Is this because the warning was preventing the db from being updated correctly? Was it giving false results?

Looking through Travis, I wondered if this a result of upgrading to 2.1.6? If so, would you consider dropping back to 2.1.5? It seems like either this should to be fixed (ideally) or downgrading to 2.1.5 undertaken if that will fix it. Going for months without security updates is pretty risky.

That said I understand you support this on a best effort basis. I don't know all the issues involved but would be willing to try to help out if you like, as long as you're available via email for questions.

We are running clair scanner to run security scan on our docker images.
The clair scanner runs inside a travis build and in our case both clair scanner and clair runs on same machine that is launched by travis.

However , we see following issue intermittently in some of the travis build run:-

8.98s$ clair-scanner -w tests/cve-scan-whitelist.yaml -c "http://127.0.0.1:6060" --threshold="High" --ip "$(ip -4 addr show docker0 | grep -oP '(?<=inet\s)\d+(.\d+){3}')" $IMAGE_NAME:latest
2021/06/09 01:28:57 [INFO] ▶ Start clair-scanner
2021/06/09 01:29:06 [INFO] ▶ Server listening on port 9279
2021/06/09 01:29:06 [INFO] ▶ Analyzing cbb111c748af833f9ef620afd2320b662c7a04b0e3cf08caf4e4f25af031892b
2021/06/09 01:29:06 [CRIT] ▶ Could not analyze layer: POST to Clair failed Post http://127.0.0.1:6060/v1/layers: dial tcp 127.0.0.1:6060: getsockopt: connection refused
The command "clair-scanner -w tests/cve-scan-whitelist.yaml -c "http://127.0.0.1:6060" --threshold="High" --ip "$(ip -4 addr show docker0 | grep -oP '(?<=inet\s)\d+(.\d+){3}')" $IMAGE_NAME:latest" exited with 1.

This issue is very intermittent and sometimes build will pass without any issues. Is there any issue with --ip I am giving.
I tried passing --ip "$(hostname -i)" , but still gets same issue.

Below are complete set of commands we have defined in .travis.yml

• curl -L https://github.com/arminc/clair-scanner/releases/download/v8/clair-scanner_linux_amd64 > clair-scanner
• chmod +x clair-scanner
• sudo mv clair-scanner /usr/local/bin
• docker run -d --name db arminc/clair-db
• docker run -p 6060:6060 --link db:postgres -d --name clair arminc/clair-local-scan:v2.0.6
• clair-scanner -w tests/cve-scan-whitelist.yaml -c "http://127.0.0.1:6060" --threshold="High" --ip "$(ip -4 addr show docker0 |
  grep -oP '(?<=inet\s)\d+(.\d+){3}')" $IMAGE_NAME:latest

We've been running in Azure pipelines for over a year without any problems, but now we have to start the local scan twice.

This is our scan script:

docker run -d --name db arminc/clair-db
sleep 1 # wait for db to come up

docker run -p 6060:6060 --link db:postgres -d --name clair arminc/clair-local-scan
sleep 15

docker rm clair
docker run -p 6060:6060 --link db:postgres -d --name clair arminc/clair-local-scan

sleep 1

DOCKER_GATEWAY=$(docker network inspect bridge --format "{{range .IPAM.Config}}{{.Gateway}}{{end}}")
wget -qO clair-scanner https://github.com/arminc/clair-scanner/releases/download/v8/clair-scanner_linux_amd64 && chmod +x clair-scanner
./clair-scanner -t Critical --ip="$DOCKER_GATEWAY" "${CONTAINERREGISTRYSERVICECONNECTION}.azurecr.io/${IMAGEREPOSITORY}:${IMAGETAG}"

docker stop db
docker stop clair

docker rm db
docker rm clair

Thanks for merging my PR to use clair:v2.0.2.

Now that clair:2.0.2 is used as base, also the arminc/clair-local-scan docker hub image should be tagged with v2.0.2.

The v2.0.1 tag in docker hub was overwritten with the v2.0.2 image. This should also be fixed.

Hello,
Clair has moved on to 2.0.6. One critical issue which was fixed was quay/clair#622
Request to update to 2.0.6

Database is created using Clair v2, we should create a secondary build as well using Clair v4.

arminc/clair-scanner#63 happens also when starting the container with:

docker run -p 6060:6060 --link db:postgres -d --name clair arminc/clair-local-scan:v2.0.6

Do we need to put the docker host ip?

I believe there is a problem with the latest Docker image tagged as v2.1.8_a0644866e5e1b81763de7e330f535f561bfd65c8. It does not publish any public ports:

4f7d1efe4054   arminc/clair-local-scan:v2.1.8_a0644866e5e1b81763de7e330f535f561bfd65c8                            "/clair -config=/con…"   2 minutes ago    Up 2 minutes                                          clair
263029064bcf   registry:2.7.1                                                                                     "/entrypoint.sh /etc…"   2 minutes ago    Up 2 minutes                0.0.0.0:55003->5000/tcp   registry
47f918ed5a11   arminc/clair-db:2022-05-13                                                                         "docker-entrypoint.s…"   2 minutes ago    Up 2 minutes                0.0.0.0:55002->5432/tcp   clair-db

This works fine with the last but one image i.e. v2.1.8_9bca9a9a7bce2fd2e84efcc98ab00c040177e258:

eb2aae873adb   arminc/clair-local-scan:v2.1.8_9bca9a9a7bce2fd2e84efcc98ab00c040177e258   "/usr/bin/dumb-init …"   2 minutes ago   Up 2 minutes   0.0.0.0:55012->6060/tcp, 0.0.0.0:55011->6061/tcp   clair
a9df3dcfe8c2   registry:2.7.1                                                            "/entrypoint.sh /etc…"   2 minutes ago   Up 2 minutes   0.0.0.0:55010->5000/tcp                            registry
baceabfd20af   arminc/clair-db:2022-05-13                                                "docker-entrypoint.s…"   2 minutes ago   Up 2 minutes   0.0.0.0:55009->5432/tcp                            clair-db

Practically, the latest tag v2.1.8_a0644866e5e1b81763de7e330f535f561bfd65c8 is unusable.

Clair provides an image for version 3 https://quay.io/repository/coreos/clair-git. clair-local-scan should also provide that.

Edit:
https://github.com/genuinetools/reg