Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add alpine tag for container #164

Open
evan361425 opened this issue Jan 20, 2022 · 4 comments
Open

Add alpine tag for container #164

evan361425 opened this issue Jan 20, 2022 · 4 comments

Comments

@evan361425
Copy link

Using Amazon 2 will detected the CVEs by Trivy

Although we are not using python, it still exist in the OS. Could we add more tags for different OS or delete some unused packages(e.g. usr/lib64/python2.7/lib-dynload/Python-2.7.18-py2.7.egg-info) when building image?

@srprash
Copy link
Collaborator

srprash commented Jan 24, 2022

Hi @evan361425
Thanks for bringing this to our notice. Adding some links for the CVEs so that they are easier to find.

https://nvd.nist.gov/vuln/detail/CVE-2021-3177
https://nvd.nist.gov/vuln/detail/CVE-2016-2183
https://nvd.nist.gov/vuln/detail/CVE-2019-20907
https://nvd.nist.gov/vuln/detail/CVE-2020-26116

Did you find these CVEs in the Dockerhub image or the public ECR image?
I believe that since the public ECR image is built from scratch as base image, it shouldn't contain these python related vulnerabilities. Can you verify that?

@evan361425
Copy link
Author

evan361425 commented Jan 25, 2022

I found it in Docker Hub image.
I do confirm the image have the python files (that is why Trivy shown the vulnerabilities):

$ docker run --net=host -e AWS_REGION=ap-northeast-1 -d amazon/aws-xray-daemon -o      
87a4e6fc6975816793ca648a42f116fedfc242e0d9d427f84357622a98269110

$ ls -l /usr/lib64 | grep python
-rwxr-xr-x  1 root root 1790912 Jun 10  2021 libpython2.7.so.1.0
drwxr-xr-x 27 root root   20480 Dec  1 18:20 python2.7

And the vulnerable file is /usr/lib64/python2.7/lib-dynload/Python-2.7.18-py2.7.egg-info

@srprash
Copy link
Collaborator

srprash commented Feb 7, 2022

Hi @evan361425
Would it be possible for you to use the public ECR image instead of the DockerHub one?

At this point I'm not sure if we remove the Python module from the image, it won't break its functionality or have other implications. Since the daemon itself is a GoLang program and doesn't use Python in any form, I believe these vulnerabilities are not exploitable for the daemon.

@evan361425
Copy link
Author

Hi @srprash.

If removing the vulnerable package will break the functionality then we are using the vulnerable package implicitly and we should fix it.

If not then removing it makes this issue kind of enhancement request.

Making container image more tiny is a good practice anyway.

The reason I open this issue is Trivy detect the vulnerable package and start warning. Trivy don't know whether application use the package or not. It just detect the existence of vulnerability.

For your information I have remove the package and commit a new tag myself to fix Trivy warning and it works fine in lab environment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants