ci: bump docker/build-push-action to v7 and clear .trivyignore (#59)

* ci: bump docker/build-push-action to v7 and clear .trivyignore

- docker/build-push-action@v6 -> @v7 across integration-tests.yml and
  security.yml. v7 runs on Node.js 24 by default, clearing the GitHub
  Actions deprecation warning for Node.js 20.

- Drop all six CVE suppressions from .trivyignore after verifying locally
  against a fresh build of lambda/helm-installer that none of them are
  reported by Trivy (DB refreshed 2026-05-13) at any severity:
  CVE-2026-4046 (glibc iconv), CVE-2026-33811/33814/39820/39836/42499
  (Go stdlib). The Lambda Python 3.14 base image now ships patched glibc
  and Go 1.26.3 aws-lambda-rie.

* ci: restore .trivyignore suppressions

CI's pinned Trivy 0.70.0 (mirror.gcr.io/aquasec/trivy-db:2) still flags
all six CVEs as HIGH against the helm-installer image:

- CVE-2026-4046: base image still ships glibc 2.34-231.amzn2023.0.3
  (fix .0.4 hasn't flowed into public.ecr.aws/lambda/python:3.14 yet).
- CVE-2026-33811/33814/39820/39836/42499: aws-lambda-rie (Go 1.26.2),
  helm v4.1.4 (Go 1.25.9), kubectl v1.35.4 (Go 1.25.9) all still
  pre-date the Go 1.25.10 / 1.26.3 fixes shipped on 2026-05-07.

Local scan with Trivy 0.69.3 + ghcr.io DB reported zero findings for
these CVEs, which led to the earlier drop; the DB mismatch with CI was
the source of the false negative. Restoring the suppressions with
refreshed justifications and a new note in the header rules to always
verify against the pinned CI Trivy version before editing.

Author: Jmevorach

.github/workflows/integration-tests.yml

@@ -276,7 +276,7 @@ jobs:
         # reused by this job, integration:kind:cluster-e2e, and
         # security:trivy:container-scan — all three build the same image
         # from the same Dockerfile + context.
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@v7
         with:
           context: .
           file: dockerfiles/health-monitor-dockerfile
@@ -301,7 +301,7 @@ jobs:
       - uses: actions/checkout@v6
       - uses: docker/setup-buildx-action@v4
       - name: Build image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@v7
         with:
           context: .
           file: dockerfiles/manifest-processor-dockerfile
@@ -326,7 +326,7 @@ jobs:
       - uses: actions/checkout@v6
       - uses: docker/setup-buildx-action@v4
       - name: Build image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@v7
         with:
           context: .
           file: dockerfiles/inference-monitor-dockerfile
@@ -352,7 +352,7 @@ jobs:
       - uses: actions/checkout@v6
       - uses: docker/setup-buildx-action@v4
       - name: Build image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@v7
         with:
           context: .
           file: dockerfiles/queue-processor-dockerfile
@@ -379,7 +379,7 @@ jobs:
       - uses: actions/checkout@v6
       - uses: docker/setup-buildx-action@v4
       - name: Build image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@v7
         with:
           context: lambda/helm-installer
           file: lambda/helm-installer/Dockerfile
@@ -581,7 +581,7 @@ jobs:
         # Shares the same GHA cache scope as integration:docker:health-monitor
         # and security:trivy:container-scan. All three build the same image
         # from the same Dockerfile + context, so layer reuse is automatic.
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@v7
         with:
           context: .
           file: dockerfiles/health-monitor-dockerfile
@@ -590,7 +590,7 @@ jobs:
           cache-from: type=gha,scope=health-monitor
           cache-to: type=gha,mode=max,scope=health-monitor
       - name: Build manifest-processor image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@v7
         with:
           context: .
           file: dockerfiles/manifest-processor-dockerfile
@@ -599,7 +599,7 @@ jobs:
           cache-from: type=gha,scope=manifest-processor
           cache-to: type=gha,mode=max,scope=manifest-processor
       - name: Build inference-monitor image
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@v7
         with:
           context: .
           file: dockerfiles/inference-monitor-dockerfile

.github/workflows/security.yml

@@ -183,7 +183,7 @@ jobs:
         # is used by the integration:docker:* jobs and the kind E2E build,
         # so each image's layers are built exactly once per commit and
         # reused everywhere.
-        uses: docker/build-push-action@v6
+        uses: docker/build-push-action@v7
         with:
           context: ${{ matrix.context || '.' }}
           file: ${{ matrix.dockerfile }}

.trivyignore

@@ -9,45 +9,51 @@
 #      or extend the date with a new justification if the fix still isn't
 #      available. Never extend without re-checking upstream.
 #   4. Keep the file short. A growing ignorefile is a smell.
+#   5. Verify against the pinned CI Trivy (TRIVY_VERSION in security.yml /
+#      cve-scan.yml) and its DB source — local `brew install trivy` uses
+#      the ghcr.io DB which can classify severities differently from the
+#      CI's mirror.gcr.io/aquasec/trivy-db:2.
 #
 # Format:
 #   CVE-XXXX-XXXXX exp:YYYY-MM-DD
 # =============================================================================
 
 # CVE-2026-4046 — glibc iconv() DoS in AL2023 base image (lambda/helm-installer).
-# Trivy's vuln DB lists glibc-2.34-231.amzn2023.0.4 as the fix, but as of
-# 2026-05-01 the fixed RPM is NOT yet available in the AL2023 dnf repos —
-# `dnf upgrade glibc` inside the base image (public.ecr.aws/lambda/python:3.14)
-# reports "Nothing to do". The AL2023 advisory (ALAS2023-2026-1622, released
-# 2026-04-30) still lists the package status as "PendingFix", confirming the
-# RPM has not yet been published. We don't add `dnf upgrade` to the Dockerfile
-# because it would make builds non-reproducible. The only remaining option is
-# to wait for AWS to publish a rebuilt Lambda Python base image that includes
-# the patched glibc, then rebuild and drop this entry.
+# ALAS2023-2026-1622 (published 2026-04-30) lists fixed RPMs
+# (glibc-2.34-231.amzn2023.0.4) in AL2023 repo snapshot 2023.11.20260427, but
+# public.ecr.aws/lambda/python:3.14 still ships glibc-2.34-231.amzn2023.0.3
+# confirmed by CI scan on 2026-05-13. The image is pinned to a repo snapshot
+# older than 2026-04-27, so `dnf upgrade glibc` in the Dockerfile would be the
+# only way to pull the fix — and that would make builds non-reproducible.
+# Wait for AWS to publish a rebuilt Lambda Python base image.
 #
-# CVE record:     https://www.cve.org/CVERecord?id=CVE-2026-4046
-# AL2023 ALAS:    https://alas.aws.amazon.com/AL2023/ALAS2023-2026-1622.html
-# ALAS JSON feed: https://alas.aws.amazon.com/cve/json/v1/CVE-2026-4046.json
-# Upstream base image: public.ecr.aws/lambda/python:3.14
-CVE-2026-4046 exp:2026-05-22
+# CVE record:  https://www.cve.org/CVERecord?id=CVE-2026-4046
+# AL2023 ALAS: https://alas.aws.amazon.com/AL2023/ALAS2023-2026-1622.html
+# Base image:  public.ecr.aws/lambda/python:3.14
+CVE-2026-4046 exp:2026-06-13
 
 # CVE-2026-33811, CVE-2026-33814, CVE-2026-39820, CVE-2026-39836,
-# CVE-2026-42499 — Go stdlib vulnerabilities (net/http, crypto/tls, os/exec)
+# CVE-2026-42499 — Go stdlib vulnerabilities (net, net/http, net/mail)
 # affecting three binaries in the helm-installer Lambda container:
 #   - aws-lambda-rie (Go 1.26.2, bundled in public.ecr.aws/lambda/python:3.14)
-#   - helm v4.1.4 (Go 1.25.9, latest release as of 2026-05-11)
-#   - kubectl v1.35.4 (Go 1.25.9, latest stable-1.35 as of 2026-05-11)
+#   - helm v4.1.4 (Go 1.25.9, latest release as of 2026-05-13)
+#   - kubectl v1.35.4 pinned in Dockerfile (Go 1.25.9; v1.35.5 released
+#     2026-05-12 is still go1.25.9 per build-image/cross/VERSION)
 #
-# Fix requires Go ≥1.25.10 or ≥1.26.3 in the compiled binaries. No upstream
-# releases are available yet:
-#   - Helm: v4.1.4 is latest (https://github.com/helm/helm/releases)
-#   - kubectl: v1.35.4 is latest stable-1.35 (https://dl.k8s.io/release/stable-1.35.txt)
-#   - aws-lambda-rie: AWS-controlled, no user-serviceable update path
+# Fix requires Go ≥1.25.10 or ≥1.26.3 in the compiled binaries. Go released
+# those versions on 2026-05-07, but no downstream rebuild has shipped yet:
+#   - Helm: v4.1.4 is still latest (https://github.com/helm/helm/releases);
+#     v4.2.0-rc.1 exists but we pin to stable.
+#   - kubectl: v1.35.5 (2026-05-12) still ships Go 1.25.9
+#     (https://raw.githubusercontent.com/kubernetes/kubernetes/v1.35.5/build/build-image/cross/VERSION)
+#   - aws-lambda-rie: latest is v1.35 (2026-03-30) still Go 1.26.2;
+#     AWS-controlled, no user-serviceable update path.
 #
-# These CVEs pre-date this PR and would fail the scan on main today.
-# Re-evaluate when Helm v4.1.5+ or kubectl v1.35.5+ ships.
-CVE-2026-33811 exp:2026-06-11
-CVE-2026-33814 exp:2026-06-11
-CVE-2026-39820 exp:2026-06-11
-CVE-2026-39836 exp:2026-06-11
-CVE-2026-42499 exp:2026-06-11
+# Re-evaluate when Helm ships v4.1.5+ with Go 1.25.10, when kubectl ships
+# v1.35.6+ rebuilt with Go 1.25.10, and when AWS rebuilds aws-lambda-rie.
+# Go release: https://groups.google.com/g/golang-announce/c/qcCIEXso47M
+CVE-2026-33811 exp:2026-06-13
+CVE-2026-33814 exp:2026-06-13
+CVE-2026-39820 exp:2026-06-13
+CVE-2026-39836 exp:2026-06-13
+CVE-2026-42499 exp:2026-06-13