security: enable and evidence private vulnerability reporting

[seonghobae]

Buyer-visible gap

Repository policy can define a private-first vulnerability-disclosure process, but source text and CI cannot prove that GitHub private vulnerability reporting is enabled, visible to external reporters, monitored, staffed, or operational. Until those live administrator and case-handling controls are evidenced, reporters may have only the content-free public-contact fallback.

Current clean policy implementation: PR #95, exact head 1fc38bb3234f1ffca35989c52682ee76fce45b9b on protected base c85d710804139c0697d7ef8fa47d02b1389e6d84.

Fresh current-head evidence:

• application ci run 31383398820: terminal success;
• reviewer-ci run 31383399170: terminal success;
• central Security Scan run 31383398494: terminal success under its scanner/revision semantics;
• predecessor CodeRabbit test-contract finding is addressed by a throwing body getter regression and the inline thread is resolved;
• no qualifying independent non-author formal APPROVED review is established;
• GitHub reports docs(security): restack coordinated vulnerability disclosure after nanoid #95 mergeable and Ready.

These source/check results do not prove this issue's live operational controls or merge authority.

Repository-owned evidence boundary

#95 provides, subject to protected integration:

• 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 with the live-setting evidence procedure;
• a read-only GitHub status probe that permits only organization-scoped GET, uses a 20-second timeout, strict UTF-8 streaming and 16 KiB ceiling, and passes only on explicit boolean enabled: true;
• executable policy/audit regressions and standards doctoring.

A passing setting probe is setting evidence only. It does not prove reporter UI visibility, notifications, staffing, case access, independent review, release/deployment acceptance, or acquisition readiness.

Fresh live setting evidence — 2026-08-15

• protected main at observation: 86ad5cba7089da125fabc75a42e8b240654bf866;
• authenticated repository API GET /repos/ContextualWisdomLab/noema/private-vulnerability-reporting returned the explicit object { "enabled": true };
• repository visibility remained public;
• the active organization ruleset remained CWL Noema central security scan, with no bypass actors and current_user_can_bypass="never".

This closes only the administrator-setting fact. It does not prove the external reporter UI, notification delivery, staffing/backup coverage, case access, or a benign end-to-end disclosure exercise. The protected-source audit receipt also remains separately required.

Acceptance criteria

Protected policy prerequisite

• Acquire fresh terminal-success application/reviewer/Security Scan evidence on unchanged docs(security): restack coordinated vulnerability disclosure after nanoid #95 current head and resolve valid current findings.
• Satisfy actual live chore(governance): protect main and enforce release checks #27/chore(operations): provision and activate hourly maintainer App #29 governance and qualifying independent formal-review requirements.
• Integrate unchanged docs(security): restack coordinated vulnerability disclosure after nanoid #95 under protected policy.
• Run the read-only private-vulnerability-reporting audit from protected source and retain exact repository/source/timestamp/result evidence.

Live administrator / reporter evidence

• A repository administrator enables GitHub private vulnerability reporting for ContextualWisdomLab/noema without weakening repository visibility, branch protection, Actions, review, or advisory controls.
• The repository Security interface exposes Report a vulnerability to an unauthenticated or ordinary external reporter as GitHub supports.
• The protected-source read-only audit records status: PASS; a failing or unavailable result remains fail closed and may not be edited into PASS.

Staffing / exercise evidence

• At least two authorized maintainers or the approved security team receive and can access private reports; ownership and backup coverage are documented without publishing secrets or unnecessary personal data.
• A benign end-to-end exercise creates a private report or draft advisory, records UTC timestamps for receipt and acknowledgement, and proves that no vulnerability details enter public issues, pull requests, CI logs, model prompts, or public artifacts.
• Notification delivery and backup ownership are observed rather than inferred.
• Evidence identifies repository, administrator setting, exercise case identifier, actors/roles, observation time and limitations; screenshots/exports remain access controlled and contain no tokens, private keys, exploit payloads or unnecessary PII.
• The exercise verifies duplicate handling, independent technical review assignment, state transitions, and closure/deletion according to the vulnerability-handling lifecycle.
• The disabled/unavailable setting path uses only the content-free Private security contact requested fallback and moves technical details into an approved private case before handling.

Buyer / documentation evidence

• After live proof exists, reconcile SECURITY.md, vulnerability-handling/runbook, canonical fix(security): bind workflow source and document MSA boundaries #71 documentation/traceability and buyer data-room evidence without promoting settings or staffing that were not observed.
• Retained public acquisition evidence proves control operation without exposing reporter identity, vulnerability details, exploit-enabling content or secrets.

Non-goals / guardrails

No public vulnerability details, synthetic enabled-setting claim, invented security contact/PGP/bounty/SLA/compensation/24x7 staffing, branch-repair/self-modifying Action, reviewer/release credential workaround, protection bypass, synthetic approval, or release merely because policy/checks are green.

Related: #27, #29, #40, #71, #72, #95

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