Security and Vulnerability Disclosure Policy

1. Scope

This policy covers the NexusNest server (cloud-hosted and self-hosted), the desktop agent, the detector service and the document-processing services. Third-party AI providers whose traffic NexusNest redacts are out of scope; report issues in those products to their own vendors.

In scope for testing under this policy:

• The production NexusNest web application and dashboard.
• The desktop agent, at any published version.
• A customer's own self-hosted deployment, with that customer's authorisation, and never another customer's tenant or deployment.

Out of scope:

• Denial-of-service testing against shared production infrastructure.
• Social engineering of NexusNest staff or customers.
• Physical access attacks against NexusNest or customer facilities.
• Any access to another customer's tenant data, even to demonstrate a cross-tenant isolation issue. Report the class of issue without performing it against real data.

2. How to report

Email [email protected]. Do not file a public issue or disclose a suspected vulnerability publicly before this process completes. A report should include:

• A clear description of the vulnerability and its impact.
• Reproduction steps or a proof of concept sufficient to confirm it.
• The affected component, version and deployment type (cloud or self-hosted).
• Any supporting logs, requests or screenshots.

A report must not include real customer data, unredacted prompt content or document contents. If a proof of concept captures such data incidentally, redact it before sending.

3. Acknowledgement and triage

We acknowledge every report within 2 business days. We then reproduce the issue and score it under CVSS v3.1, and may ask the reporter for more detail during triage.

4. Fix SLA

One fix SLA applies equally to vulnerabilities in our own code, in third-party libraries and in container base images:

For our own code the SLA clock starts on confirmation. For third-party libraries and base images it starts when a fixed version is available upstream. A finding with no upstream fix is tracked in our vulnerability register as “no upstream fix – monitored”, re-checked on every rescan, and its SLA starts on the day a fix is published.

5. Image rebuild and rescan cadence

• Base images are pinned by digest and dependencies by lockfile. Base-image and library updates are reviewed regularly, and an update that fixes a vulnerability is released within the fix SLA.
• Every shipped server, dashboard, detection and document-processing image is rebuilt from source without cache at least monthly; the agent release image is rebuilt and rescanned with every agent release.
• All shipped images are rescanned weekly at every severity.
• A rescan that finds a fixable Critical or High vulnerability triggers an immediate rebuild and a remediation release within the fix SLA.

6. Exceptions

When a fix cannot ship within the SLA, for example because it requires an incompatible upgrade, the finding becomes a documented exception recording the CVE, severity, affected component or image, justification and compensating controls, a named approver and a fixed expiry date. Exceptions are listed by name in each release's signed security statement and re-reviewed at every release. At expiry an exception is renewed with fresh approval, or the SLA applies from that date.

7. Customer notification

We notify affected customers' registered security contacts:

• within 6 hours of confirming any compromise of our build or release pipeline (source repository, CI/CD, signing keys, or registries we push from);
• within 24 hours of confirming a High or Critical vulnerability in the product.

The notification goes out even before a fix ships. It states what is known, what is not yet known, and any interim mitigation the customer can apply.

8. Fix, advisory and credit

Every fix ships with a regression test that reproduces the issue before the fix and passes after it. Once the fix ships we email each affected customer's registered security contact and add a “Security fixes” section to the release notes for the fixed version, naming the CVE ID where one was assigned and the severity. With the reporter's permission, we credit them in the advisory. We do not publish exploit details, or details sufficient to reconstruct an exploit, before affected customers have had a reasonable window to update.

9. Coordinated disclosure

We ask reporters to allow the fix SLA window above before any public disclosure. If a reporter intends to publish independently, we ask for advance notice so we can align timing with our own advisory and customer notification. We do not ask for indefinite embargoes; if a fix SLA is missed, the reporter is free to escalate or publish, and we will say so if that happens.

10. Safe harbour

We consider security research conducted under this policy to be authorised, and we will not pursue legal action against a reporter who:

• Reports through the channel above, in good faith, before public disclosure.
• Makes a good-faith effort to avoid privacy violations, degradation of service and data destruction while testing.
• Does not access, retain or exfiltrate data beyond what is strictly necessary to demonstrate the vulnerability.
• Does not access another customer's tenant, data or deployment without that customer's separate authorisation.
• Gives us the opportunity to investigate and remediate before disclosing publicly.

If a report or its testing falls outside these bounds, this safe harbour does not apply and we evaluate the situation on its own facts.

11. Version history

• 1.1 (6 October 2026): one fix SLA for code, libraries and base images; documented exceptions; 6-hour notice for build or release pipeline compromise; image rebuild and rescan cadence.
• 1.0 (29 September 2026): initial release.