# XIII. Vulnerability ### Part 13 — Responsible Vulnerability Disclosure and Do-No-Harm Publication #### 1. Objective, Scope, and Safety Boundary 1.1 **Objective.** This Part establishes a Responsible Vulnerability Disclosure (RVD) system that enables vulnerabilities and systemic weaknesses in the web ecosystem to be reported, verified, coordinated, disclosed, corrected, and learned from—without enabling exploitation or creating avoidable harm. 1.2 **Scope.** RVD applies to:\ 1.2.1 vulnerabilities discovered through lawful, non-intrusive methods permitted under Part 5;\ 1.2.2 vulnerabilities reported by external researchers, operators, and participating institutions;\ 1.2.3 ecosystem issues spanning dependencies (packages, CDNs, certificates, DNS), platform configurations, and supply-chain paths; and\ 1.2.4 integrity issues where the risk is exploitation, coercion, or systemic abuse (e.g., pervasive misconfiguration patterns, credential exposure indicators, dependency compromise signals). 1.3 **Non-executing boundary.** The Guild and Platform:\ 1.3.1 do not conduct exploitation;\ 1.3.2 do not provide weaponizable exploit playbooks;\ 1.3.3 do not perform operational incident response, dispatch, or remediation; and\ 1.3.4 do not act as an enforcement body.\ RVD is an evidence and coordination discipline—operators remediate under their authority. 1.4 **Do-no-harm principle.** Safety overrides publication ambition. Where disclosure risks materially increasing harm, the Guild must reduce detail, delay release, coordinate privately, or withhold publication—while preserving correctionability and accountability by record. *** #### 2. Intake Channels, Eligibility, and Reporter Protection 2.1 **Intake channels.** The Guild shall maintain one or more intake channels appropriate to handling classes, including:\ 2.1.1 a public intake path for Public-safe reports;\ 2.1.2 a controlled intake path for security-sensitive reports; and\ 2.1.3 an emergency path for active exploitation or systemic threat events. 2.2 **Eligibility to file.** Reports may be filed by:\ 2.2.1 individual researchers and maintainers;\ 2.2.2 participating labs and institutions;\ 2.2.3 infrastructure operators; and\ 2.2.4 enterprises using the Platform, subject to their internal authorization. 2.3 **Reporter protections (minimum).** The Guild shall:\ 2.3.1 support anonymity or pseudonymity where lawful;\ 2.3.2 avoid unnecessary identity collection;\ 2.3.3 treat reporter identity as Controlled or Restricted by default when requested; and\ 2.3.4 publish acknowledgment only by opt-in, subject to safety constraints. 2.4 **Safe harbor statement (R\&D posture).** The Guild may publish a safe-harbor posture describing permitted research behavior under this Charter’s measurement doctrine. Such posture is informational only and does not override law, contracts, or third-party program rules. *** #### 3. Triage, Classification, and Handling Class Assignment 3.1 **Triage objective.** Triage determines:\ 3.1.1 whether the report is valid and within scope;\ 3.1.2 the likely severity and exploitation plausibility;\ 3.1.3 the appropriate handling class;\ 3.1.4 the coordination route (operator, maintainer, CERT/CSIRT, regulator where lawful); and\ 3.1.5 the disclosure clock and publication posture. 3.2 **Handling class defaults.**\ 3.2.1 **Public-safe** only where disclosure cannot materially enable exploitation.\ 3.2.2 **Controlled** where technical details could raise risk if widely distributed.\ 3.2.3 **Restricted** where active exploitation, high systemic impact, or clear weaponization risk exists. 3.3 **Severity taxonomy (minimum).** Severity should be assigned using an established vulnerability scoring approach suitable to the domain, augmented by ecosystem impact factors such as:\ 3.3.1 scale of affected population;\ 3.3.2 dependency centrality (supply-chain criticality);\ 3.3.3 exploit maturity and availability;\ 3.3.4 detectability and time-to-exploit; and\ 3.3.5 downstream harm categories (financial, safety, rights, critical infrastructure). 3.4 **Out-of-scope handling.** If a report is out-of-scope, the Guild shall:\ 3.4.1 notify the reporter;\ 3.4.2 avoid retaining sensitive details beyond minimum necessary; and\ 3.4.3 where appropriate, route the reporter toward the correct program (without transferring sensitive content unless authorized). *** #### 4. Verification Standards and Evidence Pack Requirements 4.1 **Verification posture.** The Guild shall verify claims to the extent possible without exploitation. Verification methods may include:\ 4.1.1 reproducible observation of misconfiguration indicators;\ 4.1.2 non-intrusive validation of exposed interfaces;\ 4.1.3 certificate and DNS evidence corroboration;\ 4.1.4 dependency and version analysis; and\ 4.1.5 operator-confirmed validation. 4.2 **No exploit validation by default.** Proof-of-concept exploitation is prohibited unless:\ 4.2.1 explicitly authorized by the affected operator;\ 4.2.2 lawful and within a permitted testing scope; and\ 4.2.3 handled under Restricted class with stop-the-line oversight. 4.3 **Minimum evidence artifact.** Every accepted report shall have a record-valid artifact (at minimum a Controlled record) that includes:\ 4.3.1 reporter submission metadata (minimized);\ 4.3.2 affected scope (as precisely as safe);\ 4.3.3 observation data and provenance;\ 4.3.4 method/version identifiers;\ 4.3.5 severity rationale and uncertainty;\ 4.3.6 coordination route; and\ 4.3.7 correction/supersession references once remediated. 4.4 **AEP linkage.** For high-impact cases, an Assurance & Evidence Pack may be produced with:\ 4.4.1 reproducibility notes;\ 4.4.2 safe technical description;\ 4.4.3 remediation verification indicators; and\ 4.4.4 publication abstraction level declared by record. *** #### 5. Coordination Routes and Interfaces 5.1 **Operator-first coordination.** Where an operator is identifiable and reachable, the Guild should coordinate directly with the operator or its designated security contact, subject to:\ 5.1.1 handling class controls;\ 5.1.2 minimum necessary disclosure; and\ 5.1.3 secure communication. 5.2 **Maintainer and ecosystem coordination.** Where vulnerabilities involve open-source packages, libraries, or ecosystem registries:\ 5.2.1 maintainers should be notified using established channels;\ 5.2.2 coordination should prefer structured advisories and patch readiness; and\ 5.2.3 supply-chain implications should be addressed explicitly (affected versions, dependency graphs). 5.3 **CERT/CSIRT interface.** Where systemic or cross-operator risk exists, the Guild may route through CERT/CSIRT ecosystems to accelerate safe coordination, subject to:\ 5.3.1 lawful basis;\ 5.3.2 handling class constraints; and\ 5.3.3 records discipline. 5.4 **Regulatory notification.** Regulatory notification, where required or prudent, must:\ 5.4.1 remain informational and evidence-based;\ 5.4.2 avoid compliance determinations;\ 5.4.3 preserve confidentiality where lawful; and\ 5.4.4 be recorded with handling class and reliance bounds. *** #### 6. Disclosure Clocks, Exceptions, and Active Exploitation 6.1 **Default disclosure clock.** The Guild shall operate a default disclosure clock suitable for ecosystem safety, with flexibility by severity and exploitation status. 6.2 **Emergency posture.** Where active exploitation is suspected or confirmed:\ 6.2.1 the case is elevated to Restricted;\ 6.2.2 coordination routes are expedited;\ 6.2.3 publication detail is minimized; and\ 6.2.4 a public notice, if issued, must avoid operationally useful details. 6.3 **Extensions and exceptions.** Extensions may be granted where:\ 6.3.1 remediation requires complex coordination;\ 6.3.2 premature disclosure raises harm materially; or\ 6.3.3 legal constraints apply.\ Any extension must be recorded with rationale. 6.4 **Disclosure completion criteria.** Disclosure may be considered complete when:\ 6.4.1 operators have had a reasonable opportunity to remediate;\ 6.4.2 a safe public description is prepared; and\ 6.4.3 correction/supersession pointers are published. *** #### 7. Publication Abstraction Rules: Safe Technical Detail Levels 7.1 **Abstraction-by-default.** Public publications must be written to reduce exploitability while preserving learning value. 7.2 **Prohibited publication content.** Public releases must not include:\ 7.2.1 step-by-step exploitation instructions;\ 7.2.2 payloads, working exploit code, or weaponizable configs;\ 7.2.3 targetable details that materially increase exploitation likelihood; or\ 7.2.4 guidance enabling coercion, surveillance, or abuse. 7.3 **Permitted publication content.** Public releases may include:\ 7.3.1 high-level vulnerability class and conditions;\ 7.3.2 affected product families or patterns (not enumerated target lists unless safe);\ 7.3.3 detection and verification indicators that are non-exploitative;\ 7.3.4 remediation principles and safe configuration targets; and\ 7.3.5 references to standards and defensive best practices. 7.4 **Controlled technical notes.** More detailed technical material may be shared under Controlled handling with verified recipients where:\ 7.4.1 it is necessary for remediation; and\ 7.4.2 recipients agree to handling and non-redistribution rules. *** #### 8. Acknowledgment, Credits, and Attribution 8.1 **Credit posture.** Credits should:\ 8.1.1 be opt-in;\ 8.1.2 protect anonymity where requested; and\ 8.1.3 avoid exposing reporter identity to retaliation risk. 8.2 **Attribution rules.** Public attribution must:\ 8.2.1 reflect the correct contribution;\ 8.2.2 avoid implied endorsement; and\ 8.2.3 comply with handling rules and legal constraints. 8.3 **Contribution recognition.** Where the Platform or Guild operates a contribution recognition system, RVD contributions may be recognized as:\ 8.3.1 validation contributions (verification and safe reporting);\ 8.3.2 ecosystem contributions (fixes, documentation, test harnesses); and\ 8.3.3 research contributions (methods and benchmarks)—subject to anti-gaming controls. *** #### 9. Post-Disclosure Learning Loop and Benchmark Corrections 9.1 **Learning loop requirement.** For each closed RVD case, the Guild shall:\ 9.1.1 issue a closure record;\ 9.1.2 update relevant benchmarks, test harnesses, and detection logic where appropriate;\ 9.1.3 publish deprecation or correction notes if prior guidance is unsafe or inaccurate; and\ 9.1.4 record what changed and how future cases will be handled. 9.2 **Benchmark integrity constraints.** Updates to benchmarks driven by disclosure events must:\ 9.2.1 preserve reproducibility;\ 9.2.2 document method/version changes;\ 9.2.3 prevent gaming; and\ 9.2.4 maintain longitudinal comparability through clear supersession pointers. 9.3 **No silent edits.** Any change to published findings, severity, or recommended defensive posture must be made through correction and supersession records consistent with the correction clocks. *** #### 10. Records, Governance, and Stop-the-Line Authority 10.1 **RVD registers.** The Guild shall maintain, at minimum:\ 10.1.1 an intake register;\ 10.1.2 a coordination register (routes and status);\ 10.1.3 a publication register (what was disclosed, when, and at what abstraction); and\ 10.1.4 a correction/supersession register. 10.2 **Stop-the-line authority.** The Integrity Steward may:\ 10.2.1 halt publication;\ 10.2.2 elevate handling class;\ 10.2.3 require additional redaction; or\ 10.2.4 mandate a safety review,\ where disclosure could materially increase harm, violate this Charter, or create legal/rights exposure. Reasons must be recorded. 10.3 **Appeals.** Disputes about disclosure timing, attribution, or publication content must be processed through the contestability and remedy discipline, with minimal disclosure and handling-class constraints. *** --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.therisk.global/organization/cooperation/nexus-guilds/future-of-web/xiii.-vulnerability.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.