Coordinated Vulnerability Disclosure Policy

Purpose

We welcome good-faith security research and encourage responsible reporting of vulnerabilities that may affect our products, services, or supporting infrastructure. This Coordinated Vulnerability Disclosure (CVD) Policy explains how to report vulnerabilities to us, how we handle reports and how we coordinate remediation and disclosure.

This policy is intended to support a documented vulnerability handling process consistent with applicable cybersecurity and product security obligations.

Scope

This policy applies to:

  • Supported product versions published by Neoception
  • Documentation, update channels and software components that are part of the supported product lifecycle

This policy does not automatically apply to:

  • End-of-life or unsupported versions
  • Third-party services not operated by Neoception
  • Customer-managed environments, except where the vulnerability is rooted in our product

How to Report a Vulnerability

Please report suspected vulnerabilities via

Please include where possible:

  • Product name and version
  • Affected component, module or feature
  • Clear description of the issue
  • Reproduction steps or proof of concept
  • Preconditions required for exploitation
  • Impact assessment
  • Whether you believe exploitation is publicly known or active in the wild
  • Your contact details and preferred name for acknowledgment

Receipt and Acknowledgement

We will confirm receipt of vulnerability reports within the timeframe we publish for this channel.

Our standard acknowledgement targets are:

  • High-severity or actively exploited reports: within 48 hours
  • All other in-scope reports: within 72 hours

Acknowledgement means we have received the report and opened it for review. It does not mean the report has yet been validated.

Intake and Triage Process

Each report is assessed through a documented intake-and-triage workflow.

Validation

We review whether the issue:

  • Is reproducible
  • Affects a supported version
  • Falls within scope
  • Represents a security vulnerability rather than a functional defect alone

Where a report cannot be reproduced, we will document the version(s), configuration and conditions tested.

Severity Assessment

We assess severity using an established scoring methodology such as:

  • CVSS v3.1
  • CVSS v4.0

We may apply environmental and product-context adjustments where appropriate.

Exploitability Assessment

We assess whether the issue is:

  • Supported only by theoretical analysis
  • Accompanied by a public proof of concept
  • Associated with a known exploit
  • Under active exploitation or observed in the wild

This assessment may affect escalation, remediation timelines and regulatory reporting obligations.

Scope Determination

We determine affected products and versions using available engineering records, dependency data, release records, and where applicable, software bill of materials (SBOM) data.

Safe Harbour for Good-Faith Research

We will not pursue legal action against researchers who:

  • Act in good faith
  • Avoid privacy violations, destruction of data and service disruption
  • Do not exploit the vulnerability beyond what is necessary to demonstrate its existence
  • Do not access, alter or retain customer data except where unavoidable and immediately reported
  • Follow this policy and provide us a reasonable opportunity to investigate and remediate

If you are unsure whether your research is in scope, contact us before proceeding further.

Nothing in this policy authorizes:

  • Access to production data beyond minimal proof
  • Social engineering, phishing or physical attacks
  • Denial-of-service or stress-testing against live production systems
  • Malware deployment
  • Extortion, ransom demands, or threats tied to disclosure

Out-of-Scope Activities

The following are generally out of scope unless explicitly authorized in writing:

  • Social engineering of employees, users, contractors or suppliers
  • Phishing or credential harvesting
  • Denial-of-service testing against live systems
  • Spam or abuse of public forms
  • Physical security attacks
  • Vulnerabilities in third-party platforms outside our operational control
  • Reports based solely on missing best practices without demonstrable security impact
  • Reports against unsupported or end-of-life versions, unless they also affect supported versions

Researcher Communications

We aim to maintain clear and respectful communication throughout the handling process.

Where possible, we will:

  • Confirm whether the report is in scope
  • Request clarification if needed
  • Provide status updates at reasonable intervals
  • Inform the reporter when remediation has been completed or a final decision has been made

We may credit reporters publicly, subject to their consent and our disclosure process.

Disclosure Expectations

We support coordinated disclosure.

Our general approach is:

  • We request that researchers refrain from public disclosure until a fix, mitigation or advisory is available
  • Our typical embargo period is until the patch ships
  • If remediation is delayed, the default hard backstop for coordinated disclosure is 90 days from acknowledgement, unless a shorter or longer period is justified by active exploitation, customer risk, legal obligations or coordination with affected parties

We may accelerate disclosure where:

  • There is active exploitation
  • Effective mitigations are urgently needed by users
  • Regulatory reporting or public warning obligations apply

We ask reporters to coordinate publication timing with us whenever possible.

Outcomes and Closure

Every report receives a final disposition. Typical outcomes include:

  • Fixed: issue remediated, with advisory and/or CVE where appropriate
  • Duplicate: issue already known or previously reported
  • Won’t fix: issue accepted as low risk, non-exploitable or not remediated for documented reasons
  • Out of scope: issue falls outside the policy scope

Where appropriate, the final response will include:

  • Affected and fixed version information
  • Mitigations or workarounds
  • CVE identifier if assigned
  • Advisory link if published
  • Rationale for closure where no fix is planned

Regulatory Escalation and Reporting

We maintain internal processes to determine whether a reported vulnerability triggers additional escalation, including regulatory reporting obligations.

Not every reported vulnerability requires external reporting. Escalation decisions may depend on factors such as:

  • Active exploitation
  • Severity and impact
  • Whether the issue constitutes a severe incident
  • Applicability of product security regulations

Regulatory assessments and notifications are handled through internal governance processes and may occur independently of public disclosure timing.

Privacy and Confidentiality

We handle vulnerability reports and associated personal data in accordance with our privacy and security obligations.

Please do not include unnecessary personal data in submissions. If access to personal or confidential data was unavoidable during testing, disclose that fact immediately and do not retain, copy or share the data beyond what is necessary for reporting.

Supported Versions

We investigate and remediate vulnerabilities in supported versions in accordance with our support lifecycle.

Reports affecting unsupported versions may be closed unless the same issue also affects a supported version.

Policy Availability

This policy is publicly available at: https://www.neoception.com/coordinated-vulnerability-disclosure/

Contact

For all vulnerability reports and questions regarding this policy, contact: security@neoception.com

Policy Review

We may update this policy from time to time to reflect changes in our products, processes, legal obligations, and industry practices. The current published version supersedes prior versions.

Last updated: 2026-10-01