Veethree Technologies – Vulnerability Disclosure Policy

1: Introduction

Veethree Technologies is committed to the security of the products we manufacture. We value the work of security researchers and members of the public who report potential vulnerabilities to us, and we are committed to working with them to understand and resolve issues quickly.

This policy applies to products with digital elements placed on the market by Veethree Technologies that fall within the scope of Regulation (EU) 2024/2847 (the Cyber Resilience Act, “CRA”).

2: How to report a vulnerability

If you believe you have found a security vulnerability in one of our in-scope products, please report it to:

vt-security@veethree.com 

This can be reported anonymously by creating a sacrificial email address with a privacy focused provider. Please include the following otherwise we will be unable to triage accurately and the issue may be closed without a sufficient resolution:

• A description of the product and where the vulnerability was found
• We need to determine the root of the vulnerability, be it our own or a third party’s
• Product hardware and software versions
• What the vulnerability is, its type category
• When did you become aware of the vulnerability (approximate date is fine)
• Severity assessment
• Steps to reproduce, or a proof of concept
• Evidence and supporting material images, logs, packet captures. Whatever demonstrates the issue
• We will not accept binaries or executables, reports containing these will be rejected
• If referencing an external source (e.g. a public disclosure or CVE entry) name it in text rather than as a clickable link
• The potential impact of the vulnerability, if known
• Whether the vulnerability is already public or has been disclosed elsewhere
• Evidence that it is being actively exploited
• We require assurances to ensure we’re not getting anything wrong
• A note of the scope of the test
• Was this tested against a live device?

3: What to expect

We will review all reports received at this address. Reports concerning an actively exploited vulnerability or a severe incident should be flagged as such in the subject line, so they can be identified and progressed as soon as possible (see Section 4). Other reports will be triaged in the order received.

We do not commit to a fixed response time, but all reports will be triaged and dealt with as soon as we can.

4: Handling of actively exploited vulnerabilities and severe incidents

Where a report is flagged, or is otherwise identified, as relating to an actively exploited vulnerability or a severe incident affecting an in-scope product, our internal process applies, in line with Article 14 of the CRA.

4.1 Becoming aware

We are considered to have become “aware” of an actively exploited vulnerability or severe incident when we have a reasonable degree of certainty that (i) a vulnerability in an in-scope product is being actively exploited or (ii) a severe incident has occurred affecting the security of an in-scope product.

Where a report is received indicating either of these, a short initial assessment will be carried out as soon as possible to establish this degree of certainty.

Our best efforts are on getting this triaged, we aim to progress from initial assessment to notification as quickly as our resources allow.

4.2 Early warning (within 24 hours)

Once aware, an early warning notification will be submitted within 24 hours via the ENISA Single Reporting Platform, to the CSIRT designated as coordinator for Veethree Technologies indicating:

• That an actively exploited vulnerability or severe incident has been identified
• The Member States where the affected product has been made available, where known
• For severe incidents, whether it is suspected to be caused by unlawful or malicious acts

4.3 Follow-up notification (within 72 hours)

Unless the relevant information has already been provided, a follow-up notification will be submitted within 72 hours of becoming aware, providing:

• General information about the product concerned
• The general nature of the exploit/vulnerability or for a severe incident, the nature of the incident and our initial assessment of it
• Any corrective or mitigating measures taken or available
• Guidance for users on mitigating steps they can take
• An indication of how sensitive we consider the notified information to be

4.4 Informing Impacted Users

Independently of the notifications to authorities under Sections 4.2 & 4.3, once aware of an actively exploited vulnerability or severe incident we will inform all impacted users, without undue delay (unless notification causes further risk), of:

• The nature of the vulnerability or incident
• Any mitigating or corrective measures users can take in the interim, where a fix is not yet available (e.g. workarounds, configuration changes)

This is provided ahead of the full public disclosure (Section 5), where the interim information is sensitive or a fix is not yet ready, so that affected users are not left without guidance while remediation is in progress.

4.5 Final report

4.5.1 Vulnerability

Once a corrective or mitigating measure is available, a final report will be submitted no later than 14 days afterward, including:

• A description of the vulnerability, its severity, and impact
• Details of any known malicious actor who exploited or is exploiting it, where available
• Details of the security update or other corrective measure made available

4.5.2 Severe incident

If a severe incident is reported as under Article 14, the final report will be made one month after submitting the 72h report.

4.6 Where no mitigation is available

The CRA does not specify a deadline or process for cases where no corrective or mitigating measure ever becomes available. Our approach in this case:

• The 72-hour follow-up notification will explicitly state that no mitigation is currently available, along with any interim guidance we can offer users (e.g. workarounds, configuration changes, discontinuing use)
• We will not artificially delay the 72-hour notification while waiting for a fix
• If a mitigation later becomes available, the final report will be submitted within 14 days of that point, per Section 4.5.1
• If no mitigation is available at the time of the 72-hour notification, remediation work will continue as an ongoing obligation under Annex I Part II of the CRA. Users will be informed via the public disclosure process (Section 5) and where necessary interim notifications (Section 4.4) once a fix becomes available and progress will be documented internally in the interim
• Where remediation is not possible and the vulnerability poses a significant risk, as stated in Article 13 the affected product may be withdrawn or recalled in coordination with the relevant market surveillance authority

5. Public disclosure

Once a security update or other corrective measure is available for a reported vulnerability, we will publish information about it, including a description of the vulnerability, affected products, its severity and impact, and guidance for users, in accordance with Annex I, Part II, point 4 of the CRA.

Where the security risk of publishing this information outweighs the benefit (for example, where publishing before users can patch would increase risk), we may delay disclosure until users have had a reasonable opportunity to apply the update.

6. Reporting to authorities

Where we are required we will report to the relevant CSIRT via the ENISA platform in accordance with our internal process.

We will work in cooperation with our customers’ and suppliers’ Vulnerability Disclosure Policies in order to mitigate and remediate any potential vulnerabilities or severe incidents.

7. Scope limitations

• This policy applies only to products with digital elements, which includes existing products
• We do not offer financial rewards for vulnerability disclosures
• Reports outside the above criteria (e.g. non-exploited vulnerabilities, general security suggestions) are welcomed but are not subject to the timelines in Section 4, and will be triaged as capacity allows

8. Legal

This policy does not authorise any activity that would otherwise be unlawful. Reporters must comply with all applicable laws when identifying or reporting vulnerabilities.