Similar to how we scan our dependencies using OWASP vulnerability scans (links below) we are working on a solution to scan our Docker images as well.
This topic was initially introduced at the Pulsar community meeting on 2023-12-21 and we decided to expand the discussion to a wider audience before proceeding. Ultimate Goal: Create CVE-free Pulsar Docker container images Immediate Goal: Create Pulsar Docker container images w/ no newly introduced CVEs We are working on a prototype (https://github.com/onobc/github-actions-sandbox) that uses Trivy in a Github action workflow to scan a container(s) in a scheduled manner. Plan is as follows: Step 1: Introduce a scheduled Github Action workflow that performs the scan Step 2: Trigger the scan when the containers are rebuilt to prevent publishing w/ CVEs We chose to iteratively introduce the scan first via an offline schedule as it is a non-intrusive (Step 1), low-risk entry point. This benefit is also the downside (tradeoff) in that there is nothing to prevent changes from introducing new CVEs into newly built container images. Humans are not reliable at polling a resource for an error before proceeding w/ their work. As such, the intention is to continue (Step 2) and move the trigger into the CI pipeline at the proper point so that if new CVEs are introduced, the pipeline fails (user is blocked and issue is addressed). Long term, rather than "new CVE introduced" we would like it to be if "any CVE exists then block". Does anyone have objections to using Trivy for the scanner tool? If so, please explain. Does anyone else have any objections, concerns, or direction before we proceed w/ the above plan? Thanks, Chris Trivy container scan prototype: https://github.com/onobc/github-actions-sandbox Current OWASP dependency scanner links: * https://jeremylong.github.io/DependencyCheck/dependency-check-maven/ * https://github.com/apache/pulsar/blob/8beac8b12ef7c0ef54529fbb7e4e76c54dea6283/pom.xml#L2428 * https://github.com/apache/pulsar/blob/master/.github/workflows/ci-owasp-dependency-check.yaml#L30
