Skip to content

Track Trivy image CVEs: wait for Debian 13 fixes (79 alerts) #36

Closed as not planned

Description

@cursor

Executive summary

GitHub code scanning currently shows 79 open Trivy alerts (tool=Trivy) against this repo, almost entirely from the optional Docker image (python:3.12-slim + busybox-static + pandas), not from the Python CLI or the host-native deploy/ path.

Severity (Trivy) Count
CRITICAL 1
HIGH 41
MEDIUM 27
LOW 4
UNKNOWN 6
Total 79

Paths: 78× library/vhc-simplifier (container OS/image) · 1× pip METADATA (site-packages).

Ship-risk vs noise

  • Real ship path if operators run Docker: README + docker-compose.yml document docker build / Compose as a first-class runtime. There is no published GHCR/Docker Hub image; operators build locally. The scanned image (vhc-simplifier:trivy-scan in .github/workflows/trivy.yml) is that same Dockerfile. Compose already hardens with read_only, cap_drop: ALL, no-new-privileges.
  • Most CRITICAL/HIGH are scanner debt, not app-reachable: the CLI is Python (vhc_simplifier.py). It does not invoke perl, mount/nsenter, systemd-homed, or BusyBox ash. Debian 13 (trixie) lists no official fixed version for the OS CVEs (<no-dsa> / minor). apt-get upgrade / a rebuild on today’s python:3.12-slim will not clear them.
  • Host-native systemd deploy (deploy/) is unaffected by these container OS packages. Prefer it when Docker image CVE noise is unacceptable.
  • Only clear, safe upgrade found: pip CVE-2026-13346 (MEDIUM, Fixed Version 26.2.0) — see draft PR fix: upgrade Docker image pip to ≥26.2.0 (CVE-2026-13346) #35.

Intentionally not suppressed. No .trivyignore and no Trivy workflow ignore list. Blanket ignores would hide future fixable OS/app findings. Track here until Debian publishes trixie updates, then rebuild.

Live alert API was not readable from this triage token (code-scanning 403; public /security/code-scanning 404). Inventory below is from the maintainer snapshot plus Debian Security Tracker as of 2026-09-12, cross-checked against the last successful scheduled Trivy image job (run 33946666983, 2026-09-05, Debian 13.6, 88 OS packages). Weekly cron is 0 5 * * 6 (next after that run: 2026-09-12 05:00 UTC).


P0 — perl-base CRITICAL + related perl CVEs

Alert CVE Sev Package Installed Debian 13 fixed?
#252 CVE-2026-13221 CRITICAL perl-base 5.40.1-6 empty (sid/forky: 5.42.3-1; trixie <no-dsa> minor)
#253 CVE-2026-57432 HIGH perl-base 5.40.1-6 empty (unstable 5.40.1-8 / sid 5.42.3-1; trixie <no-dsa>)
#254 CVE-2026-57433 HIGH perl-base 5.40.1-6 empty (same; Storable thaw panic)
(same package) additional medium/unknown perl CVEs MED/UNK perl-base empty

What it is: perl-base is a Debian Essential leftover from python:3.12-slim. The app never calls Perl.

Reachability: CVE-2026-13221 is a regex-trie overflow requiring >65535 fixed-string alternation branches. CVE-2026-57432 is pack/unpack OOB read from an untrusted template. CVE-2026-57433 is Storable deserialization of a crafted blob. None of those are on the VHC CSV/JSON → artifact path.

Do not: pin an unofficial/sid perl, or invent a .trivyignore without a Debian fix.

Do: wait for a trixie DSA / 5.40.1-6+deb13u* (or a newer official slim tag that includes it), then rebuild.


P1 — util-linux 4-CVE cluster (36 HIGH alerts)

Four CVEs × the util-linux binary package family pulled by python:3.12-slim:

util-linux, mount, login, libuuid1, libsmartcols1, libmount1, liblastlog2-2, libblkid1, bsdutils → 36 alerts.

CVE Theme Debian 13 fixed?
CVE-2026-76642 libmount post-mount hooks after helper failure → local LPE (user fstab + X-mount.*) empty (sid 2.42.3-1; trixie <no-dsa>)
CVE-2026-78408 nsenter --join-cgroup leaks root cgroup.procs FD empty (sid 2.42.3-1; trixie <no-dsa>)
CVE-2026-78409 same util-linux family (Trivy HIGH, Fixed Version empty) empty
CVE-2026-78410 same util-linux family (Trivy HIGH, Fixed Version empty) empty

Reachability: requires local unprivileged access plus mount/nsenter features the CLI never uses. Compose drops all capabilities and uses a read-only rootfs. Not the VHC parser attack surface.

