build: pin base image digests and clear every fixable image finding

The production images built on mutable tags with --pull, so the same commit
could produce different bases, and neither Dockerfile upgraded its OS packages
even though the local ones did. The published API image carried 56 HIGH and 3
CRITICAL findings, 15 of them with an upstream fix available.

Pin both bases by digest and upgrade OS packages in the production images. That
removes all 3 CRITICAL and 13 of the 15 fixable findings. The remaining two,
msgpack and setuptools, come from a third-party SBOM; neither package is
importable or listed by pip in the built image, which I confirmed rather than
taking the previous report's word for it.

The web image could not be fixed this way: the official 1.28 line pins
nginx=1.28.3-r1 in /etc/apk/world, so apk upgrade leaves five HIGH findings in
place even though Alpine ships 1.28.3-r7. Moving to nginx:alpine (1.31.6)
clears them completely; 1.29-alpine scans worse, at 37 HIGH. Same uid 101 and
the same template entrypoint, and the local images now use the same pinned
bases so the integration suite exercises what ships. Full suite passes on
nginx 1.31.6, including the browser end-to-end.

With both images at zero CRITICAL, the image scan now blocks on CRITICAL and
reports HIGH, instead of reporting everything. PYTHON_BASE_IMAGE and
NGINX_BASE_IMAGE are wired through to the builds so a base can move forward
without editing the repository, which is what PORTAINER.md already promised.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.gitea/workflows/deploy.yml

@@ -146,6 +146,8 @@ jobs:
     timeout-minutes: 45
     env:
       TRIVY_IMAGE: ${{ vars.TRIVY_IMAGE }}
+      PYTHON_BASE_IMAGE: ${{ vars.PYTHON_BASE_IMAGE }}
+      NGINX_BASE_IMAGE: ${{ vars.NGINX_BASE_IMAGE }}
     steps:
       - name: Checkout
         uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
@@ -161,7 +163,12 @@ jobs:
       - name: Build and publish API
         run: |
           image="gitea.blyzer.com.br/blyzer/dtf-api"
-          docker build --pull --file deploy/Dockerfile.api \
+          # The Dockerfiles pin digests themselves; these variables let a base be
+          # moved forward without editing the repository. --pull is intentionally
+          # absent: a digest already names one immutable image.
+          set --
+          [ -n "$PYTHON_BASE_IMAGE" ] && set -- --build-arg PYTHON_BASE_IMAGE="$PYTHON_BASE_IMAGE"
+          docker build --file deploy/Dockerfile.api "$@" \
             --build-arg VCS_REF="${{ gitea.sha }}" \
             --tag "$image:latest" --tag "$image:${{ gitea.sha }}" .
           docker push "$image:latest"
@@ -169,27 +176,39 @@ jobs:
       - name: Build and publish web
         run: |
           image="gitea.blyzer.com.br/blyzer/dtf-web"
-          docker build --pull --file deploy/Dockerfile.web \
+          set --
+          [ -n "$PYTHON_BASE_IMAGE" ] && set -- --build-arg PYTHON_BASE_IMAGE="$PYTHON_BASE_IMAGE"
+          [ -n "$NGINX_BASE_IMAGE" ] && set -- "$@" --build-arg NGINX_BASE_IMAGE="$NGINX_BASE_IMAGE"
+          docker build --file deploy/Dockerfile.web "$@" \
             --build-arg VCS_REF="${{ gitea.sha }}" \
             --tag "$image:latest" --tag "$image:${{ gitea.sha }}" .
           docker push "$image:latest"
           docker push "$image:${{ gitea.sha }}"
-      # Reported, not blocking. The current bases carry HIGH/CRITICAL findings
-      # with no fix available upstream, so gating on them would stop every
-      # deploy without making anything safer. Read the counts each release, and
-      # see ROADMAP 2.6 for pinning digests and triaging what is fixable.
-      - name: Image vulnerability report
+      # CRITICAL blocks, HIGH is reported. Both images carry zero CRITICAL after
+      # the base pinning and OS upgrades, so this gate holds the line already
+      # reached. The remaining HIGH findings have no upstream fix, so failing on
+      # them would stop releases without making anything safer.
+      - name: Image vulnerabilities
         run: |
           image="${TRIVY_IMAGE:-aquasec/trivy:0.58.1}"
+          failed=0
           for target in \
               "gitea.blyzer.com.br/blyzer/dtf-api:${{ gitea.sha }}" \
               "gitea.blyzer.com.br/blyzer/dtf-web:${{ gitea.sha }}"; do
-            echo "--- $target"
+            echo "--- $target (HIGH, reported)"
             docker run --rm -v /var/run/docker.sock:/var/run/docker.sock "$image" \
-              image --scanners vuln --severity HIGH,CRITICAL --no-progress \
-              --format table --exit-code 0 "$target" || \
-              echo "::warning::Could not scan $target"
+              image --scanners vuln --severity HIGH --no-progress \
+              --format table --exit-code 0 "$target" ||
+              echo "::warning::Could not scan $target for HIGH findings"
+            echo "--- $target (CRITICAL, blocking)"
+            docker run --rm -v /var/run/docker.sock:/var/run/docker.sock "$image" \
+              image --scanners vuln --severity CRITICAL --no-progress \
+              --format table --exit-code 1 "$target" || failed=1
           done
+          if [ "$failed" -ne 0 ]; then
+            echo "::error::A CRITICAL vulnerability was found in a published image."
+            exit 1
+          fi
 
       - name: Trigger Portainer redeployment
         env: