> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/cooperation/nexus-guilds/future-of-web/xiii.-vulnerability.md). # XIII. Vulnerability Coordinated Intake, Verification, Disclosure Clocks, and Safe Technical Communication {% hint style="warning" %} **Draft instrument.** The clauses, fees, credits and effective dates on this page are drafts: no adoption record exists, and nothing here is in force. Ordinary participation has no fee ([NWG](/organization/governance-in-operation/nwg.md)). {% endhint %} **Where this fits:** all six sectors ([The Model](/organization/model.md)) · [Labs](/organization/programme/labs.md), [Risk Academy](/organization/programme/academy.md) · communities of practice by sector, supplying the questions of the Labs pillar; National Working Groups ([NWG](/organization/governance-in-operation/nwg.md)) · community of practice. **In brief.** RVD is an evidence and coordination discipline—operators remediate under their authority. Read against the international frameworks it serves ([UN General Assembly 2015](https://www.undrr.org/publication/sendai-framework-disaster-risk-reduction-2015-2030); [FAO 2014](https://www.fao.org/4/bl496e/bl496e.pdf); [One Health High-Level Expert Panel (OHHLEP) et al. 2022](https://doi.org/10.1371/journal.ppat.1010537)) and the [Nexus Standards](/organization/institutions/nexus-standards.md) that govern its records ([NS-0](https://nexustandards.com/standards/ns-0/), [NS-13](https://nexustandards.com/standards/ns-13/)). "An experiment is exploratory: its results are labelled as such and become evidence only after the Foundry rebuilds and the Universe tests them." (Labs pillar boundary). Ordinary participation has no fee. Paid work, internships and fellowships are separate arrangements, and unqualified contributors never take safety-critical tasks. {% hint style="info" %} **Read with the current model (2026-10-21).** * Everything this page describes is a design in formation. No national, regional or global consortium is recorded as constituted or active; the current service level is R0, information and enquiries ([Status and service levels](/organization/governance-in-operation/status-and-service-levels.md)). Where the text below reads as operation, read it as design. * Recognition, scoring and validation record what was shown under stated conditions. None is a certification, licence, rating or approval, and no country or institution is ranked. * Completion is recorded, not credentialed, until [Risk Academy](/organization/institutions/risk-academy.md) has an issuer, an assessment method and a revocation path on record; GCRI Canada is issuer of record ([Risk Academy](/organization/programme/academy.md)). {% endhint %} ### 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. *** ## Sources 1. UN General Assembly (2015). Sendai Framework for Disaster Risk Reduction 2015–2030. A/RES/69/283, 3 June 2015. 2. FAO (2014). The Water-Energy-Food Nexus: A new approach in support of food security and sustainable agriculture. Rome: Food and Agriculture Organization of the United Nations. 3. One Health High-Level Expert Panel (OHHLEP), Adisasmito, W. B. et al. (2022). One Health: A new definition for a sustainable and healthy future. PLoS Pathogens 18(6): e1010537. doi:10.1371/journal.ppat.1010537. 4. Nexus Standards. NS-0: Constitution and principles. Status: PROPOSED; UNI `NXS-STD-ST-000004`. 5. Nexus Standards. NS-13: Open standards development process. Status: PROPOSED; UNI `NXS-STD-ST-000008`. 6. GCRI. The Labs pillar home. 7. GCRI. Working groups (NWG). 8. This documentation: [Governance in operation](/organization/governance-in-operation.md); [The Model](/organization/model.md); [historical labels](/organization/reference.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.therisk.global/organization/cooperation/nexus-guilds/future-of-web/xiii.-vulnerability.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.