Remove Java artifacts scanning from vulnerability scans [DI-50] #778
Conversation
JackPGreen
changed the title
…m-hazelcast-docker
| HZ_VERSION=$(awk -F '=' '/^ARG HZ_VERSION=/ {print $2}' hazelcast-enterprise/Dockerfile) | ||
| HAZELCAST_EE_ZIP_URL=$(get_hz_dist_zip "" "${HZ_VERSION}") | ||
| curl --fail --silent --show-error --location "$HAZELCAST_EE_ZIP_URL" --output hazelcast-enterprise/hazelcast-enterprise-distribution.zip; | ||
| # Make a dummy empty ZIP file to avoid scanning Java dependencies, as managed downstream |
There was a problem hiding this comment.
Could we use the real zip but remove all *.jar files from it? This way we would be a bit closer to the docker image we actually push.
I have concerns about executable scripts from the distribution zips, if they're used in a safe manner, although I'm not sure if they're scanned.
WDYT @kwart ?
There was a problem hiding this comment.
Could we use the real zip but remove all *.jar files from it? This way we would be a bit closer to the docker image we actually push.
I have concerns about executable scripts from the distribution zips, if they're used in a safe manner, although I'm not sure if they're scanned.
WDYT @kwart ?
I'm assuming that the distribution ZIPs are already scanned and considered safe, so further tests are redundant/duplicated.
There was a problem hiding this comment.
Jars are scanned for sure, not sure about shell scripts. I don't have strong opinion here.
Don't know if it makes any difference, if you compare the scan results it might be an indicator it it makes sense
…m-hazelcast-docker
@JackPGreen any comment on that? |
Yes, it's fine. Before we were only failing because of Java dependencies, now were passing.
|
…m-hazelcast-docker
JackPGreen
deleted the
DI-50---Remove-java-artifacts-scanning-from-hazelcast-docker
branch
In #778 we swapped our usage of `dockle-action` to our forked version to workaround goodwithtech/dockle-action#7 - now thhis has been fixed upstream we can use it again.
In #778 we swapped our usage of `dockle-action` to our forked version to workaround goodwithtech/dockle-action#7 - now thhis has been fixed upstream we can use it again.
In #778 we swapped our usage of `dockle-action` to our forked version to workaround goodwithtech/dockle-action#7 - now thhis has been fixed upstream we can use it again.
In #778 we swapped our usage of `dockle-action` to our forked version to workaround goodwithtech/dockle-action#7 - now thhis has been fixed upstream we can use it again.
In #778 we swapped our usage of `dockle-action` to our forked version to workaround goodwithtech/dockle-action#7 - now thhis has been fixed upstream we can use it again.
The vulnerability scan workflow is regularly failing because of false-positive vulnerabilities inside the Hazelcast distribution JAR.
We already scan, manage and catalogue vulnerabilities upstream for the wider Hazelcast product, so this additional layer is not properly managed and ends up failing.
Reworked these checks to only focus on the Docker image, not the Hazelcast distribution, by replacing the Hazelcast distribution with a dummy empty ZIP.
Having got the scanners working, it became apparent we are also affected by goodwithtech/dockle-action#7 - so until my fix is merged upstream, I've moved this action onto using my fixed branch in a fork, instead.
Also refactored duplicated OS + EE job to use a centralised matrix.
Fixes: DI-50