security: enable and evidence private vulnerability reporting

[seonghobae]

Buyer-visible gap

Noema has protected private-first disclosure policy, a hardened read-only GitHub setting probe, and a protected scheduled/manual evidence workflow. The remaining commercial/security gap is a current protected-source retained audit receipt plus external reporter/staffing/end-to-end case proof. Repository source and CI must not fabricate those later evidence classes.

Current protected truth — 2026-08-25

Current protected main is GitHub-verified 2c83355529447248c246805d1954f268e027d2ab. The private-vulnerability-reporting implementation entered protected history through #423 as squash commit a7793751f5b033515e9d57ca276df4d77228ce64 and remains present on the current protected lineage; a779375... is integration history, not the current protected tip.

Current protected source contains:

• root SECURITY.md with private-first reporting and content-free public fallback;
• docs/security/vulnerability-handling.md with case roles/states, exact-source evidence, incident escalation, test-first remediation, independent review, bounded retention, legal hold and secure deletion/redaction semantics;
• docs/security/private-vulnerability-reporting-audit.md;
• hardened scripts/private-vulnerability-reporting-audit.mjs with repository/source binding, JSON/media/UTF-8/duplicate-key/size/timeout defenses and explicit enabled: true acceptance;
• package command security:private-reporting-audit;
• .github/workflows/private-vulnerability-reporting-audit.yml with manual dispatch plus daily schedule, contents: read only, credential-free exact checkout, no secret/write contract, and bounded artifact retention;
• the workflow remains within the repository's reviewed immutable artifact-upload authority.

The historical #95 implementation line and merged #423 are integrated history, not current PR owners.

Live setting evidence already observed

On 2026-08-15 the repository status API returned { "enabled": true } for ContextualWisdomLab/noema, while repository visibility remained public. That is historical administrator-setting evidence for that observation time only. It does not prove that the setting is still enabled on 2026-08-25, external reporter UI visibility, notification delivery, staffing/backup coverage, case access, or a benign end-to-end disclosure exercise. Until a fresh protected-source audit is retained, do not promote the 2026-08-15 observation into current operational PASS.

#423 integration evidence

#423 was repaired after its first GREEN candidate exposed a real repository CI contract failure: the new artifact-producing workflow was absent from the complete reviewed upload-artifact workflow inventory. The canonical branch added that missing inventory entry, then non-destructively incorporated the then-current protected documentation tip. On unchanged exact head 76846a143e375d0f83305bb59e24bfc52d815ac5, Application CI 32092608629, reviewer-ci 32092608640, and central Security Scan 32092608636 all reached terminal success with zero unresolved review threads. #423 was then squash-merged as protected commit a7793751f5b033515e9d57ca276df4d77228ce64.

That proves historical source/workflow integration only. It does not prove a current protected audit execution, reporter/staffing/case evidence, release/deployment, or acquisition readiness.

Acceptance criteria

Repository-owned setting evidence

• Private-first policy, vulnerability lifecycle, read-only setting probe and adversarial response handling are protected source.
• Administrator setting was observed enabled on 2026-08-15; preserve it as dated historical evidence only.
• security(operations): retain private-reporting setting evidence #423 reached terminal-success exact-head CI/reviewer/Security evidence with zero valid unresolved findings before integration.
• Integrate the unchanged security(operations): retain private-reporting setting evidence #423 semantics under protected governance.
• Run the protected-source private-vulnerability-reporting audit against the then-current exact protected main and retain a report bound to exact repository, exact protected source revision, observation timestamp and immutable workflow/run identity.
• A failing/unavailable/stale audit remains FAIL/non-authoritative; no retained report is edited into PASS.

External reporter evidence

• From an unauthenticated or ordinary external-reporter perspective, verify GitHub exposes Report a vulnerability for the intended public repository without exposing technical details publicly.
• Retain bounded observation evidence that does not contain a real vulnerability, reporter identity, secret, exploit payload or unnecessary PII.

Staffing / benign exercise evidence

• At least two authorized maintainers or the approved security team can access private reports; record primary/backup ownership without publishing sensitive identity data unnecessarily.
• A benign synthetic report or draft advisory exercises receipt, acknowledgement, assignment, private technical handling, duplicate behavior where applicable, independent review, and closure.
• Observe notification delivery and backup ownership rather than infer them from configuration prose.
• Prove no vulnerability details enter public issues/PRs/CI/model prompts/public artifacts.
• Exercise the disabled/unavailable fallback using only the content-free Private security contact requested path before technical details move to an approved private case.

Buyer / transfer evidence

