Apply Debian's security patches in the cell's image

[flavorjones]

The image scan and SBOM job failed on master and on every open PR. Trivy reported CVE-2026-14456 in libssl3t64 as a fixable High, and no rebuild of this repository could clear it: ruby:3.4-slim ships 3.5.6-1~deb13u2 while the fix 3.5.7-1~deb13u2 is already in trixie-security, so --pull in bin/example-image cannot reach it until docker-library/ruby rebuilds the tag. The gate stayed red on work that had nothing to do with it, which is the outcome .github/workflows/ci.yml says it does not want.

Run apt-get upgrade in the installed Dockerfile after the FROM, so the image's patch level is its own rather than upstream's release cadence. That stops the class rather than this advisory: the next one to land ahead of a tag rebuild would have failed the same way. Waiting for the base rebuild leaves every unrelated PR red until upstream ships and recurs on the next advisory, and a .trivyignore entry, defensible on its own since a cell runs network: none and is not a QUIC server, works against the reason ignore-unfixed is in the workflow: only a vulnerability a rebuild can fix is supposed to block. Pinning the upgrade to openssl alone is narrower and worse, because the next CVE is in a different package.

Before and after, with the flags CI passes (--severity HIGH,CRITICAL --ignore-unfixed --exit-code 1) against images bin/example-image built:

before: Total: 3 (HIGH: 3, CRITICAL: 0), exit 1
  libssl3t64, openssl, openssl-provider-legacy
  CVE-2026-14456  HIGH  fixed  3.5.6-1~deb13u2 -> 3.5.7-1~deb13u2

after:  no OS vulnerability section, exit 0
  ii  libssl3t64:amd64         3.5.7-1~deb13u2
  ii  openssl                  3.5.7-1~deb13u2
  ii  openssl-provider-legacy  3.5.7-1~deb13u2

hotcell-client/test/install_test.rb holds the line, next to the OMP_NUM_THREADS guard from e5f8596 and for the same reason: the failure only appears in a built image, so the scaffold's own text is what a test can hold. The upgrade sits above the chmod a-s sweep, so the setuid assertion in the same job still finds nothing.

One bound on the claim: the upgrade layer caches on the base image's digest, so a local rebuild the day after a fresh advisory reuses it and can be a patch behind until --no-cache. CI builds on a runner with no cache, so the gate itself is honest.

An upgrade leaves an existing application's Dockerfile alone, so a cell installed before this needs the line added by hand and the image rebuilt. CHANGELOG.md says so.

ref: #46

[Fix #46]

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Applies current Debian security updates when building newly installed HotCell images, preventing fixable vulnerabilities in stale upstream base tags from failing CI.

Changes:

• Adds an apt-get upgrade layer with package-list cleanup.
• Tests the generated Dockerfile for the upgrade command.
• Documents the behavior and migration step for existing installations.

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
hotcell-client/lib/hot_cell/install/Dockerfile.tt	Applies Debian package updates during image builds.
hotcell-client/test/install_test.rb	Verifies the installed Dockerfile includes the upgrade.
CHANGELOG.md	Documents the security update behavior and existing-installation migration.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.