fix: [#428] Docker vulnerability remediation pass 1 (all 8 images)

[josecelano]

Summary

This PR implements Docker vulnerability remediation pass 1 for all 8 images tracked in issue #428. Each image was scanned with Trivy, remediation was applied where possible, results were verified, and follow-up issues were created for remaining unresolved CVEs.

Closes #428

Changes by Image

1. torrust/tracker-deployer (trixie) — partial remediation

• Removed gnupg from runtime layer to reduce attack surface
• After: 44 HIGH, 1 CRITICAL (was 49 HIGH)
• Follow-up: Investigate unresolved deployer CVEs after remediation pass 1 #429

2. torrust/tracker-backup (trixie) — remediation no change

• Added apt-get upgrade -y to base layer
• After: 6 HIGH, 0 CRITICAL (no change — upstream packages not yet patched)
• Follow-up: Investigate unresolved backup image CVEs after remediation pass 1 #431

3. torrust/tracker-ssh-server (Alpine 3.23.3) — fully remediated ✅

• Added apk upgrade --no-cache to base layer
• Fixed malformed entrypoint script (echo → printf for multi-line in Alpine)
• After: 0 HIGH, 0 CRITICAL

4. torrust/tracker-provisioned-instance (Ubuntu 24.04) — fully remediated ✅

• Added --no-install-recommends + apt-get upgrade -y to base layer
• After: 0 HIGH, 0 CRITICAL

5. caddy (3rd-party) — partial remediation

• Upgraded tag 2.10 → 2.10.2 in docker-compose.yml.tera and security scan CI workflow
• After: 14 HIGH, 4 CRITICAL (was 18 HIGH, 6 CRITICAL)
• Follow-up: Investigate unresolved Caddy CVEs after upgrade to 2.10.2 #432

6. prom/prometheus (3rd-party) — partial remediation

• Upgraded default image tag v3.5.0 → v3.5.1 in src/domain/prometheus/config.rs
• After: 6 HIGH, 4 CRITICAL (was 16 HIGH, 4 CRITICAL)
• Follow-up: Investigate unresolved Prometheus CVEs after upgrade to v3.5.1 #433

7. grafana/grafana (3rd-party) — partial remediation

• Upgraded default image tag 12.3.1 → 12.4.2 in src/domain/grafana/config.rs
• After: 4 HIGH, 0 CRITICAL (was 18 HIGH, 6 CRITICAL — CRITICAL fully cleared)
• Follow-up: Investigate unresolved Grafana CVEs after upgrade to 12.4.2 #434

8. mysql (3rd-party) — monitored, no safe upgrade

• mysql:8.4 (floating tag resolves to 8.4.8) = 7 HIGH, 1 CRITICAL
• All pinned minor tags (8.4.1–9.1) have 98–100 HIGH — floating tag is already optimal
• Runtime validated: mysql:8.4 → Ver 8.4.8
• Follow-up: Investigate unresolved MySQL helper-component CVEs in mysql:8.4 #435

Documentation Updates

• docs/security/docker/scans/ — added remediation pass 1 sections to all 8 scan files
• docs/security/docker/scans/README.md — updated global summary table
• docs/issues/428-docker-vulnerability-analysis-apr8-2026.md — all checklists and acceptance criteria complete

Follow-up Issues Created

Issue	Image	Remaining
#429	deployer	44 HIGH, 1 CRITICAL
#431	backup	6 HIGH, 0 CRITICAL
#432	caddy	14 HIGH, 4 CRITICAL
#433	prometheus	6 HIGH, 4 CRITICAL
#434	grafana	4 HIGH, 0 CRITICAL
#435	mysql	7 HIGH, 1 CRITICAL

[josecelano]

ACK 7a44e51

[josecelano]

📋 For Existing Deployments: How to Apply Docker Image Remediation

If you've already deployed the tracker using a previous version of the deployer (before this PR), you'll need to manually update your Docker images to benefit from these vulnerability fixes.

Docker Images to Update

Service	Previous Tag	New Tag	Vulnerability Impact
prom/prometheus	v3.5.0	v3.5.1	10 CVEs fixed (16 HIGH → 6 HIGH)
grafana/grafana	12.3.1	12.4.2	14 CVEs fixed (18 HIGH, 6 CRITICAL → 4 HIGH, 0 CRITICAL)
caddy	2.10 (or untagged)	2.10.2	4 CVEs fixed (18 HIGH, 6 CRITICAL → 14 HIGH, 4 CRITICAL)

All other services are already updated in this version of the deployer.

Update Steps

1. Update docker-compose.yml in your deployment

   cd /opt/torrust
   nano docker-compose.yml  # or your preferred editor

   Find and update these lines:

   # Before
   prometheus:
     image: prom/prometheus:v3.5.0
   
   grafana:
     image: grafana/grafana:12.3.1
   
   caddy:
     image: caddy:2.10
   
   # After
   prometheus:
     image: prom/prometheus:v3.5.1
   
   grafana:
     image: grafana/grafana:12.4.2
   
   caddy:
     image: caddy:2.10.2

2. Pull the new images

   docker compose pull prometheus grafana caddy

3. Recreate containers with new images

   docker compose up -d prometheus grafana caddy

4. Verify services are running

   docker compose ps
   docker compose logs prometheus -n 50  # Check for any startup issues

Verification

After updating, you can verify the new image tags are running:

docker images | grep -E "prom/prometheus|grafana/grafana|caddy"

Expected output (or similar):

prom/prometheus                     v3.5.1    ...
grafana/grafana                     12.4.2    ...
caddy                               2.10.2    ...

Rollback (if needed)

If you experience issues, you can quickly rollback by reverting the docker-compose.yml changes and running:

docker compose up -d prometheus grafana caddy

---

What About Future Deployments?

Any new deployments created with this version of the deployer (v0.1.0+) will automatically use the updated image versions. The deployer pins these versions in the code:

• src/domain/prometheus/config.rs — v3.5.1
• src/domain/grafana/config.rs — 12.4.2
• templates/docker-compose/docker-compose.yml.tera — caddy:2.10.2

---

Related: See issue #437 for tracking remaining unresolved CVEs and future security improvements.

[josecelano]

Follow-up on the Trivy: 5 configurations not found warning:

Root cause identified in workflow logs: third-party SARIF uploads are failing with HTTP 422 because the custom gh api /code-scanning/sarifs call sends category, which is now rejected (Invalid input: "category" is not a permitted key).

This warning is therefore a code-scanning upload/configuration issue, not a regression in the Docker remediation work in this PR.

I opened a dedicated fix issue: #437.

Given all required CI checks are green and this warning is neutral, PR #436 can be merged safely, then #437 can fix the SARIF upload path in a focused follow-up.