Coordinated Vulnerability Disclosure (CVD) Policy

Copyright © 2026 Mech-Mind Robotics Technologies Co., Ltd. All Rights Reserved

---

1. Purpose

Mech-Mind Robotics Technologies Co., Ltd. (hereinafter referred to as "the Organization") is committed to ensuring the security of its products with digital elements, and complying with relevant requirements of the EU Cyber Resilience Act (Regulation (EU) 2024/2847).

This Coordinated Vulnerability Disclosure (CVD) policy establishes a process for external security researchers, customers, suppliers, coordinators and the general public to report potential security vulnerabilities in the Organization's products. It also clarifies the Organization's responsibilities and commitments for handling and disclosing such vulnerabilities.

---

2. Scope

2.1 Products and Services in Scope

The following products, systems and services are covered by this policy:

• Mech-Eye Series 3D Industrial Camera (including firmware and supporting SDK; support period: 5 years from product release)
• Mech-Eye 3D Laser Profiler (including firmware and supporting SDK; support period: 5 years from product release)
• Mech-Vision Machine Vision Software Platform (support period: 5 years from the release date of each major version)
• Mech-Viz Intelligent Robot Programming Environment (support period: 5 years from the release date of each major version)
• Mech-MSR 3D Measurement and Inspection Software (support period: 5 years from the release date of each major version)
• Mech-DLK Deep Learning Software (support period: 5 years from the release date of each major version)
• Mech-Metrics Data Monitoring and Analytics Platform (support period: 5 years from the release date of each major version)
• Mech Mind Official Websites and Online Services - www.mech-mind.com / mech-mind.com.cn

2.2 Out of Scope

The following are not covered by this policy:

• Issues in third-party products, services, or infrastructure that are not owned or operated by the Organization
• Social-engineering, phishing, or physical security attacks
• Denial-of-Service (DoS) or Distributed Denial-of-Service (DDoS) attacks
• Vulnerabilities in products that have reached end-of-life and are no longer supported with security updates by the Organization
• Vulnerabilities already known to the Organization or actively being remediated
• Functional defects or user-experience issues that pose no security risks

---

3. Legal Safe Harbor

The Organization commits that it generally will not initiate legal action or report to law enforcement authorities for security research activities conducted in good faith, in strict compliance with the requirements of this policy, in a non-destructive manner, and within the scope authorized by this policy.

Nevertheless, the Organization reserves the right to take necessary measures and make reports as required by law, including but not limited to:

• Reporting or relevant action is mandated by applicable laws and regulations
• Research activities exceed the scope defined in this policy
• Research has caused or is likely to cause harm to users, systems or data
• Activities involve extortion, malicious vulnerability exploitation, unauthorised disclosure of vulnerability information, unauthorised data access or service disruption

This safe harbor protection is subject to the reporter:

• Strictly limiting operations to the minimum necessary to verify the existence of the vulnerability
• Not accessing, modifying, deleting or disclosing the data of other users
• Not exploiting the vulnerability to gain access beyond what is necessary for verification purposes
• Maintaining good-faith, effective communication and cooperation with the Organization

---

4. How to Report a Vulnerability

The Organization encourages reporters to submit vulnerability reports via its designated security channels. Reports submitted via non-designated channels (e.g. general-purpose email) will also be received and processed by the Organization.

4.1 Submission Channels

Vulnerability reports may be submitted via the following channels:

security.txt: https://www.mech-mind.com/.well-known/security.txt

PGP key fingerprint: Available at https://www.mech-mind.com/security/pgp-key

4.2 Report Contents

To facilitate efficient triage, reporters are encouraged to provide as much of the following information as practicable:

1. Affected Products: Product name, version, platform and/or URL
2. Vulnerability Description: Detailed account of the vulnerability and its potential impacts
3. Reproduction Steps: Step-by-step instructions, including details of the tools and environment
4. Supporting Evidence: Screenshots, network captures, logs or Proof-of-Concept (PoC) code
5. Severity Assessment: Optional CVSS v3.1 or v4.0 score
6. Contact Information: Email address or other valid means for follow-up communications

4.3 Anonymous Reports

Reporters may submit vulnerabilities anonymously via the secure web form. Anonymity, however, may limit the Organization's ability to provide follow-up communications or public recognition.

---

5. Vulnerability Handling Workflow

5.1 Receipt

Upon receiving a vulnerability report, the Organization will:

• Acknowledge receipt within 7 working days
• Assign a unique vulnerability-tracking identifier (e.g., MM-VULN-YYYY-NNNN)
• Provide the reporter with initial contact details from its Product Security Incident Response Team (PSIRT)

5.2 Validation

Following acknowledgement of receipt, the PSIRT will complete its initial assessment within 15 working days. During this stage, the Organization will:

• Validate the vulnerability and attempt to reproduce it
• Assess vulnerability severity using CVSS v3.1 or v4.0
• Identify affected products and versions
• Assign an internal processing priority based on risk evaluation

If the information provided in the report proves insufficient for reproduction, the PSIRT will contact the reporter to request supplementary details.

5.3 Vulnerability Risk Assessment

After validation, the Organization will conduct a risk assessment to determine the potential impact, severity and handling priority of the vulnerability.

The Organization will inform the reporter of validation results and the assigned vulnerability handling priority.

5.4 Remediation

For validated vulnerabilities, the Organization will formulate, develop, and test appropriate fixes or risk-mitigation measures. Remediation measures may include (but are not limited to):

