## Summary Triage of the project [Vulnerability Report](https://gitlab.com/gitlab-org/duo-workflow/default-docker-image/-/security/vulnerability_report/) completed on 2026-06-10. - **Total findings:** 87 - **Severity:** HIGH (all 87) - **Scanner:** Container Scanning (all 87) - **State:** DETECTED (all active; none resolved or dismissed) ## Triage outcome **No findings were dismissed.** All 87 are genuine, vendor-acknowledged CVEs with real vulnerable package versions and no false-positive flags. Dismissal was not appropriate. However, every sampled finding shares a consistent **deprioritization** profile: - **EPSS score:** 0.0 (negligible probability of exploitation in the wild) - **Known exploit:** No (not on any known-exploited list) - **Reachability:** Not applicable — Container Scanning does not provide reachability data, so it was not used as a triage signal. These are real issues that should be fixed, but none are under active exploitation, so they do not require emergency response. ## Recommended remediation The vast majority of these findings are **OS/base-image package CVEs** (kernel-headers, gnutls, openjdk, ruby/ERB, expat, libpng, python36, git-lfs, krb5-libs, libcap, binutils, etc.) across the `workflow-generic-image` and `workflow-generic-image-hardened` images. The most effective single action is to **rebuild the container images on updated base layers** and re-run the pipeline. This will pull in patched package versions and resolve most of these findings in one pass. ### Suggested steps 1. Update the base image reference(s) in the Dockerfile(s) to the latest patched tags. 2. Run `dnf update` / package upgrades during the build so userspace packages (gnutls, openjdk, ruby gems, expat, libpng, python, git-lfs, krb5-libs, libcap, binutils) pick up fixes. 3. Re-run the security pipeline and compare the new Vulnerability Report against this baseline. 4. For any findings that persist after rebuild (e.g. packages with no upstream fix yet, or `end_of_life` packages such as some kernel-headers CVEs), re-triage individually and decide on risk acceptance. ## Notable context - A large subset are **`kernel-headers`** Linux kernel CVEs. Containers do not run their own kernel, so the practical exploitability of these via the container is limited. They were **kept active** (not dismissed) but are good candidates for individual `NOT_APPLICABLE` review if the team confirms they are out of scope for this deployment. - At least one finding (CVE-2025-21927, kernel-headers) shows `Vendor Status: end_of_life`, meaning no upstream fix is expected for that package stream — these may require base-image migration rather than a package update. - Notable userspace CVE worth attention: **CVE-2026-41316** (ERB/`rubygem-psych`) is a deserialization-to-RCE issue; prioritize the Ruby gem updates in the rebuild. ## Risk acceptance note Until the rebuild lands, these remain accepted-but-tracked risks based on EPSS 0.0 and no known exploitation. No automated dismissals were performed.