feat(supply-chain): build, attest, and activate the patch-validator image

[seonghobae]

Problem

Noema's exact-source patch-quarantine library has now been cleanly rebuilt after the protected nanoid remediation, but the dedicated patch-validator image remains on a stale historical stack. Until the image is rebuilt on the protected exact-source successor, published, signed, scanned, attested and activated with independently verifiable evidence, buyers cannot verify that the runtime image used for validation is reproducible from reviewed source or that it preserves the intended credential boundary.

Current protected main: c85d710804139c0697d7ef8fa47d02b1389e6d84.

Current patch-quarantine source owner: PR #93, exact head fe3074a188739705f89ff67b46712ac9d228081d, direct on protected main. Fresh application CI 31375580944, reviewer-ci 31375580959 and central Security Scan 31375580983 are terminal-success; formal reviews remain 0 and live #27/#29 governance still blocks protected merge.

Historical #65 is closed unmerged. PR #67 contains unique validator-image work but remains based on the old #65 lineage and has moved independently; old #65/#67 checks/reviews never transfer to a future clean successor.

The delivery lane must also keep artifact license metadata subordinate to owner/legal authority. Historical #67 work exposed that an OCI org.opencontainers.image.licenses="LicenseRef-Proprietary" label could silently invent a legal posture while Noema has no approved outbound-rights declaration. Image publication must fail closed when release/container rights metadata disagrees with—or attempts to substitute for—the repository/package/owner-legal licensing decision tracked by issue #5 and the acquisition-integrity line #69.

Required architecture

• Keep image build, image verification, untrusted patch execution, model judgement, review publication, merge authority, release authority, deployment authority, and owner/legal licensing authority as separate stages.
• Never expose GitHub write credentials, reviewer/model keys, NVIDIA_NIM_API_KEY, Cloudflare credentials, OIDC publication tokens, signing credentials, or the Docker socket to untrusted patch execution.
• Preserve exact-head binding, stale-head refusal, immutable workflow-source provenance, bounded evidence collection, and separation among checks, statuses, formal reviews, scanner evidence, model judgement and merge/release authority.
• Do not create .github/workflows/repair-*, self-modifying Actions, branch-patching workflows, or workflows with contents: write that patch their own branch.
• Never infer an outbound source/artifact license from repository visibility, private: true, SBOM/scanner classification or an invented LicenseRef-* value.

Dependency order

#93 protected integration
→ rebuild only #67's unique validator-image delta on the then-current protected lineage
→ fresh exact-head application/reviewer/eligible Security Scan/image evidence
→ protected-main local-image operational acceptance
→ publication/signature/attestation/digest-lock activation

Do not restack #67 while #93 is unintegrated or while another writer is moving #67. Do not copy #65 package/history or transfer predecessor evidence.

Acceptance criteria

Protected exact-source prerequisite

• Integrate fix(security): update transitive nanoid for CVE-2026-67213 #76 nanoid remediation on protected main.
• Rebuild feat(sandbox): add quarantined patch validation #65's unique exact-source patch-quarantine work on current protected main as feat(sandbox): restack exact patch quarantine after nanoid #93.
• Acquire fresh feat(sandbox): restack exact patch quarantine after nanoid #93 application CI, reviewer-ci and central Security Scan terminal-success evidence.
• Satisfy chore(governance): protect main and enforce release checks #27/chore(operations): provision and activate hourly maintainer App #29 live governance and qualifying independent formal-review requirements on unchanged feat(sandbox): restack exact patch quarantine after nanoid #93.
• Merge feat(sandbox): restack exact patch quarantine after nanoid #93 under protected policy and run exact-source patch-quarantine operational acceptance from main.

Clean validator-image successor

• After feat(sandbox): restack exact patch quarantine after nanoid #93 protected integration, identify feat(sandbox): build and verify patch-validator image #67's unique image-only delta by exact comparison and rebuild only that delta from current protected main.
• Preserve the reviewed closed node_patch_verify_v1 image-owned command profile; no caller-provided shell command.
• Use a reviewed minimal numeric-non-root image with explicit entrypoint and no shell/package manager unless technically required and justified.
• Pin and authenticate build inputs and static runtime identity; require the JavaScript/Unicode runtime capabilities the validator actually needs.
• Document supported architectures, UID/GID, filesystem, locale/timezone and resource assumptions.
• Acquire fresh application CI, reviewer-ci, eligible central Security Scan and image-workflow evidence on the clean exact head; old feat(sandbox): build and verify patch-validator image #67 evidence is historical only.

Supply-chain evidence

• Generate a CycloneDX or SPDX SBOM for the exact final image.
• Scan the exact image and fail on MEDIUM/HIGH/CRITICAL findings unless a time-bounded independently reviewed exception names the exact digest/advisory.
• Bind exact embedded runtime/native-component identities and vulnerability-database snapshot to the image digest.
• Sign the immutable image digest using a verified keyless or repository-controlled identity.
• Generate provenance bound to repository, source commit, workflow path/ref/digest, builder identity, runner environment, image digest and build parameters.
• Verify signature, SBOM, provenance, source repository, signer workflow, Actions OIDC issuer and runner policy before any reviewer consumes the image.
• Retain bounded machine-readable build/verification receipts with explicit schema versions and SHA-256 digests.

