Setup security workflow that tests CVEs in the docker image on change

[hydrapolic]

Currently, our trivy job runs but might not be able to detect CVEs in our docker image prior to publishing it.

For example, while our security workflow passes, trivy image openzipkin/zipkin-gcp:2.3 fails with a high severity issue on alpine packages.

To solve this, let's make a new workflow called security-docker based on the security one.

• before trivy runs in that workflowm, build docker/ directory similar this: https://github.com/openzipkin/zipkin-dependencies/blob/master/.github/workflows/test_readme.yml
• change the trivy part of that workflow to only look at that test docker image and nothing else.
• make sure that security workflow isn't run unless pom or dockerfile changes occurred.

This workflow should fail similar to running ad-hoc. Assuming it does, lets do something similar in the docker-java and docker-alpine repos so that they also run trivy only after building the image.

[shakuzen]

Thanks for opening the issue. Would you be willing to open a pull request that bumps the versions of dependencies?

[hydrapolic]

Seems like the latest 2.3 is doing better, however the alpine image beneath needs an apk upgrade.

trivy image openzipkin/zipkin-gcp:2.3

openzipkin/zipkin-gcp:2.3 (alpine 3.21.2)

Total: 7 (UNKNOWN: 2, LOW: 0, MEDIUM: 3, HIGH: 2, CRITICAL: 0)

┌────────────┬────────────────┬──────────┬────────┬───────────────────┬───────────────┬─────────────────────────────────────────────────────────────┐
│  Library   │ Vulnerability  │ Severity │ Status │ Installed Version │ Fixed Version │                            Title                            │
├────────────┼────────────────┼──────────┼────────┼───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ libcrypto3 │ CVE-2024-12797 │ HIGH     │ fixed  │ 3.3.2-r4          │ 3.3.3-r0      │ openssl: RFC7250 handshakes with unauthenticated servers    │
│            │                │          │        │                   │               │ don't abort as expected                                     │
│            │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2024-12797                  │
│            ├────────────────┼──────────┤        │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│            │ CVE-2024-13176 │ MEDIUM   │        │                   │ 3.3.2-r5      │ openssl: Timing side-channel in ECDSA signature computation │
│            │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2024-13176                  │
├────────────┼────────────────┼──────────┤        │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│ libssl3    │ CVE-2024-12797 │ HIGH     │        │                   │ 3.3.3-r0      │ openssl: RFC7250 handshakes with unauthenticated servers    │
│            │                │          │        │                   │               │ don't abort as expected                                     │
│            │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2024-12797                  │
│            ├────────────────┼──────────┤        │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│            │ CVE-2024-13176 │ MEDIUM   │        │                   │ 3.3.2-r5      │ openssl: Timing side-channel in ECDSA signature computation │
│            │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2024-13176                  │
├────────────┼────────────────┤          │        ├───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ libtasn1   │ CVE-2024-12133 │          │        │ 4.19.0-r2         │ 4.20.0-r0     │ libtasn1: Inefficient DER Decoding in libtasn1 Leading to   │
│            │                │          │        │                   │               │ Potential Remote DoS                                        │
│            │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2024-12133                  │
├────────────┼────────────────┼──────────┤        ├───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ musl       │ CVE-2025-26519 │ UNKNOWN  │        │ 1.2.5-r8          │ 1.2.5-r10     │ musl libc 0.9.13 through 1.2.5 before 1.2.6 has an          │
│            │                │          │        │                   │               │ out-of-bounds write ......                                  │
│            │                │          │        │                   │               │ https://avd.aquasec.com/nvd/cve-2025-26519                  │
├────────────┤                │          │        │                   │               │                                                             │
│ musl-utils │                │          │        │                   │               │                                                             │
│            │                │          │        │                   │               │                                                             │
│            │                │          │        │                   │               │                                                             │
└────────────┴────────────────┴──────────┴────────┴───────────────────┴───────────────┴─────────────────────────────────────────────────────────────┘

[shakuzen]

We have trivy configured on https://github.com/openzipkin/docker-alpine, so I wonder if these HIGH CVEs came up since the last release of that 2 weeks ago. I'm not sure there's anything to do in this repo anymore since the Java deps are all patched now. /cc @reta @codefromthecrypt

Users that want to resolve these without us needing to release everything in the chain can build a container image FROM zipkin-gcp and run apk upgrade, I think.

[codefromthecrypt]

yep before cutting 2.3.0 I made sure our policy for trivy passed. new cves will always occur later, but at the moment all good. https://github.com/openzipkin/zipkin-gcp/releases/tag/2.3.0

[codefromthecrypt]

basically we have a a trivy workflow on our docker images and we resolve them as we can. as this is an unpaid bunch of volunteers we can't give a higher level of service than this.

Here's the workflow on the base image
https://github.com/openzipkin/docker-java/blob/master/.github/workflows/security.yml
and here are notes if you find something on that image and want to help contribute to more patches
https://github.com/openzipkin/docker-java?tab=readme-ov-file#cves

At any point, we can re-kick the docker build on a version such as here to rebuild the image. One of the maintainers needs to make a tag docker-2.3.0 and it will rebuild it, if for example the corresponding alpine image was re-pushed with more updates.

[codefromthecrypt]

So, right now we are green here https://github.com/openzipkin/zipkin-gcp/actions/runs/13382840730

So, what could be a way forward might be to have this run after building the docker image, as maybe it isn't able to detect what would be built given the dockerfile.

If someone has time to implement that, it could reduce the amount of CVEs.

Here's a way out make a new workflow called security-docker based on the security one.

• before trivy runs in that workflowm, build docker/ directory similar this: https://github.com/openzipkin/zipkin-dependencies/blob/master/.github/workflows/test_readme.yml
• change the trivy part of that workflow to only look at that test docker image and nothing else.
• make sure that security workflow isn't run unless pom or dockerfile changes occurred.

I've updated the description and re-opened this

[codefromthecrypt]

@hydrapolic apologies I jumped to conclusions. I think you are right on this and put a plan together. Help wanted as I'm way over budget timewise over the last several days.