[Feature]: hoophq/hoopdev base image carries 1,000+ fixable CVEs; request slimmer agent image and dependency refresh

Is your feature request related to a problem?

Yes. We run hoop.dev in production (gateway + custom agent sidecar built FROM hoophq/hoopdev). Security scans of images derived from hoophq/hoopdev report ~1,100+ active, fixable CVEs, including 22 CRITICAL on our agent image and 5 CRITICAL with known exploits (openssl, curl, go/stdlib, nodejs) that trigger automated alerting. This comes from the upstream hoophq/hoopdev base image, not our thin layer (we only add clickhouse-client). Bumping 1.120.0 → 1.121.1 did not materially improve the profile. Main contributors:

• linux-libc-dev kernel headers alone (~891 Inspector findings) — compile-time artifacts in a runtime image
• Legacy libssl1.1 and old OpenSSL runtime
• Bundled CLIs (kubectl, sqlcmd, mongo-tools, gcloud) with stale Go stdlib
• Node/npm tooling and app/hoop Go deps (kin-openapi, go-git, go-billy) We temporarily suppress ~180 CVE/GHSA IDs in CI, but that is not sustainable for production or compliance.

Describe the solution you'd like

1. Publish hoophq/hoopdev-minimal — production image with only the hoop agent binary, required runtime libs (OpenSSL 3.x, ca-certs, shell), and without linux-libc-dev, libssl1.1, kubectl/sqlcmd/mongo-tools/gcloud, or Node unless explicitly needed. Keep full hoophq/hoopdev for local dev.

2. Multi-stage Dockerfile — build in a builder stage; runtime stage copies only the agent binary and runtime deps. No -dev packages or kernel headers in the published image. Migrate to a current Ubuntu LTS with OpenSSL 3.x.

3. Split optional tools — move bundled CLIs to a separate hoop-tools image/sidecar or document bring-your-own-tools for production. Default Helm/K8s deployments use the minimal agent.

4. Automated rebuild cadence — rebuild and republish on each release, weekly base-OS patches, and Go/Node/tool security advisories. Bump known fixes now: kin-openapi >= v0.144.0, go-git/go-billy. Add a Trivy CRITICAL/HIGH gate in publish CI.

5. SBOM + per-tag manifest — attach SPDX/CycloneDX SBOM and a JSON manifest (base OS, bundled tool versions, Trivy summary) to each GitHub release so downstream users can verify fixes without full rescans.

6. Document custom agent patterns — guide for extending the minimal base safely (which connection types need which binaries, Dockerfile best practices).

First milestone: multi-stage build + base OS refresh on existing hoophq/hoopdev, plus Go module bumps.

Second milestone: ship hoophq/hoopdev-minimal and point production Helm defaults at it.

Describe alternatives you've considered

No response

Priority

High - Critical for my use case

Use Case

We run hoop.dev in production on Kubernetes as our SSO-audited access proxy to ClickHouse and Postgres. The gateway runs hoophq/hoop; our agent sidecar is a thin custom image built FROM hoophq/hoopdev with clickhouse-client added for exec-based DB sessions. Engineers connect via hoop connect — no raw credentials, all sessions audited.

Our use case is narrow: proxy/exec and HTTP proxy for database access. We do not need kubectl, sqlcmd, mongo-tools, gcloud, Node tooling, or kernel dev headers in the production agent pod. But because hoophq/hoopdev ships the full dev toolkit, every custom agent inherits ~1,100+ scannable CVEs, 22 CRITICAL, and automated alerts on exploitable findings — blocking CI, triggering compliance review, and forcing us to maintain 180+ temporary CVE suppressions.

A minimal production agent image (and cleaner full image via multi-stage builds) would benefit us by letting us stay on hoop.dev without fighting scanners and pager fatigue. It would benefit the broader community the same way: anyone running hoop agents as K8s sidecars or building custom FROM hoophq/hoopdev images for production — rather than local dev — gets a sane security posture out of the box. Full hoophq/hoopdev can remain the all-in-one dev experience; hoophq/hoopdev-minimal (or equivalent) becomes the documented production path in Helm and custom-agent docs.

Mockups or Examples

No response

Additional Context

No response

Contribution

• I would be willing to submit a PR to implement this feature

Code of Conduct

• I agree to follow this project's Code of Conduct