Do: wait for Debian 13 util-linux ≥ 2.42.3 (or a backported deb13u*), rebuild slim.


P2 — other HIGHs

Package CVE Why it is in the image Reachability Debian 13 fixed?
busybox-static CVE-2026-38754 Installed on purpose for optional cron (docker-entrypoint.sh → busybox crond) Heap overflow is in ash ifsbreakup(), not crond. Cron argv is already trusted operator input (CRON_SCHEDULE). Do not remove busybox-static without replacing cron or documenting that CRON_SCHEDULE stops working. empty (sid 1:1.38.0-3; trixie <no-dsa>)
libsystemd0 / libudev1 CVE-2026-16742 Shared libs from the slim base (not systemd-homed) Bug is systemd-homed local LPE via group addition. This image does not run homed. empty on trixie (forky 261.2-1; trixie <no-dsa>)

P3 — mediums / lows / unknown (including the one fixable finding)

Item Notes
pip CVE-2026-13346 MEDIUM, Fixed Version 26.2.0 Path traversal from a malicious package index (pip download --only-binary is the material case). CLI does not call pip at runtime. Clear fix: upgrade image pip. Draft PR: #35
Remaining ~26 MED + 4 LOW + 6 UNKNOWN Additional perl/util-linux/base-image CVEs with no trixie fix, plus scanner “unknown” severity. Same wait-and-rebuild strategy. Do not blanket-ignore.

Recommended remediations

  1. Merge the pip pin (fix: upgrade Docker image pip to ≥26.2.0 (CVE-2026-13346) #35) so the only fix-available finding is closed on the next image scan.
  2. Wait for Debian 13 (trixie) security updates, then rebuild on a fresher python:3.12-slim (prefer digest pin after the rebuild is known-good). Do not apt-get install sid perl/util-linux/busybox into this image.
  3. Optional later hardening (separate change, not a CVE suppress): distroless/chainguard-style Python image, or drop busybox-static if cron is retired; multi-stage so pip is not left in the runtime layer.
  4. Lower-exposure path today: host-native deploy/ systemd unit (no container OS packages). Still upgrade that venv’s pip (python -m pip install --upgrade "pip>=26.2.0") as hygiene — not a Trivy image alert.
  5. When to suppress vs upgrade
    • Upgrade when Trivy/Debian lists a Fixed Version that is in trixie (or a trustworthy official slim rebuild).
    • Track (this issue) when Fixed Version is empty / <no-dsa>.
    • Suppress in .trivyignore only with a per-CVE comment (unused + no fix + not reachable) and a link back here. Prefer leaving alerts open. Never a blanket ignore.

When this issue can close

  • pip alert gone after fix: upgrade Docker image pip to ≥26.2.0 (CVE-2026-13346) #35 + next trivy-image upload, and
  • Debian 13 has fixed perl + util-linux + busybox + systemd CVEs (or we have rebuilt onto a base that has), or
  • we have deliberately moved the documented Docker runtime off python:3.12-slim to a distroless image and re-scanned.

Key alert / tracker links

Activity

  1. cgfixit commented on Sep 12, 2026

    @cgfixit
    Owner

    Status update (pip half done; issue stays open)

    The original close box required both (1) the pip upgrade and (2) Debian 13 fixes for perl/util-linux/busybox/systemd, or a distroless move + re-scan. Only (1) is done.

    Done

    • #35 merged 2026-09-12 (f2aa05e). Dockerfile on main pins pip>=26.2.0.
    • Code scanning alert #358 (CVE-2026-13346) is fixed (2026-09-12 04:27 UTC, next Trivy image upload after the pin).
    • Latest image scan on current main (8d8675c): Trivy run 34696590820 SUCCESS (filesystem + container).

    Not done — leave this issue open

    • 86 Trivy alerts still open on main (1 critical, 43 high, 28 medium, 4 low, 10 unset). Those are still the Debian 13 <no-dsa> OS leftovers (perl-base, util-linux cluster, busybox ash, systemd-homed, …), not the VHC parser path.
    • Do not sid-pin those packages and do not add a blanket .trivyignore.

    Residual (not a close condition, not actioned here): image still reports setuptools CVE-2026-59890 MEDIUM (installed 70.3.0, fixed 83.0.0) — separate from the pyproject SPDX setuptools>=77 build-backend bump in #40.

    Close when Debian 13 publishes trixie updates and we rebuild official slim, or when the documented Docker runtime leaves python:3.12-slim and is re-scanned.

  2. cgfixit commented on Sep 12, 2026

    @cgfixit
    Owner

    fake news unless I used this in a container

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions