morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #6708] [Feature] Require dependency security evidence for source and fresh release consumers #4079

New issue

Open

opened 2026-10-31 00:46:40 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:46:40 +00:00

Owner

Originally created by @gensokyo-dev on GitHub (Oct 23, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6708

Before submitting

Searched related issues/PRs; #6480 is the parent audit tracker and #4898 is a broader Scorecard proposal.
Reviewed the contribution scope; this concerns existing CI/release verification, with no new analysis provider or target capability.
No credentials, private samples or exploit details are included.

Area

Setup, packaging, or upgrade / CI

Current limitation

At main 5d6b8a0ab693c03ab85cf0807d40bedf021e76d8, npm publication is isolated (#6681), but required qualification has no advisory/signature gate. The audit in #6480 found a known development dependency advisory and nine transitive version differences between a fresh 6.7.0 consumer and its source lock. Those differences are allowed semver resolution, not a compromise finding. Current source/consumer audits and installed-platform signature commands pass, but that manual evidence is not an ongoing gate.

Desired outcome and success criteria

Add bounded read-only source advisory/signature checks and require them for release qualification.
Check the actual fresh consumer used by release rehearsal/post-publication verification, sharing the installation owner instead of resolving a second tree.
Retain full raw reports and installed-tree evidence; return a small report with source/version/digests, graph fingerprint, installed-platform coverage and explicit unknowns. npm signature JSON does not expose a verified-signature count; do not invent one or imply cross-platform coverage.
Known advisories, invalid/missing signatures, malformed output and unavailable evidence must not become a clean pass.
State the consumer semver-resolution policy and its residual risk: the source lock alone does not pin downstream installations. A full-source shrinkwrap prototype installed development dependencies; it must not be shipped as a shortcut.
Measure real source/consumer runs and report elapsed/CPU/peak memory with cold/warm distinctions. Preserve exact qualified bytes, cleanup and CLI/MCP canaries.

Expected interaction with targets

Read project/dependency metadata; write private temporary consumer projects/evidence; contact the official npm registry; run pinned npm and existing local CLI/MCP verification processes. No analyst-target execution, injection or mutation capability is added. Install dependency hooks remain disabled in security scans.

Target and scope details

Reuse the current Node/npm pins, existing qualification and canonical canary installation. Keep npm issuer authority out of scanning jobs. Administrative alert/publisher settings and optional native secondary-download trust are separate assessments in #6480. No npm release or administrative setting change is requested by this implementation.

Verification available so far

Observed results and packaging prototypes are recorded in #6480 and #6681. The new automated gate and its cost are not yet measured. Source-only absence of a gate is not a runtime compromise reproduction.

Originally created by @gensokyo-dev on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6708 ## Before submitting - [x] Searched related issues/PRs; #6480 is the parent audit tracker and #4898 is a broader Scorecard proposal. - [x] Reviewed the contribution scope; this concerns existing CI/release verification, with no new analysis provider or target capability. - [x] No credentials, private samples or exploit details are included. ## Area Setup, packaging, or upgrade / CI ## Current limitation At main `5d6b8a0ab693c03ab85cf0807d40bedf021e76d8`, npm publication is isolated (#6681), but required qualification has no advisory/signature gate. The audit in #6480 found a known development dependency advisory and nine transitive version differences between a fresh 6.7.0 consumer and its source lock. Those differences are allowed semver resolution, not a compromise finding. Current source/consumer audits and installed-platform signature commands pass, but that manual evidence is not an ongoing gate. ## Desired outcome and success criteria - Add bounded read-only source advisory/signature checks and require them for release qualification. - Check the actual fresh consumer used by release rehearsal/post-publication verification, sharing the installation owner instead of resolving a second tree. - Retain full raw reports and installed-tree evidence; return a small report with source/version/digests, graph fingerprint, installed-platform coverage and explicit unknowns. npm signature JSON does not expose a verified-signature count; do not invent one or imply cross-platform coverage. - Known advisories, invalid/missing signatures, malformed output and unavailable evidence must not become a clean pass. - State the consumer semver-resolution policy and its residual risk: the source lock alone does not pin downstream installations. A full-source shrinkwrap prototype installed development dependencies; it must not be shipped as a shortcut. - Measure real source/consumer runs and report elapsed/CPU/peak memory with cold/warm distinctions. Preserve exact qualified bytes, cleanup and CLI/MCP canaries. ## Expected interaction with targets Read project/dependency metadata; write private temporary consumer projects/evidence; contact the official npm registry; run pinned npm and existing local CLI/MCP verification processes. No analyst-target execution, injection or mutation capability is added. Install dependency hooks remain disabled in security scans. ## Target and scope details Reuse the current Node/npm pins, existing qualification and canonical canary installation. Keep npm issuer authority out of scanning jobs. Administrative alert/publisher settings and optional native secondary-download trust are separate assessments in #6480. No npm release or administrative setting change is requested by this implementation. ## Verification available so far Observed results and packaging prototypes are recorded in #6480 and #6681. The new automated gate and its cost are not yet measured. Source-only absence of a gate is not a runtime compromise reproduction.

bsakaguchi added the

triage

enhancement

labels

2026-10-31 00:46:40 +00:00

bsakaguchi commented

2026-10-31 00:46:40 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 24, 2026):

Strong proposal — turning manual audit evidence into an ongoing release-qualification gate is the right direction, and the "known advisories / invalid or missing signatures / malformed output / unavailable evidence must not become a clean pass" clause is the part that matters most; CI gates quietly passing on absent data are worse than no gate. Two suggestions: (1) since a known dev-dependency advisory already exists, ship an explicit advisory baseline/allowlist with the rationale for each entry, so the gate fails on new or changed advisories instead of making the whole pipeline red until the baseline is cleared; (2) classify "evidence unavailable" as its own distinct state (not pass, not advisory) in the small report — that keeps the honest-unknowns requirement auditable at a glance. Agree with keeping the consumer semver-resolution policy and residual risk stated rather than hidden by a shrinkwrap shortcut.

@XinwangTao commented on GitHub (Oct 24, 2026): Strong proposal — turning manual audit evidence into an ongoing release-qualification gate is the right direction, and the "known advisories / invalid or missing signatures / malformed output / unavailable evidence must not become a clean pass" clause is the part that matters most; CI gates quietly passing on absent data are worse than no gate. Two suggestions: (1) since a known dev-dependency advisory already exists, ship an explicit advisory baseline/allowlist with the rationale for each entry, so the gate fails on *new* or *changed* advisories instead of making the whole pipeline red until the baseline is cleared; (2) classify "evidence unavailable" as its own distinct state (not pass, not advisory) in the small report — that keeps the honest-unknowns requirement auditable at a glance. Agree with keeping the consumer semver-resolution policy and residual risk stated rather than hidden by a shrinkwrap shortcut.

bsakaguchi referenced this issue

2026-10-31 01:11:25 +00:00

[PR #4080] [MERGED] perf(tests): reuse CLI compilation for exported binding checks #6043

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#4079

No description provided.

Rows
Columns