Closed ovizii closed 2 years ago
Most probably because I am integrating packages within the docker image that are from early 2021 and should be refreshed...
I haven't really recompiled the image since so might be on a future to do list...
Cool, thanks for taking not and your reply. Feel free to close the ticket whenever you like. Looking forward to updated images when you get around to it, I guess one could always use your Dockerfile and create one's own image if not wanting to wait for updates :-)
Did you also check the db image?, does trivy give you verbose details about these.. Total: 2108 seems like alot, many might be the same xss over and over etc.
I am not sure which DB image you are talking about. This is a one-image guacamole solution. The image used is maxwaldorf/guacamole:1.3 and it is based upon tomcat:jdk15-openjdk-slim-buster.
@tablatronix if you are curious about the numbers, just give it a try and run this to see all the details.
docker run --rm -v /tmp:/root/.cache/ -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy:0.18.3 maxwaldorf/guacamole:1.3 | more
You only compared the image to tomcat, not postgresql, maybe it exposes something ?
@tablatronix if you had looked at his Dockerfile you would have understood what I am trying to tell you: I use maxwaldorf/guacamole:1.3 which is based upon tomcat:jdk15-openjdk-slim-buster. There are no other images involved.
Check it out: https://github.com/MaxWaldorf/guacamole/blob/main/Dockerfile he is manually installing postgres in line 42
oh it literally checks images my bad, I thought trivy was running in the container.. Its its own container doh
no worries. You are kinda right, I am running trivy from a temporary container and have it scan another container in this case: maxwaldorf/guacamole:1.3
image updated to guacamole 1.4.0 I wonder if score is improved now...
thanks, will give it a try right now. I changed my docker-compose.yml and am now using this image: maxwaldorf/guacamole:1.4
here is a trivy test result:
docker run --rm -v /tmp:/root/.cache/ -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy:0.18.3 maxwaldorf/guacamole:1.4 | more
maxwaldorf/guacamole:1.4 (debian 10.11)
=======================================
Total: 1548 (UNKNOWN: 1, LOW: 161, MEDIUM: 823, HIGH: 492, CRITICAL: 71)
if interested, you can also scan up to 10 images each month for free with snyk but I reached my limit already:
docker scan maxwaldorf/guacamole:1.4
You have reached the scan limit of 10 monthly scans without authentication.
Closing this issue as I cannot make this more up-to-date than the new image created...
Hi there,
guacamole is apparently not vulnerable to the log4j vulnerability => https://issues.apache.org/jira/projects/GUACAMOLE/issues/GUACAMOLE-1474?filter=allissues
but seeing that I had already started looking into security issues, I started checking the images I run with trivy and was surprised by the high number of findings. I had a look at your Dockerfile and its based upon: tomcat:jdk15-openjdk-slim-buster so I was wondering if that is no longer being maintained? The latter findings (see below) are obviously are on Guacamole's side not much we can do about them.
Here is how you can run it:
docker run --rm -v /tmp:/root/.cache/ -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy:0.18.3 maxwaldorf/guacamole:1.3 | more
and
docker run --rm -v /tmp:/root/.cache/ -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy:0.18.3 tomcat:jdk15-openjdk-slim-buster | more
Here is a quick overview of the findings, without going into the details I am just wondering why maxwaldorf/guacamole:1.3 has way more vulnerabilities than its base image tomcat:jdk15-openjdk-slim-buster?