Draft prepared for attorney review. These documents are first drafts: they are not legal advice and have not been adopted by Varrock Inc. Points awaiting a business decision are marked [DECISION: …] and points for counsel [COUNSEL: …]; nothing here is in force.

Coordinated Vulnerability Disclosure Policy

Draft prepared for review by counsel. Dated 2026-10-06. This is a first draft produced for attorney review; it has not been adopted by Varrock Inc., is not legal advice, and creates no rights or obligations until published in final form. Every point that needs a decision by the company or its counsel is marked [DECISION: …] or [COUNSEL: …] and collected in section 13. Text inside HTML comments (<!-- -->) is drafting commentary for the reviewers and is to be stripped before publication.

Related documents: Privacy Policy · Website and Service Terms of Use · End User License Agreement · Third-Party Notices · EU product compliance memo · Enterprise security overview · Enterprise readiness

1. Purpose and status#

1.1 Varrock Inc. ("Varrock", "we", "us") makes OasisGUI available from oasisgui.com — free of charge for personal use, and under an Enterprise Licence Agreement for business use; oasis-runner, the oasisnet daemon and the bundled helpers ship inside that download and are installed on hosts by the app; Oasis Mobile, the iOS companion app, is distributed through Apple's channels (section 8.1). These products run on machines the user controls, carry SSH credentials and WireGuard keys, and install software across a fleet. We want to hear about security defects in them before anyone else does. [DECISION: align "free of charge" with the licensing wording settled for EULA section 3.2 (business use free, or under a written agreement) and with the website, which today says "Free download"]

1.2 This policy explains what is in scope, how to tell us about a vulnerability, what we promise in return, and what we ask of researchers. It is modelled on the vulnerability-disclosure and vulnerability-handling guidance in ISO/IEC 29147:2018 and ISO/IEC 30111:2019 and on RFC 9116, and is intended to serve as the coordinated vulnerability disclosure policy and single point of contact that Annex I, Part II, points (5) and (6) of the EU Cyber Resilience Act (Regulation (EU) 2024/2847) require. We have not been assessed against those standards and claim no certification.

1.3 This is not a bug bounty. We do not currently pay rewards. [DECISION: whether to offer rewards; if yes, a separate bounty document is needed, since reward programs are treated as contracts in several jurisdictions]

2. Definitions#

• "Vulnerability": a weakness in a Product that could be exploited to compromise the confidentiality, integrity or availability of a system or data, alone or in combination with another weakness.
• "Product": any item listed in section 3.1.
• "Reporter": anyone who reports a Vulnerability under this policy; "Report": what they send us.
• "Security Contact": the mailbox and security.txt file described in section 4.
• "Supported Version": as defined in section 8.
• "Fix": a change that removes or materially mitigates a Vulnerability, made available to users of a Supported Version.
• "Coordinated Disclosure": the Reporter withholds public details until a Fix is available or the deadline in section 6.3 passes, while Varrock works on the Fix.
• "Good Faith Security Research": as defined in section 7.1.
• "Terms": the Website and Service Terms of Use published at oasisgui.com; "EULA": the End User License Agreement for the Products.

3. Scope#

3.1 Products in scope#

[DECISION: keep the push gateway in scope while it is dormant, and list it in security.txt once it goes live] [DECISION: whether founder.oasis.cooking and the Varrock-run coordinators (oasis.cooking, relic) are product infrastructure or internal; if internal, state that they are out of scope]

