Scoped Reservation Visibility Prevents Cross-Project Disclosure Leakage

# Scoped Reservation Visibility Prevents Cross-Project Disclosure Leakage ## Claim A shared vulnerability-reservation system needs per-project visibility scoping, or every participant can see every other participant's unpublished disclosures.  ## Scope & conditions - Holds for any multi-tenant system where reservations, drafts, or embargoed records are pending disclosure and the tenants are otherwise unrelated (competing or unaffiliated projects sharing one authority). - The fix generalizes beyond CVEs to any shared-infrastructure model where "who can issue" and "who can see what's been issued but not published" are separate questions — MITRE's default conflates them. - Weakens where all participants already share a trust boundary (a single team's internal projects), since leakage between them carries little marginal risk. ## Evidence MITRE's current CNA infrastructure exposes reservations across the whole organization — any project with issuance access can see other projects' pending, unpublished CVEs. The OpenJS Security Working Group's proof-of-concept adds a "bucket" model: reservations are scoped per project, with separate test and production buckets, closing a gap the presenter identifies as MITRE's own tooling not currently solving. > [!quote] > "if we want to give credentials to anyone any project within the foundation to issue their own CVs, that's going to be challenging because everybody will see other's reservation" ## Links - [[3. Resources/Permanent Notes/Delegated Authority Scales When Coordination Stays Central]] — because applies-in; this scoping mechanism is what makes that source's broader delegation model safe to ship - [[3. Resources/MOCs/Open Source Governance MOC]] — because applies-in; shared-infrastructure design for multi-project foundations ## Tests / falsifiers - Check whether the bucket model's test/production separation actually prevents a test-environment mistake from touching a live MITRE record — if a leak occurs across that boundary, the scoping claim needs revision. - Confirm whether any two unaffiliated projects can, in practice, enumerate each other's bucket references or reservation counts even without reading contents — partial leakage (existence disclosure) would qualify the claim. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Literature Notes/OpenJS Security Working Group - June 22, 2026]] — OpenJS Security Working Group meeting, architecture/bucket-model segment