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

[seonghobae]

Goal

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

Protected source truth — 2026-09-08 KST

Protected Noema is GitHub-verified main@699489cdbb8de3404154d9a3d6022c692ce85fd6, the normal #547 documentation-authority integration after #540 toolchain/license repair. The dedicated patch-validator image/runtime/supply-chain implementation entered protected history through #407 and remains preserved by subsequent integrations.

Current protected source retains the fully-static numeric-non-root scratch runtime, no-network/read-only/capability-dropped smoke, exact source/image/receipt binding, pinned Trivy/Syft/Grype tooling, CycloneDX/SBOM/component evidence, reviewed runtime-component provenance, strict identity/applicability checks and fail-closed vulnerability thresholds. #540 removed the historical Wrangler/Miniflare/Sharp/Libvips tooling path in favor of pinned direct source truth without weakening this boundary.

#547 exact 30b7e7e5cdab8de65715834a16f994b2047eafa6 subsequently reached all four terminal GREEN gates before normal merge, including patch-validator-image run 34165467851. That image job completed every static runtime, smoke, SBOM, Grype/Syft component and exact-receipt step successfully. This is strong current PR-head verification, but it is still not protected-main operational acceptance or immutable publication.

A live performance/RCA finding exposed why successive sibling PR image runs remained cold despite type=gha,scope=noema-patch-validator-image: the workflow ran only on PR branches/dispatch, while GitHub Actions cache visibility does not let one sibling PR restore another sibling's branch cache. #540 run 34155490034 spent about 104 minutes in the exact image build; later sibling #547 again spent about two hours building the same static runtime.

Draft #558 repairs that causal boundary. It adds protected-main cache seeding only when image-authority paths change, while retaining workflow_dispatch and every security/isolation/receipt gate. After #547 changed protected ancestry, #558 was ordinary/non-force converged to f2aa8570d952cc0a371da161e651472c080e00ce, behind_by=0. Hosted CI 34172635652, job 101895784847, then produced a real RED after checkout, live-base verification, lockfile control, install and typecheck: the legacy patch-validator-workflow test incorrectly required bare pull_request: to be directly adjacent to workflow_dispatch: and rejected the intentionally added sibling push: trigger. The run reported 1 failed / 4121 passed tests.

Current #558 exact is 2f91bf8641212ecae435b5fbcc9084cc0acd6295. The minimum causal repair changed only the stale test contract so it still proves pull_request: has no nested filters while allowing an independent sibling event trigger. Production workflow, permissions, scanner/isolation gates and publication authority were not weakened. Fresh compare against protected 699489c... is ahead-only, behind_by=0, merge-base exactly protected main, with effective changes limited to .github/workflows/patch-validator-image.yml, test/patch-validator-image-build-cache.test.ts, and test/patch-validator-workflow.test.ts. A wholly fresh application/reviewer/Security/image generation is running; predecessor results do not transfer.

A normal #558 merge necessarily changes the image workflow path, so the resulting protected merge commit will run the full image workflow once on main and seed a default-branch BuildKit cache available to later sibling PRs; unrelated main merges will not enqueue the 150-minute lane.

The GitHub release collection remains empty. No historical PR-head image receipt, current candidate image check, package version or issue text counts as an immutable released artifact.

Completed source/image criteria

• Exact-source quarantine and dedicated validator-image implementation are protected.
• Preserve node_patch_verify_v1, exact source/image/receipt binding, supply-chain pinning and credential-free isolation.
• Real no-network/read-only/non-root smoke and hostile-result-channel regressions exist.
• CycloneDX, Trivy, Syft/Grype, static-runtime/component and exact-image receipt verification exist.
• Reviewed identities/provenance are required for independently versioned bundled runtime components.
• Malformed/ambiguous image identity, unreviewed provider/CPE provenance, cross-repository smoke evidence, duplicate image authority and receipt-path replacement fail closed.
• Raw scanner evidence remains separate from reviewed applicability evidence.
• Current docs: reconcile protected runtime and commercial gap authority #547 exact head reached application/reviewer/Security/image terminal success before normal protected integration.
• fix(toolchain): replace Wrangler/Miniflare GPL-family path #540 protected source removes the prior GPL-family tooling path without weakening the static runtime or scanner boundary.

Remaining executable boundary

Protected-main operational acceptance and cache seed

• Complete fix(ci): seed patch-validator cache from protected main #558 exact 2f91bf8641212ecae435b5fbcc9084cc0acd6295 on one unchanged head with application CI, reviewer-ci, required Security and patch-validator-image terminal success, clean review authority and current-base ancestry; normal merge only.
• Verify the resulting protected-main push image run executes against the exact fix(ci): seed patch-validator cache from protected main #558 merge commit and retains its exact artifact/run identities. This run is both the required protected-main operational acceptance opportunity and the first reusable default-branch BuildKit cache seed.
• Bind retained receipt to that exact protected source. Historical feat(sandbox): restack patch-validator image on current main #407/docs: reconcile protected runtime and commercial gap authority #547 PR-head evidence does not substitute.
• On a subsequent image-authority PR, verify cache restoration from protected main and record actual build duration against the cold fix(toolchain): replace Wrangler/Miniflare GPL-family path #540/docs: reconcile protected runtime and commercial gap authority #547 baseline. Do not claim a performance gain from configuration alone.
• If protected-main execution or cache restoration fails, repair the exact causal boundary test-first without weakening scanner/isolation policy.

Publication / signature / provenance

• Publish only an immutable image digest after protected-main operational acceptance.
• Sign/attest through verified repository-controlled or keyless identity isolated from untrusted execution.
• Bind provenance 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-versioned canonical SHA-256 identities.

Licensing / transfer rights

• Keep outbound artifact-license metadata absent or subordinate to an explicit authorized owner/legal decision.
• Bind actual release rights 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.

Guardrails

Do not weaken #27, fabricate #29/#227 identity provisioning, configure #40 by documentation, synthesize #3 production KPI evidence, choose an outbound license, or write central .github, contextual-orchestrator, quarantine or egress source from this owner lane.

Related: #5, #9, #27, #29, #40, #73, #227, #407, #531, #558.

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