Licensing / third-party rights evidence

• Do not emit org.opencontainers.image.licenses or equivalent artifact license metadata while outbound rights remain unresolved, unless an authorized owner/legal record explicitly requires a truthful bounded declaration.
• If owner/legal later chooses an SPDX posture, require any OCI license annotation to match that approved expression exactly; custom/unlicensed decisions may not be replaced by another OCI claim.
• Bind exact-release artifact-rights metadata to repository, SemVer tag, full commit, immutable image digest, SBOM, dependency-license inventory, NOTICE/attribution and provenance.
• Apply the fix(acquisition): authenticate data-room manifest evidence #69-style acquisition consistency gate before registry publication/activation so artifact metadata cannot broaden root/package/owner-legal rights.
• Preserve third-party attribution/NOTICE and dependency-license evidence; vulnerability success never substitutes for license compatibility or transfer rights.

Runtime security verification

• Run a real no-network smoke test against the exact digest-pinned image.
• Verify non-root, read-only rootfs, dropped capabilities, no-new-privileges, seccomp, isolated IPC, bounded PID/CPU/memory/swap/descriptors/process/core/file-size/tmpfs/wall-time and no Docker socket.
• Keep source/patch inputs read-only and do not expose a host-writable final evidence path to untrusted execution; trusted host synthesizes retained evidence only after authenticated completion.
• Prove GitHub/model/NVIDIA NIM/Cloudflare/OIDC/signing/publication/release/deployment credentials are absent from container env/filesystem/arguments/mounts.
• Add adversarial tests for oversized output, network attempt, process exhaustion, special files, mount injection, forged/result-replacement attempts, timeout/cleanup failure and unexpected exits.

Reviewer integration

• Activate the image only behind a configuration gate that defaults disabled until exact verification evidence passes.
• Bind immutable image digest to repository/base/head/patch SHA-256/profile/workflow/check/result receipt.
• Treat validator output as evidence only; it cannot approve a PR, satisfy independent review, authorize merge/release or choose licensing posture.
• Refuse stale head, missing/pending required evidence, malformed receipt, pagination truncation, unknown producers, unexpected skipped jobs and mismatched workflow source.
• Preserve standalone Noema operation and modular integration with .github, naruon and other CWL services through explicit versioned boundaries.

Quality / documentation

• Maintain beginner-readable public docs and exact 100% owned production statement/branch coverage plus exposed function/line metrics.
• Update canonical operations, security, threat model, deployment, incident/recovery, keyless-signing, retention, licensing/IP-transfer, buyer-verification and traceability docs on the single fix(security): bind workflow source and document MSA boundaries #71 canonical line after implementation stabilizes.
• Record current primary standards/technical documentation with APA 7 references for OCI image/runtime/annotations, SLSA, NIST SSDF/container guidance, Sigstore, SPDX/NOTICE and selected SBOM format.
• Update CHANGELOG.md; do not bump version or publish a release until integrated technical, review, provenance, licensing/NOTICE/IP-transfer and release-acceptance gates all pass.

Verification evidence

Retain references for exact source/workflow identities, built image/digest/platforms, SBOM/vulnerability/signature/provenance receipts, artifact-rights/NOTICE/license evidence, no-network isolation and trusted-host synthesis, exact patch request/result, independent review/protected merge, and rollback/rotation drill evidence.

Out of scope

This issue does not weaken #27, provision #29, configure #40, choose outbound licensing under #5, or claim acquisition readiness without #3/#5 production and commercial evidence.

Related: #5, #9, #27, #29, #40, #67, #69, #93

[seonghobae]

Security acceptance clarification: result producer must be privilege-separated

PR #65 exact head df9829aed39d8f447002b4eb411e7cab3285cb15 currently bind-mounts the sole host result.json writable and runs the validator plus repository-controlled validation subprocesses under the same non-root UID/GID. Descriptor-safe host reading, byte limits, schema validation, request rebinding, and zero-exit consistency do not by themselves authenticate the producer: same-UID untrusted code can attempt to keep a background writer alive and race/replace the final evidence file after the trusted entrypoint writes it.

Treat the existing “result replacement” criterion as requiring a real adversarial proof, not only path/symlink stability tests:

• untrusted repository code must never have write authority to the final evidence channel;
• do not rely on timing, PID-1 exit ordering, file mode bits shared by the same UID, or a secret pathname/environment variable;
• prefer architectural separation, such as no result mount in the untrusted execution container and host/trusted-controller construction of bounded evidence from authenticated execution facts, or a separately justified producer/runner privilege boundary;
• add a malicious fixture that forks/background-loops, discovers advertised file descriptors/mounts, and repeatedly attempts valid forged PASSED JSON before/during/after validator completion;
• prove the forged payload cannot become the host-observed result and that timeout/kill/cleanup paths fail closed;
• preserve no-network, no Docker socket, least privilege, exact-head binding, immutable image verification, and separation of evidence from approval/merge authority.