3.2 Third-party code we ship. Bundled helpers and the libraries compiled into the Products (Rust crates, npm packages, the vendored boringtun and innernet code) are in scope for reporting: we accept the Report, forward it to the upstream project unless the Reporter already has, and ship the upstream Fix in our next release. The upstream project, not Varrock, owns the defect, so section 6.3's timeline runs from the upstream Fix becoming available and section 7 cannot waive the upstream project's rights (section 7.3). A defect in how a Product uses such code (installing an unverified script, misusing the user's SSH agent) is a Varrock defect on the ordinary timeline. A known vulnerability in a dependency with no demonstrated effect on a Product is accepted as a dependency-update request, not as a Vulnerability.

3.3 Out of scope#

The following are not Vulnerabilities under this policy, and testing them is not authorised under section 7:

• Infrastructure users operate. Coordinators, relays, exit nodes, runners, VMs, shared desktops and chat relays are hosted by the organisation that uses them, not by Varrock (the Varrock-operated hosts are listed in section 3.1). A weak password or exposed port in one deployment belongs to that operator; a weakness in the code that produces the deployment is in scope.
• Third-party services the app or a host contacts on the user's behalf — Anthropic's account endpoints used by the Claude accounts feature (claude.ai, console.anthropic.com, api.anthropic.com), OpenRouter, ElevenLabs, api.country.is, api.ipify.org, www.cloudflare.com/cdn-cgi/trace, ip-api.com / ipapi.co, the vendor install scripts the Install… flow runs (Claude Code, Codex, Kimi, OpenCode, Hermes, Homebrew), and package and VM-image mirrors. Codex and Kimi account data are read from local files; no OpenAI or Moonshot endpoint is contacted by Oasis itself. Report their weaknesses to their operators. What the app sends them is documented in the Privacy Policy; an undocumented or unnecessary outbound contact is in scope.
• Denial of service, volumetric or resource-exhaustion attacks against any Varrock host or any coordinator or relay.
• Social engineering, phishing or physical attacks against Varrock personnel, the registered agent, or users.
• Findings reproducible only on a version that is not a Supported Version (section 8).
• Informational findings on oasisgui.com (missing headers, SPF/DMARC, version banners) without demonstrable impact.
• Wrong or unsafe output from third-party AI agents (Claude Code, Codex, Kimi) or the Supervisor and Commander features, which act with the user's own credentials on the user's instruction. A way to make Oasis grant an agent more than the user intended is in scope.
• Raw scanner output without a working demonstration.

4. How to report#

4.1 Security Contact#

4.1.1 Send Reports to [DECISION: contact mailbox].

[DECISION: security mailbox — recommended security@oasisgui.com; read by someone who can act within the period in section 6.1; not auto-forwarded to the sales inbox]

4.1.2 Reports may be encrypted. [DECISION: publish an OpenPGP key for the Security Contact; private key held off the release workstation]

4.2 Draft security.txt#

The file below follows RFC 9116. Serve it at https://oasisgui.com/.well-known/security.txt (optionally mirrored at /security.txt), sign it with the key in 4.1.2, and refresh Expires before it lapses. The website is published by scripts/release.sh into a k3s-served web root; the file must be carried by the website build so a release never removes it. [DECISION: add security.txt to the website build; confirm the server serves .well-known/ paths]

# Varrock Inc. — OasisGUI, Oasis Mobile, oasis-runner, OasisNet
Contact: mailto:[DECISION: contact mailbox]
Expires: 2027-10-06T00:00:00.000Z
Encryption: https://oasisgui.com/security/pgp.txt
Preferred-Languages: en
Policy: https://oasisgui.com/security/
Canonical: https://oasisgui.com/.well-known/security.txt
Acknowledgments: https://oasisgui.com/security/thanks/

Expires may be at most one year out. The Encryption, Policy and Acknowledgments URLs are proposals. [DECISION: final URLs of this policy, the key and the credits page on oasisgui.com]

4.3 SECURITY.md#

The repository should carry a root SECURITY.md stating the Supported Version rule (section 8), the Security Contact and a link to this policy.

[DECISION: whether the repository will be made public; if so, SECURITY.md also surfaces in GitHub's security tab]

4.4 What to include#

• Product and version (OasisGUI: Settings; oasis-runner and oasisnet: --version);
• platform and, for mesh issues, whether the node was a peer, coordinator or relay;
• steps to reproduce or a proof of concept;
• impact as the Reporter understands it;
• whether the Vulnerability is, to the Reporter's knowledge, being actively exploited (section 5.6);
• whether anyone else has been told (upstream project, CERT, customer);
• how the Reporter wishes to be credited (section 6.5), if at all.

4.5 Do not send us other people's data; if a proof of concept reaches real user data, stop, record the minimum, and tell us.

4.6 We accept Reports in English. [DECISION: other languages]

4.7 Your data and your Report. We process the Reporter's contact details, any key, and the Report itself to triage and fix the issue, to communicate with the Reporter, to keep the log in section 10.2, and, with the Reporter's choice under section 6.5, to publish credit. The legal basis, recipients and retention are described in section 5.6 of the Privacy Policy (retention for the support period, which section 8.4 leaves to be decided; the credits page under section 6.5). Personal data of third parties that reaches us in a proof of concept is used only to assess the issue and is deleted once the Fix ships. By sending a Report the Reporter allows Varrock to use its contents to reproduce, fix, test, and describe the Vulnerability in an advisory; the Reporter keeps all other rights in their work.

5. What we do with a Report#

5.1 Acknowledge receipt and give the Reporter a reference identifier.

5.2 Triage. We reproduce the issue, assign a severity and say whether we agree it is an in-scope Vulnerability. CVSS v4.0 is a common language, not the sole measure: a low-scoring defect that leaks SSH keys is still critical.

5.3 Fix the Supported Version and ship through the channels in section 9. Where a complete Fix needs more time we may ship a mitigation first and say so.

5.4 Inform the Reporter of progress at reasonable intervals and on release; where practical we share the Fix in advance for verification under confidentiality.

5.5 Publish an advisory after release (section 9.6).

5.6 Notify authorities and users where required. Since 11 September 2026 the Cyber Resilience Act (Regulation (EU) 2024/2847, Article 14) requires a manufacturer that becomes aware of an actively exploited Vulnerability in a Product, or of a severe incident affecting a Product's security, to report it through the ENISA single reporting platform to the coordinating CSIRT: an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available (one month after the notification for a severe incident). Article 14(8) also requires us to inform affected users without undue delay, and where appropriate all users, of the Vulnerability and of the measures they can take. A Report of active exploitation starts those clocks, which is one reason section 4.4 asks for it. [COUNSEL: confirm Varrock, as a non-EU manufacturer making the Products available in the EU, is bound by Article 14; identify the coordinating CSIRT under the Article 14(7) cascade; advise whether an EU authorised representative under Article 20 should be appointed] [DECISION: who registers on the ENISA single reporting platform and holds the credentials]

6. Timelines and credit#

6.1 Acknowledgement: within 3 business days of receipt. [DECISION: confirm the acknowledgement period against who actually reads the mailbox]

6.2 Triage result: within 10 business days of acknowledgement.

6.3 Fix and disclosure window. Our target is a released Fix within 90 days of the triage result, sooner for critical issues. We ask the Reporter not to publish details before the earlier of (a) the day we release the Fix and advisory or (b) 90 days after the triage result, unless both sides agree another date in writing. Withholding publication until that date is a condition of the safe harbour in section 7, not a separate contract; a Reporter who publishes after that date remains within the safe harbour even if no Fix has shipped. If we need longer (for example, the Fix depends on an upstream project, section 3.2), we will say so and propose a date; the Reporter may decline.

6.4 Active exploitation. Either side may shorten the timeline. We prioritise a mitigation and an advisory over a complete Fix.

6.5 Credit. We credit Reporters by the name or handle they choose, in the advisory and on a credits page, unless they prefer anonymity. Duplicates of issues already known to us are not credited, but we tell the Reporter it was a duplicate.

6.6 Disputes over severity, scope or timing are stated plainly in writing. We never require a non-disclosure agreement as a condition of being heard.

7. Safe harbour#

7.1 Good Faith Security Research means accessing a Product solely to test or investigate a security flaw or Vulnerability, carried out in a manner designed to avoid harm to individuals or the public, where the information obtained is used primarily to promote the security of the Products and not for extortion, fraud or other wrongful purposes.

7.2 Authorisation. For a Reporter who conducts Good Faith Security Research within the scope in section 3 and the rules in section 7.4, Varrock:

• (a) considers the research authorised under the Computer Fraud and Abuse Act (18 U.S.C. §1030), the Delaware Computer Related Offenses statute (11 Del. C. §§931–941) and similar U.S. state laws, and will not initiate, and will not voluntarily support, a civil or criminal action against the Reporter on the basis of that research. This does not prevent us from complying with a subpoena, court order, or a lawful request from a public authority, including the CSIRT reporting in section 5.6; where we are compelled, we will tell the Reporter unless prohibited;
• (b) will not assert a claim under the anti-circumvention provisions of the Digital Millennium Copyright Act (17 U.S.C. §1201) or under the EULA for circumvention of technological measures or reverse engineering of a Product to the extent necessary for the research;
• (c) waives any restriction in the Terms or the EULA that would otherwise prohibit the research, to the same extent; and
• (d) will confirm this authorisation to any third party that asks about the Reporter's conduct, if the Reporter requests it.

7.3 Limits. This safe harbour binds Varrock only. We cannot authorise access to systems other people own — including the hosts, VMs, coordinators and relays that users of the Products run, and the third-party services in section 3.3 — and we cannot waive the rights of upstream projects whose code we bundle. Under EU and Member State law (Directive 2013/40/EU and its transpositions) good-faith research is not uniformly recognised as a defence; the Reporter remains responsible for the law where they are. For oasisgui.com and the other Varrock-operated hosts in section 3.1, section 7.2 is the authorisation of the system owner. Testing a copy of a Product the Reporter installed on their own machine does not involve access to anyone else's system. [COUNSEL: review this section against the DOJ 2022 CFAA charging policy and the disclose.io template; ensure the EULA and Terms carry a matching carve-out so this section is not contradicted elsewhere] [COUNSEL: summarise, for the EU Member States and the UK where Reporters are most likely to be based, whether and on what conditions a manufacturer's published authorisation shields a researcher under the transpositions of Directive 2013/40/EU and the national CVD frameworks adopted under NIS2 Article 12; adjust this paragraph accordingly]

7.4 Rules. The safe harbour applies only if the Reporter:

• tests only Products they installed themselves, on machines and accounts they own or are authorised to use;
• tests the Varrock-operated hosts in section 3.1 only as far as needed to show a defect in them, never with sustained or automated traffic against the download, update or binary endpoints;
• performs no denial of service, brute force or spam; no social engineering, phishing or physical intrusion;
• does not access, modify, exfiltrate or retain other people's data, and deletes any obtained incidentally once reported;
• installs no backdoor, persists no access, pivots nowhere and disrupts nothing;
• does not disclose publicly before the deadline in section 6.3;
• demands no payment as a condition of reporting or of withholding disclosure; and
• does not otherwise break the law in the course of the research.

7.5 A Reporter unsure whether a planned test is covered should ask the Security Contact first.

7.6 Accidental overstep. If a Reporter acting in good faith goes beyond the rules in section 7.4 by accident — for example a proof of concept reaches real user data — and stops, reports it to the Security Contact promptly and follows our instructions, we will treat the research as still within this section.

8. Supported Versions#

8.1 Only the latest published release of each Product is supported, and a Fix ships only as a new release. We do not back-port. This mirrors how the software is distributed:

• https://oasisgui.com/downloads/latest.json carries exactly one version with one signed artifact per platform; there is no manifest of older versions, so the updater can only ever offer the newest build.
• OasisGUI checks that manifest at launch and, by default, every 10 minutes. The periodic check can be switched off; the launch check and the manual check in Settings cannot.
• oasis-runner has no self-update path. The desktop app is the sole updater of the runners it manages: it bundles a runner binary, probes each host's installed hash and re-pushes its own copy on mismatch, leaving alone a runner stamped by a newer app build. A runner is therefore at the version of the newest desktop app that has connected to its host.
• oasisnet is installed on hosts from the app bundle; a newer bundled daemon produces an install offer in the app. NixOS hosts using the declarative module follow the flake revision they pin. NixOS VM templates fetch the daemon from start.oasis.cooking pinned by SHA-256; a Fix reaches that channel only when the pin is updated, which the advisory will say.
• Oasis Mobile is not on the public App Store. Two channels exist today: direct install from Xcode onto a developer-registered phone, and TestFlight builds uploaded through App Store Connect. Under Apple's TestFlight rules a build expires 90 days after upload, so the Supported Version is the newest TestFlight build. [DECISION: whether Oasis Mobile is offered to customers at all today; the production distribution channel (App Store, TestFlight, enterprise/ad hoc); and so what "latest release" and "Supported Version" mean for it and whether a Fix is delivered through TestFlight or a future App Store listing]

8.2 Nix-managed installs (VITE_OASIS_PACKAGE_MANAGER=nix) get no in-app updates and move to the fixed revision through Nix; advisories will name it.

8.3 A Report against an older version is welcome; we triage it against the latest release.

8.4 Support period. The Cyber Resilience Act (Article 13(8)) requires Varrock to handle Vulnerabilities for a support period that reflects the time the Products are expected to be in use and is at least five years unless that expected use is shorter, and (Annex II, user information) to state the end date of that period to users. Because we support the latest release only, the practical commitment is to keep publishing Fixes through latest.json and the equivalent channels for the stated period. [COUNSEL: verify the Article 13 paragraph numbers in the published Official Journal text before publication] [DECISION: the support period to state publicly, the date it runs from, and whether it is stated per major version] [COUNSEL: whether serving only the newest release satisfies Article 13(9) (security updates to remain available for at least ten years after issue or the remainder of the support period), or whether released artifacts must stay downloadable from an archive; the release script keeps no archive today]

9. How Fixes ship#

9.1 Signed desktop updates. Every OasisGUI update payload is signed with a minisign key whose public key is embedded in the app (src-tauri/tauri.conf.json, plugins.updater.pubkey). The Tauri updater verifies the signature against that key before installing and rejects anything that fails. The manifest keys (darwin-aarch64; linux-x86_64-appimage, linux-x86_64-deb, windows-x86_64 when built) ensure one installer format is never offered another's payload.

9.2 Platform signing. macOS builds are Developer ID signed, notarized, stapled and Gatekeeper-checked (scripts/release.sh). Linux and Windows builds carry the minisign updater signature only: no distribution-repository signature on Linux, no Authenticode on Windows, so a first Windows install passes through SmartScreen. This affects how an organisation should verify a first install. [DECISION: Authenticode signing for Windows]

9.3 Publication order. Artifacts are uploaded under size-and-SHA gates and installed together; latest.json lands last so no client sees a manifest pointing at a missing file; served bytes are fetched back and compared with the local build (scripts/release.sh).

9.4 User consent. Updates are never silent: the app shows the release notes and offers "Update & Restart" or "Later". A security Fix will say so in the first line of the notes. [DECISION: whether a security release may shorten the "Later" interval or re-prompt on a timer; the code today has no such distinction]

9.5 Hosts and mesh nodes. After a desktop update the app converges the runners on hosts it manages at the next connection or background sweep (src-tauri/src/runner_bootstrap.rs) and offers the newer oasisnet daemon where bundled. A runner or oasisnet Fix therefore reaches a host when an updated desktop app next connects; advisories will say which component carries the Fix.

9.6 Advisories. We publish an advisory for every Fix that resolves a Vulnerability, reported or found internally: affected Products and versions, fixed version, severity, Reporter credit (section 6.5) and any workaround. [DECISION: where advisories live — recommended https://oasisgui.com/security/advisories/ plus the entry in src/changelog.json the updater already shows; and whether to request CVE identifiers from MITRE or become a CNA]

9.7 Security Fixes separate from features. The CRA (Annex I, Part II, point (2)) requires that, where technically feasible, security updates be provided separately from functionality updates. Our single-track model ships both together. [COUNSEL: whether the single track is acceptable under the "where technically feasible" qualifier, or whether a patch-release convention carrying only the Fix must be adopted before December 2027]

9.8 Software bill of materials. The release produces no SBOM or provenance today (docs/enterprise/02-security.md); the CRA (Annex I Part II(1)) will require one covering at least top-level dependencies. Until then the list can be derived from Cargo.lock, bun.lock and src-tauri/binaries/manifest.json. [DECISION: add SBOM generation to scripts/release.sh ahead of the CRA deadline]

10. Internal handling#

10.1 The Security Contact is read by [DECISION: named roles, not individuals, with at least two people to cover absence].

10.2 Each Report is logged on receipt with reference, date, Product, severity and status, outside any issue tracker. [DECISION: where the vulnerability log lives; retain it for the support period as evidence for NIS2-regulated customers and market-surveillance authorities]

10.3 Fixes are developed without describing the exploit in commit messages or in src/changelog.json until the advisory is public. [DECISION: if the repository becomes public, adopt a private security branch or a private fork for embargoed fixes; today all work lands on main]

10.4 Release signing keys are held under access controls described in our enterprise security documentation. A suspected compromise of a signing key or of the release pipeline is treated as a critical in-scope Report; rotation means publishing a new updater public key in an update signed by the current key before retiring it. [DECISION: move release signing to hardened CI or a hardware token; write the key-rotation runbook; decide what, if anything, about key custody is said publicly]

11. Reports that reach us otherwise#

11.1 A security issue that arrives at sales@oasisgui.com, through a customer, a CERT/CSIRT, a public forum, social media or an issue tracker is handled under this policy from the time someone at Varrock reads it; a public post may be hidden until a Fix ships, and the timelines in section 6 run from our acknowledgement.

12. Changes and governing law#

12.1 We may change this policy by publishing a new version at the URL in security.txt. The version in force when a Report is received applies to it; safe-harbour changes do not apply retroactively to research already under way.

12.2 This policy, and any dispute arising from it, is governed by the laws of the State of Delaware, USA, without regard to its conflict-of-laws rules. If the Reporter is a consumer habitually resident in the EU, EEA or UK, this does not deprive them of the protection of the mandatory law of that country (Regulation (EC) 593/2008, Article 6(2)), and they may bring proceedings in the courts of that country and may be sued only there (Regulation (EU) 1215/2012, Articles 17–19, and the equivalent UK rules). [COUNSEL: whether a forum clause belongs in a non-contractual policy at all; if so, mirror Terms section 18.2 for business Reporters; confirm the wording is identical across the Terms, EULA and this policy]

13. Open decisions#

Every marker used above, by section.

Decisions for Varrock

1. §1.1 — (Resolved 2026-10-07: wording aligned with EULA §3.2 — personal use free, business use under an Enterprise Licence Agreement.)
2. §1.3 — [DECISION: whether to offer rewards; if yes, a separate bounty document]
3. §3.1 — [DECISION: keep the push gateway in scope while it is dormant, and list it in security.txt once it goes live]
4. §3.1 — [DECISION: whether founder.oasis.cooking and the Varrock-run coordinators are product infrastructure or internal; if internal, state that they are out of scope]
5. §4.1.1, §4.2 — [DECISION: security mailbox — recommended security@oasisgui.com], [DECISION: contact mailbox] (today the only published mailbox is sales@oasisgui.com; no SECURITY.md; no security.txt)
6. §4.1.2 — [DECISION: publish an OpenPGP key for the Security Contact]
7. §4.2 — [DECISION: add security.txt to the website build; confirm the server serves .well-known/ paths]
8. §4.2 — [DECISION: final URLs of this policy, the key and the credits page on oasisgui.com]
9. §4.3 — [DECISION: whether the repository will be made public] (private at the date of this draft)
10. §4.6 — [DECISION: other languages]
11. §4.7 — resolved on 2026-10-06: Privacy Policy §5.6 and §11 now carry the security-reports paragraph (purpose, Art. 6(1)(f) basis, recipients including the CSIRT and the credits page, retention tied to the support period in §8.4); the retention period itself remains open there. Still to do: point the Terms §9.4 marker at §4.7 — Terms owner.
12. §5.6 — [DECISION: who registers on the ENISA single reporting platform and holds the credentials]
13. §6.1 — [DECISION: confirm the acknowledgement period against who actually reads the mailbox]
14. §8.1 — [DECISION: whether Oasis Mobile is offered to customers; its production distribution channel; what "latest release" means for it]
15. §8.4 — [DECISION: the support period to state publicly, the date it runs from, and whether per major version]
16. §9.2 — [DECISION: Authenticode signing for Windows]
17. §9.4 — [DECISION: whether a security release may shorten the "Later" interval or re-prompt]
18. §9.6 — [DECISION: where advisories live; CVE identifiers or CNA status]
19. §9.8 — [DECISION: add SBOM generation to scripts/release.sh]
20. §10.1 — [DECISION: named roles reading the Security Contact]
21. §10.2 — [DECISION: where the vulnerability log lives]
22. §10.3 — [DECISION: private security branch or fork for embargoed fixes if the repository becomes public]
23. §10.4 — [DECISION: move release signing to hardened CI or a hardware token; key-rotation runbook; what is said publicly about key custody]

Questions for counsel

24. §5.6 — [COUNSEL: CRA Article 14 applicability to a non-EU manufacturer; coordinating CSIRT under the Article 14(7) cascade; Article 20 authorised representative]
25. §7.3 — [COUNSEL: safe-harbour wording vs. DOJ 2022 CFAA policy and disclose.io; matching carve-out in EULA and Terms]
26. §7.3 — [COUNSEL: whether a manufacturer's published authorisation shields a researcher in the relevant EU Member States and the UK (Directive 2013/40/EU transpositions; NIS2 Article 12 CVD frameworks)]
27. §8.4 — [COUNSEL: verify the Article 13 paragraph numbers in the published Official Journal text]
28. §8.4 — [COUNSEL: whether latest-only distribution satisfies Article 13(9), or whether an archive of released artifacts is required]
29. §9.7 — [COUNSEL: single-track releases under Annex I, Part II, point (2)]
30. §12.2 — [COUNSEL: whether a forum clause belongs in this policy; mirror Terms section 18.2; identical wording across Terms, EULA and this policy]

Source: docs/legal/vulnerability-disclosure-policy.md in the repository · draft for attorney review · 47 [DECISION] markers and 15 [COUNSEL] markers on this page.