Coordinated Vulnerability Disclosure & Safe Harbour Policy

1. Binding Legal Safe Harbour & Statutory Authorisation

When conducting security research in strict, good-faith compliance with every boundary set forth in this Policy, British Noble considers your testing activity to be authorised conduct:

• British Noble will not initiate, recommend, or support any civil lawsuit or criminal law-enforcement referral against you under the UK Computer Misuse Act 1990, the US Computer Fraud and Abuse Act (CFAA, 18 U.S.C. Sec. 1030), EU Directive 2013/40/EU on attacks against information systems, UAE Federal Decree-Law No. 34 of 2021 on Countering Rumours and Cybercrimes, or analogous cybercrime statutes.
• To the extent your good-faith testing requires bypassing a technological protection measure solely to verify a security flaw in an in-scope system, British Noble waives anti-circumvention claims under Section 1201 of the US Digital Millennium Copyright Act (DMCA) and Sections 296ZA-296ZF of the UK Copyright, Designs and Patents Act 1988.
• Should a third party or cloud infrastructure provider initiate legal proceedings against you for good-faith testing performed strictly within this Policy on British Noble-owned properties, British Noble will take affirmative steps to confirm in writing to relevant authorities or counsel that your research was conducted pursuant to our authorised Vulnerability Disclosure Policy.

If at any point you are uncertain whether a proposed test vector falls within authorised scope, pause immediately and email Security@BritishNoble.com for written clarification before executing the test.

2. Authorised In-Scope Properties & Sandbox Testing Rules

Security research is authorised solely against the following British Noble first-party production and sandbox properties, using only self-registered sandbox accounts created by the researcher (for example, registering two separate 14-day evaluation workspaces using email aliases such as researcher+tenantA@yourdomain.tld and researcher+tenantB@yourdomain.tld to test cross-tenant isolation):

• Primary public web properties and API routes served directly under https://britishnoble.com/*;
• The authenticated 11-screen Publishing OS web application at https://britishnoble.com/app/* tested strictly against researcher-owned sandbox workspaces;
• Authenticated Connected Author Portal workflows tested strictly between researcher-owned publisher and researcher-owned author accounts;
• Documented OpenAPI 3.1 REST endpoints, SAML 2.0 / OIDC federation handshakes, and webhook signing verification routines; and
• Isolated file ingestion and preflight parsers (EDItEUR ONIX 3.1.2 XML, Adobe IDML packages, Word .docx, EPUB 3.3 archives, and PDF/X-1a metadata extractors) tested strictly with benign, non-destructive proof-of-concept payloads inside researcher-owned sandboxes.

3. Out-of-Scope Targets & Prohibited Testing Methods

To safeguard live publishing schedules, retail ONIX feeds, and third-party providers, the following targets and techniques are strictly prohibited and excluded from safe harbour:

• Destructive or Availability Attacks: Volumetric Denial-of-Service (DoS/DDoS), algorithmic complexity exhaustion (such as multi-gigabyte zip bombs aimed at starving preflight worker pools), or automated credential-stuffing/brute-force floods.
• Human & Physical Vectors: Phishing, spear-phishing, vishing, SMS social engineering, pretexting against Customer Support or British Noble staff, or physical intrusion against regional desks or AWS data centres.
• Third-Party Infrastructure: Underlying infrastructure belonging to Amazon Web Services, Stripe, Wise, Okta, Microsoft, or external retail distribution channels (Ingram, Amazon, Apple, Kobo, OverDrive), which maintain their own independent vulnerability disclosure programmes.
• Low-Impact / Non-Exploitable Scanner Noise: Unauthenticated rate-limit observations on marketing contact forms, informational TLS cipher ordering notes where TLS 1.2/1.3 AEAD is active, missing theoretical HTTP headers lacking a demonstrable exploit chain, clickjacking on static non-authenticated pages, or raw automated scanner exports submitted without manual validation.

4. Mandatory Halt-on-Sight Rule for Unpublished Manuscripts & PII

Publishing platforms store irreplaceable unreleased creative works whose premature exposure could destroy years of an author's labour. Accordingly, researchers must strictly obey the Embargoed IP Zero-Touch Rule: you must never intentionally target, access, modify, corrupt, or download another customer's manuscripts, galley proofs, cover artwork, contributor profiles, tax forms, or financial ledgers.

If, while testing cross-tenant access controls between your own two sandbox accounts, you inadvertently observe any indicator suggesting visibility into a real third-party tenant (such as a non-test UUID, title string, or HTTP metadata header), you must stop testing immediately, capture solely the minimal opaque request/response header proving existence of the flaw (redacting any visible literary text or personal identifier), refrain from opening or downloading any document body, and report the finding straight to Security@BritishNoble.com marked URGENT P1 ISOLATION.

5. PGP Encrypted Reporting Protocol & Required Evidence

All vulnerability disclosures must be submitted electronically to Security@BritishNoble.com (also advertised via our RFC 9116 compliant /.well-known/security.txt manifest). For sensitive findings involving authentication, cryptography, or parser execution, encrypt your report payload using the British Noble Product Security PGP key published in security.txt (4096-bit RSA / Ed25519 subkey; verify fingerprint before encrypting). Never upload live vulnerability proofs to public GitHub gists, Pastebin, third-party Slack channels, or unencrypted video-sharing sites.