This is tracked under #66 rather than opening a duplicate issue because #66 already owns runtime activation and adversarial result-replacement verification. It does not justify weakening or bypassing PR #65's current RED CI, independent approval, CodeRabbit, or branch-protection gates.

[seonghobae]

2026-08-07 runtime-remediation assessment

PR #67 remains bound to exact head 7c4604ca25492b779cbb85b5b807e7bc989f42b0; no concurrent head change was observed before this write. Its fail-closed image scan remains correctly RED on five MEDIUM findings in the signed gcr.io/distroless/nodejs24-debian13 runtime.

Current upstream evidence does not support a safe same-family digest refresh:

• Distroless nodejs24-debian13 tracks Debian 13/trixie and is rebuilt from Debian updates: https://github.com/GoogleContainerTools/distroless
• CVE-2026-5435 remains unfixed for Debian trixie and is marked no-dsa: https://security-tracker.debian.org/tracker/CVE-2026-5435
• CVE-2026-5450 is fixed only in Debian forky/sid, not trixie: https://security-tracker.debian.org/tracker/CVE-2026-5450
• Debian's glibc tracker still lists CVE-2026-5928 and CVE-2026-6238 as open for trixie: https://security-tracker.debian.org/tracker/source-package/glibc
• CVE-2026-27171 is fixed in forky/sid zlib but remains vulnerable with no-dsa in trixie: https://security-tracker.debian.org/tracker/CVE-2026-27171

A potential alternative is a signed, SBOM-attested Chainguard Node runtime. However, the current public latest track is Node 26, the standard image specification reports a shell, and versioned Node 24/minimal variants require registry entitlement rather than being a verified drop-in public dependency:

• Node image/version catalogue: https://images.chainguard.dev/directory/image/node/versions
• Current specifications: https://images.chainguard.dev/directory/image/node/specifications
• Signature and attestation verification: https://images.chainguard.dev/directory/image/node/provenance

Therefore no branch change, vulnerability exception, VEX assertion, severity downgrade, or rerun-only remediation is justified. The safe next paths are:

1. wait for a signed immutable Debian 13 runtime whose complete final-image scan passes; or
2. obtain access to an exact Node 24 shell-free alternative, pin its digest, verify producer identity/signature/SBOM/provenance, prove Node/runtime compatibility and no-shell/no-package-manager properties, then rerun the complete exact-head evidence chain.

PR #67 must remain draft and unmergeable until one of those paths passes without weakening the existing MEDIUM/HIGH/CRITICAL gate.

[seonghobae]

Acceptance tightening from exact-head review of PR #67 at 95a9219e1087b1dc5d4a2fb3c8f8c2f0b4ca2b9e:

The current scratch image's fully-static Node 24.19.0 executable is positively identified as Node by Syft and evaluated as a Node CPE by Grype, but that is not yet sufficient embedded-component evidence. Node's upstream build documentation states that dependencies are bundled into the Node binary by default, and Node exposes dependency versions through process.versions. The current injected .note.package describes only Node itself, so bundled OpenSSL, zlib, libuv, nghttp2, Brotli, c-ares, llhttp, SQLite, and any other native dependency can remain invisible as independently matched vulnerability subjects.

Add these fail-closed acceptance requirements before publication/activation:

• derive a deterministic embedded-runtime component inventory from the exact reviewed Node source/build and the exact built runtime, cross-checking runtime-reported dependency versions against source/build metadata;
• keep an explicit allowlist of expected embedded component identities and reject unknown, omitted, duplicate, malformed, or unrepresentable components rather than silently dropping them;
• attach supported immutable package identities (PURL/CPE or scanner-supported ecosystem identity) per component where reliable; an unsupported identity remains an explicit unresolved release blocker;
• run vulnerability matching over the embedded-component inventory itself, not only the outer Node CPE or filesystem package database;
• bind the component inventory and vulnerability receipt to the same exact local image SHA-256 identity used by the runtime/SBOM/smoke evidence;
• add a RED regression proving a MEDIUM/HIGH/CRITICAL/UNKNOWN advisory on a bundled dependency cannot yield a clean verification receipt even when the Node-only CPE has no finding;
• prohibit VEX/ignore/severity-downgrade/empty-match interpretation as a substitute for component coverage;
• retain the existing Trivy filesystem/language lane and Syft/Grype Node-presence lane as separate evidence planes rather than scanner voting.

Primary sources to cite in the corresponding doctoring update: Node.js BUILDING.md for bundled dependencies, Node.js process.versions for runtime dependency-version inventory, and Grype's package/matcher/SBOM documentation for supported package identities and matching boundaries. This comment does not change #27/#29 governance gates or authorize merge/release.