• Security Patches: Software updates that directly resolve the vulnerability
• Firmware Updates: Security firmware updates for Mech-Eye hardware devices
• Configuration Changes: Product configuration changes that reduce vulnerability risks
• Mitigation Guidance: Temporary risk-reduction guidance for users before a complete remediation is available
• End-of-Life Notification: Notification for relevant users if the affected product is no longer supported for security updates

If the Organization cannot deliver a fix within the target timeframe, it will promptly notify the reporter, provide a revised schedule and temporary mitigation measures.

5.5 Remediation Testing

Before releasing remediation measures, the Organization will conduct necessary testing of all remediation measures, including but not limited to:

• Functional Testing: Verify that the fix has resolved the reported vulnerability
• Regression Testing: Ensure that the remediation does not adversely affect product functionality
• Compatibility Testing: Validate that the fix is applicable to the affected product versions

5.6 Release and Disclosure

After remediation is completed, the Organization will:

1. Notify the reporter that the vulnerability has been resolved
2. Publish a security advisory or release note, where applicable
3. Credit the reporter in public advisories with the reporter's consent
4. Update security documentation for affected products

The Organization supports Coordinated Vulnerability Disclosure. Prior to public disclosure, the Organization will negotiate the following items with the reporter:

• The public disclosure date
• The content of the public advisory or statement
• The embargo period required to protect users

Note: The embargo period will be negotiated between the Organization and the reporter on a case-by-case basis.

Organizational security advisories will normally contain:

• Vulnerability Description: Symptom, root-cause analysis, and assigned CVE identifier (if available)
• Severity Assessment: CVSS v3.1/v4.0 score and corresponding risk level
• Affected Products: List of impacted product models and software-firmware version ranges
• Mitigations: Temporary protective measures or workarounds to apply before patch installation
• Remediation: Download locations and installation instructions for patch/firmware-update packages
• Acknowledgements: Credit for the vulnerability discoverer with the reporter's consent

The Organization aims to complete the coordinated disclosure process within 90 calendar days from the date of acknowledgment of the report. If this timeframe cannot be met, the Organization will notify the reporter and agree on a revised disclosure date.

5.7 Post-Release Actions

After a security update is released, the Organization will:

• Monitor all issues related to released remediation measures
• Verify that the vulnerability has been effectively resolved
• Update the final status of the vulnerability record
• Conduct lessons-learned reviews for critical vulnerabilities

---

6. Ongoing Communications

The Organization commits to maintaining regular communications with reporters and stakeholders throughout the vulnerability handling process:

• Acknowledgement of Receipt: Acknowledge receipt within 7 business days after receiving a vulnerability report
• Progress Updates: Provide the reporter with a progress update at least once every 30 calendar days while the vulnerability is being handled
• Validation Results: Provide the reporter with the assessment results after completion of the initial assessment
• Remediation Timeline: Communicate the expected remediation timeline with the reporter after completion of the risk assessment
• Resolution Notification: Notify the reporter when the security remediation is released
• Public Disclosure: Publish relevant advisories through the Organization's security channels

Security channels include email, web portals and other accessible communication methods as appropriate.

---

7. Confidentiality

The Organization will keep vulnerability reports confidential. Except as otherwise required by applicable laws or regulations, the Organization will not share personal information provided by the reporter with third parties without the reporter's explicit consent.

---

8. Data Protection and Privacy

When processing vulnerability reports, the Organization may collect personal information submitted by reporters (such as name and email address). The Organization commits to processing such personal data in accordance with the following principles:

• Legal Basis: The reporter's personal data is processed on the basis of the legitimate interest in maintaining product security
• Data Minimization: Only personal information necessary for processing the vulnerability report will be collected
• Retention Period: The reporter's personal data will be retained for 3 years after the vulnerability is closed and will then be securely deleted
• Data subject rights: Reporters have the right to request access to, correction of, or deletion of their personal data by contacting security@mech-mind.net
• Data Sharing: Unless otherwise required by applicable laws or regulations, the Organization will not transfer personal data to third parties without the reporter's explicit consent. For example, when reporting relevant security incidents to ENISA, only necessary technical information will be provided, without the reporter's identifying information
• International Data Transfers: If data needs to be transferred to a country or region outside the EU, the Organization will ensure that such transfers comply with the requirements of Chapter V of the GDPR

For questions regarding data protection, please contact privacy@mech-mind.net

---

9. Handling of Non-Vulnerability Reports

If the PSIRT determines after validation that a reported issue does not constitute a security vulnerability, the following actions will be taken:

1. Reporter Notification: Inform the reporter of the outcome within 5 working days after completion of the validation
2. Rejection Justification: Provide the reporter with specific reasons for non-acceptance (e.g. non-security issues, known defects, out-of-scope under this policy)
3. Reassessment: If the reporter disagrees with the PSIRT conclusion, supplementary information may be submitted within 15 working days after receiving the notification and request a reassessment
4. Record Closure: Mark the report as closed within the vulnerability management system and record its final status

Common grounds for non-vulnerability classification include:

• The reported behaviour is a functional design product feature, rather than a security defect
• The reported issue is outside the scope of this policy (see Section 2.2)
• The issue could not be reproduced and the reporter has not provided additional information
• The reported vulnerability has already been remediated or is currently being remediated

---

10. Recognition and Rewards

The Organization currently does not operate a vulnerability bounty program. For reporters who responsibly disclose valid vulnerabilities, the Organization may provide the following forms of recognition or rewards:

• Public acknowledgement on the Organization's security acknowledgments page with the reporter's consent
• Souvenirs or other non-monetary rewards, at the Organization's discretion

All forms of recognition or rewards are determined by the Organization at its sole discretion and are subject to the reporter's compliance with this policy. Reports submitted in violation of this policy are not eligible for recognition or rewards.

---