To enable rapid engineering reproduction on the first pass, include in every submission: (a) affected URL, API endpoint, or parser component; (b) vulnerability classification (CWE identifier) and estimated CVSS v4.0 vector string; (c) exact researcher sandbox account emails and UTC timestamps of your test requests so our SOC can whitelist your source IP in WAF logs; (d) deterministic step-by-step reproduction instructions with raw HTTP requests/responses or minimal benign sample file; and (e) assessment of realistic publishing security impact.

6. CVSS v4.0 Severity Triage, Remediation & Audit Log SLAs

Every valid report submitted to Security@BritishNoble.com enters our CISO-monitored vulnerability queue and is scored objectively using the FIRST Common Vulnerability Scoring System v4.0 (CVSS v4.0) alongside publishing-specific multi-tenant impact weighting:

Retroactive Tenant Log Sweep: Whenever a Critical or High vulnerability is confirmed, our Security Operations team immediately queries immutable WORM audit logs across all sovereign regions to verify mathematically whether any malicious actor exploited that vector prior to the researcher's report; if any customer workspace were ever affected, our ≤ 24-hour DPA breach notification protocol triggers immediately.

7. High-Priority Publishing Architecture Research Classes

Product Security particularly values deep manual architectural research across six core publishing surfaces: (1) PostgreSQL Row-Level Security (RLS) predicate enforcement and per-tenant AWS KMS encryption-context isolation across Single Title Record REST and batch-export queries; (2) XML parser hardening against entity expansion, XInclude, XSLT injection, or external DTD/XSD schema-fetch SSRF inside EDItEUR ONIX 2.1/3.0/3.1.2 and Adobe IDML ingestion pipelines; (3) OpenType/WOFF2 font-shaping, ICC colour profile parsing, and PDF/X-1a rendering micro-container boundary escapes; (4) SAML 2.0 XML signature wrapping, OIDC state/nonce binding, and SCIM 2.0 bearer token scoping; (5) multi-currency fixed-decimal rounding, sliding royalty escalator transitions, and idempotency-key race conditions in the Sales & Royalties settlement engine; and (6) forensic watermark stripping or bypass on High-Security Embargo digital review galleys.

Submitting a clean, minimal reproduction script demonstrating any flaw across these six architectural classes receives immediate escalated review by a Principal Security Architect alongside our CISO.

8. 90-Day Embargo & Coordinated Public Disclosure Rules

British Noble practises transparent Coordinated Vulnerability Disclosure. Researchers agree to keep all vulnerability particulars, HTTP traces, and proof-of-concept payloads strictly confidential until British Noble has deployed and verified the production remediation across all four sovereign cloud regions (UK, EU, US, and UAE), up to a standard ninety (90) calendar day disclosure window measured from validated triage (extendable once by mutual written agreement solely where an upstream open-source library or operating-system kernel requires coordinated multi-vendor CVE embargoes).

Prior to publishing any technical blog post, academic paper, or security conference presentation discussing a resolved finding, researchers submit a pre-publication draft to Security@BritishNoble.com at least ten (10) business days in advance so our Product Security Desk can verify that zero customer identifiers, ISBN fixtures, internal hostnames, or unpatched third-party vendor details are inadvertently disclosed, and coordinate official CVE-ID assignment where applicable.

9. Security Hall of Acknowledgements & Discretionary Recognition

Researchers who are the first to submit a previously unknown, reproducible, in-scope vulnerability that leads to a substantive engineering code, parser, or infrastructure configuration change are eligible (at their election, credited under legal name, academic affiliation, or handle) for permanent attribution in the British Noble Security Hall of Acknowledgements, a formal CISO-signed Letter of Commendation suitable for academic tenure, visa, or career portfolios, and discretionary recognition awards approved by the CISO Security Committee for high-impact Critical or High cross-tenant, cryptographic, or parser findings.

Eligibility requires full adherence to this Policy, including the Embargoed IP Zero-Touch Rule and coordinated disclosure embargo. Duplicate submissions of issues already tracked internally by our engineering team or previously reported by an earlier researcher receive courteous confirmation citing the original internal ticket timestamp. Current or former employees and contractors of British Noble (within twelve months of departure) and their immediate household members are ineligible for monetary awards.

10. Researcher Data Hygiene & Post-Remediation Destruction

Throughout testing, researchers must store HTTP proxy databases (such as Burp Suite, OWASP ZAP, or Caido project archives), packet captures, screenshots, and proof-of-concept artefacts exclusively on full-disk-encrypted local workstations protected by multi-factor authentication, never syncing unencrypted vulnerability captures to consumer cloud folders. Within seven (7) calendar days following written confirmation from British Noble that the vulnerability has been remediated and verified in production, researchers must securely and permanently overwrite and delete all local response captures containing British Noble workspace payloads and, for Critical or High findings, confirm deletion by reply email to Security@BritishNoble.com.

11. Triage Escalation Review & Policy Maintenance

If a researcher believes in good faith that a submitted report was inaccurately classified, prematurely closed, or underscored under CVSS v4.0, they may request an independent escalation review addressed to CISO & General Counsel Escalation via Security@BritishNoble.com. Escalations are reviewed within five (5) business days by a Staff Security Architect who did not participate in the initial triage decision. This Policy is reviewed annually by the CISO and Legal Counsel; any future revision applies strictly prospectively and shall never retroactively diminish legal safe harbour for good-faith research initiated under a prior published version.