Idea — automatically detect platform labels for containers (e.g. language runtime and version)

[strausmann]

Summary

Let Newt derive platform labels for blueprint-managed resources automatically (e.g. platform::php, platform_version::8.4.2) from container/image metadata, marked with origin detected.

Motivation

Label-scoped policies (#3979) are only as good as the labels. During PHP2Shell (CVE-2026-109618 / CVE-2026-109619) the first question I had was "which of my exposed apps run PHP, and which version?" — and I had to answer it by hand, container by container. Labels maintained by people drift; detection would answer this directly.

Proposed Solution

Only an idea for discussion, not a full design:

• Newt already reads Docker labels of containers. It could additionally inspect image metadata: OCI labels, well-known environment variables (PHP_VERSION, NODE_VERSION, PYTHON_VERSION, …), optionally an SBOM if one is attached to the image.
• Detected labels get origin detected (see Scoped labels (`scope::value`) that survive blueprint sync, plus label inheritance from sites #3978), are shown as such, can be overridden manually, and can't be removed by hand while detection still reports them.
• Detection should be opt-in per site.

Alternatives Considered

• Maintaining platform labels manually in each blueprint — works, but drifts with image updates.
• External tooling (SBOM scanners) pushing labels via the API — possible today once Scoped labels (`scope::value`) that survive blueprint sync, plus label inheritance from sites #3978 exists; built-in detection would just make it zero-config.

Additional Context

Detection is inherently fuzzy (minimal images without metadata, multiple runtimes in one image). It's fine if this stays out of scope — #3979 and #3978 are useful without it.

Related: #3979, #3978.

AI disclosure: drafted with the help of an AI assistant (Claude Code); reviewed and edited by me.

[strausmann]

Thinking about this more, I'd like to narrow this request. Pangolin and Newt shouldn't build SBOMs or scan images themselves — that's a moving target and well covered by existing scanners. What's missing is a clean way for an external scanner to keep labels up to date.

Why version labels can't be maintained by hand: during PHP2Shell the interesting labels were exactly the volatile ones (platform_version::…). They change with every image update. Stable labels like platform::php or location::dc-a are fine in blueprints; versions are not — after the first update they're wrong, and a policy based on them hits the wrong resources.

Images without a published SBOM aren't a blocker: tools like Syft, Trivy or Grype generate the SBOM from the image itself (package databases such as apk/dpkg), so it doesn't matter whether the publisher ships one. Some container managers already run image audits on their own.

Proposal — a scanner companion talking to the API:

1. A small companion container runs next to Newt (or as an optional Newt module). For every container Newt exposes, it scans the image (by digest), and pushes the result as labels with origin detected (see Scoped labels (`scope::value`) that survive blueprint sync, plus label inheritance from sites #3978), e.g. platform::php, platform_version::8.4.26 and — even more useful — cve::CVE-2026-109618.
2. With CVE labels, a policy in Label-scoped access policies that take precedence over resource rules (incident kill switch) #3979 can simply say resource:cve = CVE-2026-109618. Nobody has to translate version ranges from an advisory by hand; the scanner's vulnerability database does the matching.
3. When the image changes (new digest after an update or redeploy), the companion rescans and replaces its labels. A patched app loses its CVE label and drops out of the policy automatically.

What Pangolin would need for that (small, and useful for any external tool):

• Newt already reports each container's id, name and image (parseDockerContainers.ts). Exposing the mapping resource ↔ container/image digest via the API would let a companion know which image backs which resource.
• An API call to replace all labels of origin detected on a resource in one go (idempotent), so a scanner never touches blueprint or manual labels and never leaves stale ones behind. Optionally the image digest the labels were derived from, so the UI can show "detected from image sha256:…, scanned at …".

Note that these labels live in Pangolin, not on the container: Docker labels are fixed at container creation and can't be changed on a running container, so the companion never touches the container itself — it only uses Newt's container/image mapping to know which Pangolin resource to label.

That keeps the scanning logic out of Pangolin entirely, and anyone can plug in the scanner they already trust. I'm happy to build such a companion myself if the API part makes sense to you.

AI disclosure: drafted with the help of an AI assistant (Claude Code); reviewed and edited by me.