Repository navigation
feat(ci): restore container image vulnerability scanning with Grype - #44035
Conversation
Trivy scanning was removed from the docker-build workflow in apache#38780 after both aquasecurity/trivy-action and the trivy binary itself were compromised (twice, per the ASF incident report and a follow-up StepSecurity report) to steal credentials from GitHub Secrets during CI runs. No replacement was put in place, so the built lean image hasn't had vulnerability results uploaded to the Security tab since. Adds anchore/scan-action (Grype) instead of going back to Trivy: a different tool from a different maintainer with no shared supply chain, already on the ASF Infrastructure GitHub Actions allowlist (no new approval request needed), and it produces SARIF the same way Trivy did. Scoped `security-events: write` to just the docker-build job for the SARIF upload, matching the same grant pattern already used in github-action-validator.yml for zizmor's scan. Configured as informational-only (fail-build: false), matching the prior Trivy setup -- this workflow still doesn't gate merges on scan findings. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Bito Automatic Review Skipped - Files Excluded |
…igger on docker.yml changes Addresses both CodeAnt review comments on apache#44035: - docker-build is gated by the change-detector's python/frontend/docker categories, none of which classified .github/workflows/docker.yml itself. A change to only that file (like this PR) would never trigger the job, so a broken vulnerability-scan step would go unexercised until some unrelated app-code push happened to ride along with it. Added a docker.yml pattern to the "docker" category, matching how this file already carries dedicated patterns for other CI-relevant workflow files. - Added continue-on-error to both the scan and upload steps, and gated the upload on the scan actually having produced a SARIF file. fail-build: false already covers findings not failing the build; this covers the scan/upload steps themselves erroring out (a transient DB pull issue, a GitHub API hiccup) and marking master's docker-build red for something that's meant to be purely informational. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #44035 +/- ##
==========================================
+ Coverage 79.88% 79.89% +0.01%
==========================================
Files 2915 2916 +1
Lines 170737 170755 +18
Branches 39566 39569 +3
==========================================
+ Hits 136391 136432 +41
+ Misses 31829 31805 -24
- Partials 2517 2518 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Code Review Agent Run #8377a0Actionable Suggestions - 0Review Details
Bito Usage GuideCommands Type the following command in the pull request comment and save the comment.
Refer to the documentation for additional commands. Configuration This repository uses Documentation & Help |
…ython for CVE-2026-6100 Two independent findings from the container-image vulnerability scan restored in apache#44035 (its first real run since Trivy was removed in apache#38780): Grype self-match false positives: the built image bundles this project's own dev build as the "apache-superset" package, installed from source with version "0.0.0.dev0" instead of a real released version. Grype cannot compare that placeholder against a fixed-version threshold, so it matches every historical apache-superset GHSA ever published as still unfixed -- confirmed 61 matches locally against this exact package metadata (up to Critical severity), including GHSA-92qf-8gh3-gwcm, GHSA-rwhh-6x83-84v6, and GHSA-wh73-hpcg-v32j, all patched years ago (4.1.0, 3.0.3, and 1.4.2 respectively) and obviously not still open on current master. Added .grype.yaml excluding the paths where that self-referential package metadata lives in the image; verified locally that this drops apache-superset matches to zero while every other package's real findings are untouched. CVE-2026-6100-python: a real, currently open finding. The base image pins Python 3.11.14-slim-trixie (Dockerfile ARG PY_VER), vulnerable to a use-after-free in lzma/bz2/gzip decompressor reuse after a MemoryError; fixed in 3.11.16 (confirmed tag published on Docker Hub 2026-09-02). Bumped all three places this version is pinned in lockstep: the Dockerfile ARG default, docker-build-extra-flags.sh's override for every non-py311/py312 preset, and the pyver-override-check workflow job's assertion of the expected effective --build-arg value. Co-Authored-By: Evan Rusackas <evan@preset.io> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ython for CVE-2026-6100 Two independent findings from the container-image vulnerability scan restored in apache#44035 (its first real run since Trivy was removed in apache#38780): Grype self-match false positives: the built image bundles this project's own dev build as the "apache-superset" package, installed from source with version "0.0.0.dev0" instead of a real released version. Grype cannot compare that placeholder against a fixed-version threshold, so it matches every historical apache-superset GHSA ever published as still unfixed -- confirmed 61 matches locally against this exact package metadata (up to Critical severity), including GHSA-92qf-8gh3-gwcm, GHSA-rwhh-6x83-84v6, and GHSA-wh73-hpcg-v32j, all patched years ago (4.1.0, 3.0.3, and 1.4.2 respectively) and obviously not still open on current master. Added .grype.yaml excluding the paths where that self-referential package metadata lives in the image; verified locally that this drops apache-superset matches to zero while every other package's real findings are untouched. CVE-2026-6100-python: a real, currently open finding. The base image pins Python 3.11.14-slim-trixie (Dockerfile ARG PY_VER), vulnerable to a use-after-free in lzma/bz2/gzip decompressor reuse after a MemoryError; fixed in 3.11.16 (confirmed tag published on Docker Hub 2026-09-02). Bumped all three places this version is pinned in lockstep: the Dockerfile ARG default, docker-build-extra-flags.sh's override for every non-py311/py312 preset, and the pyver-override-check workflow job's assertion of the expected effective --build-arg value. Co-Authored-By: Evan Rusackas <evan@preset.io> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ython for CVE-2026-6100 Two independent findings from the container-image vulnerability scan restored in apache#44035 (its first real run since Trivy was removed in apache#38780): Grype self-match false positives: the built image bundles this project's own dev build as the "apache-superset" package, installed from source with version "0.0.0.dev0" instead of a real released version. Grype cannot compare that placeholder against a fixed-version threshold, so it matches every historical apache-superset GHSA ever published as still unfixed -- confirmed 61 matches locally against this exact package metadata (up to Critical severity), including GHSA-92qf-8gh3-gwcm, GHSA-rwhh-6x83-84v6, and GHSA-wh73-hpcg-v32j, all patched years ago (4.1.0, 3.0.3, and 1.4.2 respectively) and obviously not still open on current master. Added .grype.yaml excluding the paths where that self-referential package metadata lives in the image; verified locally that this drops apache-superset matches to zero while every other package's real findings are untouched. CVE-2026-6100-python: a real, currently open finding. The base image pins Python 3.11.14-slim-trixie (Dockerfile ARG PY_VER), vulnerable to a use-after-free in lzma/bz2/gzip decompressor reuse after a MemoryError; fixed in 3.11.16 (confirmed tag published on Docker Hub 2026-09-02). Bumped all three places this version is pinned in lockstep: the Dockerfile ARG default, docker-build-extra-flags.sh's override for every non-py311/py312 preset, and the pyver-override-check workflow job's assertion of the expected effective --build-arg value. Co-Authored-By: Evan Rusackas <evan@preset.io> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ython for CVE-2026-6100 Two independent findings from the container-image vulnerability scan restored in apache#44035 (its first real run since Trivy was removed in apache#38780): Grype self-match false positives: the built image bundles this project's own dev build as the "apache-superset" package, installed from source with version "0.0.0.dev0" instead of a real released version. Grype cannot compare that placeholder against a fixed-version threshold, so it matches every historical apache-superset GHSA ever published as still unfixed -- confirmed 61 matches locally against this exact package metadata (up to Critical severity), including GHSA-92qf-8gh3-gwcm, GHSA-rwhh-6x83-84v6, and GHSA-wh73-hpcg-v32j, all patched years ago (4.1.0, 3.0.3, and 1.4.2 respectively) and obviously not still open on current master. Added .grype.yaml excluding the paths where that self-referential package metadata lives in the image; verified locally that this drops apache-superset matches to zero while every other package's real findings are untouched. CVE-2026-6100-python: a real, currently open finding. The base image pins Python 3.11.14-slim-trixie (Dockerfile ARG PY_VER), vulnerable to a use-after-free in lzma/bz2/gzip decompressor reuse after a MemoryError; fixed in 3.11.16 (confirmed tag published on Docker Hub 2026-09-02). Bumped all three places this version is pinned in lockstep: the Dockerfile ARG default, docker-build-extra-flags.sh's override for every non-py311/py312 preset, and the pyver-override-check workflow job's assertion of the expected effective --build-arg value. Co-Authored-By: Evan Rusackas <evan@preset.io> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ython for CVE-2026-6100 Two independent findings from the container-image vulnerability scan restored in apache#44035 (its first real run since Trivy was removed in apache#38780): Grype self-match false positives: the built image bundles this project's own dev build as the "apache-superset" package, installed from source with version "0.0.0.dev0" instead of a real released version. Grype cannot compare that placeholder against a fixed-version threshold, so it matches every historical apache-superset GHSA ever published as still unfixed -- confirmed 61 matches locally against this exact package metadata (up to Critical severity), including GHSA-92qf-8gh3-gwcm, GHSA-rwhh-6x83-84v6, and GHSA-wh73-hpcg-v32j, all patched years ago (4.1.0, 3.0.3, and 1.4.2 respectively) and obviously not still open on current master. Added .grype.yaml excluding the paths where that self-referential package metadata lives in the image; verified locally that this drops apache-superset matches to zero while every other package's real findings are untouched. CVE-2026-6100-python: a real, currently open finding. The base image pins Python 3.11.14-slim-trixie (Dockerfile ARG PY_VER), vulnerable to a use-after-free in lzma/bz2/gzip decompressor reuse after a MemoryError; fixed in 3.11.16 (confirmed tag published on Docker Hub 2026-09-02). Bumped all three places this version is pinned in lockstep: the Dockerfile ARG default, docker-build-extra-flags.sh's override for every non-py311/py312 preset, and the pyver-override-check workflow job's assertion of the expected effective --build-arg value. Co-Authored-By: Evan Rusackas <evan@preset.io> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SUMMARY
Container image vulnerability scanning has been dark since #38780 removed
aquasecurity/trivy-actionfromdocker.yml. That removal was the right call: both the Action and thetrivybinary itself were compromised (twice), per ASF's incident report and a follow-up StepSecurity writeup — the injected code harvested/proc/*/environand process memory for secrets, SSH keys, and cloud credentials, and exfiltrated them. No replacement was put in place, so thedocker.yml:docker-buildcode-scanning configuration has been showing as stale/failing in the Security tab ever since (nothing has uploaded results for it in ~6 months).This PR restores scanning with Grype (
anchore/scan-action) instead of going back to Trivy: a different tool, different maintainer, no shared supply chain with the compromised project. It's already on the ASF Infra GitHub Actions allowlist (anchore/scan-action@27805bf3.../v7.4.2), so no new allowlist request is needed —asf-allowlist-checkshould pass as-is.CHANGES
Scan built image for vulnerabilitiesstep (Grype, SARIF output) and anUpload vulnerability scan results to GitHub Security tabstep (github/codeql-action/upload-sarif, same pin already used incodeql-analysis.yml), gated on the same condition the old Trivy step used (pushtomaster,leanpreset only).security-events: write, scoped to just thedocker-buildjob, for the SARIF upload — the same grant pattern already used ingithub-action-validator.ymlfor zizmor's scan.fail-build: false, matching the prior Trivy config: this stays informational and doesn't gate merges on findings.TESTING INSTRUCTIONS
action-validator .github/workflows/docker.ymlpasses.zizmor .github/workflows/docker.ymlreports no new findings (only 5 pre-existing, unrelatedself-repositorynits on other steps).pushtomasterwithbuild_preset == 'lean', it won't fire on this PR itself — the way to confirm it after merge is checking that a new Grype-produced analysis shows up under Security → Code scanning for thedocker.yml:docker-buildcategory.ADDITIONAL INFORMATION