• Retain a buyer-safe evidence receipt that proves control operation without exposing private case content.
• Reconcile canonical traceability/data-room evidence after protected operational proof exists; do not revive historical docs: establish canonical product and trust-boundary documentation #71/docs(security): restack coordinated vulnerability disclosure after nanoid #95/security(operations): retain private-reporting setting evidence #423 ownership or claim release/deployment/acquisition readiness from this setting alone.

Current execution boundary

The repository-owned source/workflow gap is integrated. The currently available GitHub write surface does not expose a fresh generic workflow_dispatch operation for this audit workflow, so an immediate protected audit run must not be fabricated through a rerun, status edit, or alternate source path. The scheduled workflow remains the legitimate future evidence path. Waiting blocks only this operational sub-lane.

Non-goals / guardrails

No public vulnerability details, synthetic setting claims, invented security email/PGP/bounty/SLA/24x7 staffing, PAT/App credential merely for a public status GET, self-modifying workflow, protection bypass, synthetic approval, or release because historical setting/source evidence was green.

Related: #5, #27, #29, #40, #66, #227, #407.

[seonghobae]

Repository-owned detection advanced on PR #72 without asserting that the administrator control is already enabled.

At exact PR #72 head 50f42d6b2b09be57cd20406c09d4a0a79de0c8c2, a test-first read-only audit now exists as scripts/private-vulnerability-reporting-audit.mjs plus a pure evaluator/URL contract in scripts/lib/private-vulnerability-reporting-audit.mjs. The probe is bounded to GitHub's GET /repos/{owner}/{repo}/private-vulnerability-reporting status endpoint, accepts only an explicit boolean enabled: true as PASS, fails closed on disabled/malformed/unavailable responses, never uses PUT/DELETE, and writes machine-readable evidence to artifacts/security/private-vulnerability-reporting-audit.json. Its evidence explicitly states that a passing setting read does not prove notification routing or an end-to-end private-report exercise.

Current CI run 31332120576 executed all 4 new audit contract tests successfully; the full suite is 653/653 with configured owned statement/branch/function/line coverage at 100%. The run remains failed only at the inherited nanoid <3.3.17 high-severity audit gate already isolated in #75/#76, so this is diagnostic test evidence rather than a green merge gate. Central Security Scan 31332120561 is terminal success; reviewer CI is still handled as separate evidence.

This closes only the repository-owned detection gap. The issue remains open: live enabled/disabled status, external-reporter UI exposure, authorized maintainer access/backup coverage, benign notification/exercise evidence, and retained operational evidence are still unproven and must not be inferred from repository text or the status probe.

[seonghobae]

Fresh live administrator evidence from this invocation:

• protected main observed immediately beforehand: f1b5a5626b4779b7a554aee76ba600e19ad53cc7;
• read-only GitHub API GET /repos/ContextualWisdomLab/noema/private-vulnerability-reporting returned exact payload {"enabled":true};
• live ruleset remains organization-owned CWL Noema central security scan (18794436) with no bypass actors and no policy weakening performed by this observation.

This proves the repository setting is currently enabled. It does not prove the external reporter UI, notification delivery, two-person staffing, case access, benign end-to-end exercise, or protected-source #95 audit execution. Keep those acceptance lanes fail-closed and separate. No vulnerability details, secrets, reporter identity, or synthetic case evidence were created.

[seonghobae]

Fresh live administrator-setting evidence on protected main 18cac8dcab31dd53048d5d14ad01673b5b77d141: authorized read-only GitHub API probe GET /repos/ContextualWisdomLab/noema/private-vulnerability-reporting returned exact payload {"enabled":true}. This satisfies the narrow live setting fact only. It does not prove external-reporter UI visibility, notification delivery, staffing/backup ownership, benign end-to-end advisory exercise, independent case review, or acquisition readiness; those acceptance lanes remain open/fail-closed until independently observed.

[seonghobae]

Fresh live control-plane evidence: GitHub's repository private-vulnerability-reporting endpoint currently returns {"enabled": true} for ContextualWisdomLab/noema.

This satisfies only the administrator-setting existence boundary. It does not prove the external reporter UI, notification delivery, two-person staffing/backup coverage, private-case access, benign end-to-end exercise, duplicate handling, review assignment, or retention/deletion lifecycle. Those acceptance lanes remain fail closed until directly observed. The setting evidence is also separate from PR #95 source integration and protected-source audit evidence.

[seonghobae]

Fresh live control-plane proof: GET /repos/ContextualWisdomLab/noema/private-vulnerability-reporting returned exactly { "enabled": true } while protected main remained e52f802c65cc07f3a9083e78d053bbe16d8e4b37. This establishes the repository setting only. It does not establish external reporter UI visibility, notification delivery, staffing/backup ownership, case access, end-to-end advisory exercise, protected-source audit execution, release/deployment acceptance, or acquisition readiness. Keep those acceptance items fail-closed until independently observed.