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

[seonghobae]

Goal

Maintain a buyer-verifiable patch-validator image lifecycle: reviewed source → exact image/runtime/SBOM/vulnerability receipts → protected integration → protected-main operational acceptance → immutable publication/signature/attestation → controlled activation. The validator must never inherit reviewer/model/GitHub-write/provider-routing/quarantine/security/outbound/release authority, and automation must not invent outbound licensing authority.

Protected truth — 2026-09-07 KST

Current protected main is GitHub-verified d9b2a956960be72a5370afa50275a405dfbba529, the normal merge of #526 on top of protected 0dec8d84b1e4744e7a9c6a77e2e2631a183ee2ab. That parent already contains the normal #554 workflow-source trust integration; #554 is no longer an open image-gate candidate. The image/runtime/supply-chain implementation originally entered protected history through #407 as GitHub-verified squash commit 8ce7c7536888ec0b596e18368eedd9379deec64f; 8ce7c753... is the integration commit, not the current protected tip.

The unchanged #407 exact head 871490009a65336003047a85b994581ed3e36b44 reached terminal success in all four applicable gates before merge:

• Application CI 32619804074: success
• reviewer-ci 32619804030: success
• central Security Scan 32619804069: success
• dedicated patch-validator-image 32619804032: success
• unresolved review findings: 0

Current protected source retains the fully-static numeric-non-root scratch runtime, no-network/read-only/capability-dropped smoke path, exact source/image/receipt binding, pinned Trivy/Syft/Grype tooling, CycloneDX/SBOM/component evidence, reviewed runtime-component identities and applicability evidence, strict SHA-256/provider/CPE/provenance checks, fail-closed MEDIUM-or-higher policy, and credential-free validator execution.

Fresh current-main candidate evidence narrows the present verification latency. PR #543 exact b14b37ca12b3b6ae1999d250a393997ffff04dec has terminal-success application CI 34071938887, reviewer-ci 34071938888, and required Security Scan 34071938889. Dedicated image run 34071938978, job 101590775349, is assigned to GitHub-hosted runner 1001730092; exact checkout, stale-head refusal, scanner installation, exact dependency materialization and Buildx completed, and the job is still executing Build exact-head patch-validator image. This is PR-head verification only and does not satisfy protected-main operational acceptance or publication.

The current workflow gives the image build a 150-minute step timeout within a 180-minute job and uses shared GHA BuildKit cache scope noema-patch-validator-image. The reviewed Dockerfile intentionally compiles checksum-pinned OpenSSL 3.5.8 and fully-static Node 24.19.0 from source before producing the scratch runtime. Several current candidate generations are concurrently in that build phase; this is therefore build-cost/cache-population throughput evidence, not a repository-wide hosted-runner assignment outage. Do not weaken the static/non-root/scratch/runtime receipt boundary to shorten the queue. After one current generation completes, compare BuildKit cache-hit/export evidence before changing the canonical #550→#540 workflow/toolchain lane.

No GitHub release currently exists for Noema. Historical #407 PR-head evidence and current open-PR image evidence therefore remain implementation/integration or candidate verification history, not protected-main operational publication evidence.

Historical predecessor #67 was semantically compared with the integrated successor and closed as superseded; it was not merged.

Completed local-image criteria

• Reconstruct the image/runtime/verifier/reviewer integration on protected lineage.
• Preserve node_patch_verify_v1, exact source/image/receipt binding, supply-chain pinning and credential-free isolation.
• Add realistic no-network/read-only/non-root smoke and hostile-result-channel regressions.
• Add CycloneDX, Trivy, Syft/Grype, static-runtime/component and exact-image receipt verification.
• Repair builder/runtime/scanner evidence failures test-first without weakening isolation or vulnerability thresholds.
• Require reviewed identities/provenance for independently versioned bundled runtime components.
• Fail closed on malformed/ambiguous image identity, unreviewed provider/CPE provenance, cross-repository smoke evidence, duplicate image authority and receipt-path replacement.
• Preserve raw scanner evidence separately from reviewed applicability evidence.
• Obtain application CI, reviewer-ci, eligible central Security Scan and dedicated image terminal-success on one unchanged exact feat(sandbox): restack patch-validator image on current main #407 head before integration.
• Re-read live base/reviews/scanner authority immediately before integration and merge the unchanged gate-clean successor.
• Compare feat(sandbox): build and verify patch-validator image #67 against the integrated successor and close it as superseded only after valuable semantic preservation was established.

Remaining executable boundary

Protected-main operational acceptance

• Execute .github/workflows/patch-validator-image.yml by its protected workflow_dispatch entrypoint against the then-current exact protected main and retain immutable run/artifact identities.
• Bind the retained receipt to that exact protected source revision. Historical feat(sandbox): restack patch-validator image on current main #407 PR-head evidence and open-PR evidence do not substitute for protected-main proof.
• If protected-main execution fails, repair the exact causal boundary test-first without weakening scanner/isolation policy.

The currently available GitHub write surface exposes rerun operations but no generic fresh workflow_dispatch action for this workflow. A rerun of a prior PR event is not a protected-main dispatch and must not be used to manufacture this acceptance receipt. Waiting on an authorized fresh dispatch blocks only this operational sub-lane.

Publication / signature / provenance

• Publish only an immutable image digest after protected-main local-image acceptance.
• Sign/attest through a verified repository-controlled or keyless identity that is not exposed to untrusted execution.
• Generate provenance bound to repository, exact source, workflow path/ref, builder/runner identity, image digest and build parameters.
• Verify signature/provenance/SBOM/source/signer identity before reviewer consumption or activation.
• Retain bounded machine-readable receipts with schema versions and canonical SHA-256 identities.

Licensing / transfer rights

• Keep OCI/artifact outbound-license metadata absent or subordinate to an explicit authorized owner/legal decision.
• Bind artifact-rights evidence to SemVer tag, full source commit, immutable image digest, SBOM, dependency-license inventory, NOTICE/attribution and provenance.
• Preserve third-party obligations; vulnerability success is not license/transfer-rights evidence.

Activation / buyer proof

• Activation defaults disabled until protected operational/publication evidence passes.
• Validator evidence never counts as formal approval, merge/release authority, deployment authority or acquisition readiness.
• Refuse stale/missing/malformed/mismatched producer/workflow/image/receipt evidence.
• Exercise rollback/rotation/recovery and retain buyer-verifiable evidence.
• Reconcile canonical operations/security/threat-model/test/traceability/licensing authority after publication/activation implementation stabilizes.

Guardrails

Do not weaken #27, provision #29/#227 by source fiction, configure #40 by documentation, synthesize #3 production KPI evidence, choose an outbound license, or write central .github/naruon/contextual-orchestrator source from this issue.

Related: #5, #9, #27, #29, #40, #73, #227, #407, #526, #539, #543, #550, #554.

[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.