The reviewed image is a compatibility candidate for isolated Catalog integration testing. It is not a general-purpose Kubernetes distribution. The image is highly privileged and must not be tested on a workstation or production host.

• Build only in the manually dispatched GitHub security gate or an isolated environment with disposable state.
• Verify every downloaded artifact by immutable version and checksum before publication.
• Block publication when the exact candidate contains an applicable HIGH or CRITICAL vulnerability or a detected secret. A scanner finding may be resolved only by a source-linked, machine-readable VEX statement with reproducible evidence.
• Do not commit API keys, certificates, kubeconfigs, bootstrap material, private registries, endpoints, or live metadata.
• Quote credentials and URLs, fail closed on HTTP errors, and keep certificate archives outside logs.
• Treat host mounts, cgroups, Docker socket access, kernel modules, firewall rules, and control-plane credentials as privileged interfaces.
• Review the exact final image filesystem, configuration, layers, SBOM, and third-party legal files before distribution.
• Run the Helm 2 compatibility server only as the dedicated UID and service account. Its compatibility role intentionally omits privilege-binding, escalation, impersonation, bulk deletion, certificate approval, and non-resource URL verbs. Charts can still create privileged workloads, so restrict Catalog authors and plan a separate Helm 3 migration.
• Never use replace --force or helm init --upgrade for the Tiller transition. Create and checksum an offline release-data bundle outside the source tree, use a rolling Deployment update, verify canonical record content, and roll back the Deployment revision on failure.
• Treat every scripts/tiller-release-backup bundle as sensitive cluster data: keep its directory at mode 0700, files at mode 0600, store it offline with restricted access, and never commit or upload it. The tool deliberately provides no automatic restore operation.
• Keep the Azure CLI Python dependency set internally consistent. Azure CLI core 2.89.0 requires MSAL 1.36.0, and the supported MSAL and pyOpenSSL set requires cryptography <49. The image therefore installs checksum-verified cryptography 48.0.1 and pyOpenSSL 26.2.0 wheels without invoking a network package resolver. Exact distribution checks, pip check, reviewed vulnerable-API reachability checks, and the Azure command paths used by this package are release-blocking. Move to the fixed cryptography series only when a published Azure CLI dependency set supports it.

The runtime assessment is stored in security/openvex.json. The build-environment assessment is generated deterministically from security/dapper-linux-libc-dev-reviewed-cves.txt and the exact Ubuntu package version in package/ubuntu-apt.lock.

• CVE-2026-69249 affects the packaged cryptography series. The image does not accept or validate attacker-supplied certificate chains, and the exact-filesystem gate finds no caller of cryptography.x509.verification, PolicyBuilder, or the client/server verifier builders outside cryptography itself.
• CVE-2026-69247 affects PKCS#7 EnvelopedData decryption APIs. The image does not expose a PKCS#7 decryption service, and the same gate finds no external call to pkcs7_decrypt_der, pkcs7_decrypt_pem, or pkcs7_decrypt_smime.
• Ubuntu linux-libc-dev 7.0.0-29.29 is an exact, build-only dependency of the C toolchain. Its 46 reviewed HIGH/CRITICAL scanner records describe executable Linux kernel subsystems, while this package contains only development headers under /usr/include and documentation under /usr/share/doc/linux-libc-dev. The Dapper build verifies that path boundary, rejects executable header files, records the complete package path inventory, and contains no Ubuntu kernel binary or module. The generated OpenVEX document applies only to the exact Ubuntu package PURL and the explicitly reviewed CVE list.
• Every run retains both unfiltered and applicable scans and separately blocks applicable HIGH/CRITICAL findings after OpenVEX. It also requires every build-environment VEX entry to be present in the raw scan, so stale or newly reported findings stop the gate for review. If an affected call path appears, the package contents change, or a compatible fixed dependency set becomes available, replace the assessment instead of carrying it forward.

Report suspected vulnerabilities through this repository's private security advisory channel. Do not include live credentials, certificates, or cluster data in a public issue.