Coordinated Vulnerability Disclosure Policy

1. Purpose

YTL values the cybersecurity of its products and continuously works to improve their security. The YTL Product Security Incident Response Team (PSIRT) receives, handles and discloses security vulnerabilities affecting our products. We welcome security researchers, customers, partners, suppliers and other parties to report, in good faith and in a coordinated manner, potential cybersecurity vulnerabilities that may affect our products.

This policy sets out the scope, reporting channels, recommended report content, acknowledgment timelines, secure communication methods, ongoing communication arrangements, vulnerability handling principles and coordinated disclosure approach. We register, verify, assess, remediate, test and publish vulnerabilities according to our internal vulnerability handling process, and we work to minimise the impact of vulnerabilities on users and affected parties.

Our process is aligned with the principles of ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling processes), in addition to the essential requirements of the EU Cyber Resilience Act (Regulation (EU) 2024/2847).

2. Scope

This policy applies to the following products of YTL that are within their support period, and to their supported versions:

• Software products and applications, and digital products with network connectivity.
• Hardware products that contain software, firmware or network communication functions.
• Software components, mobile applications, cloud services and management tools shipped with products, but only the parts maintained by YTL.

Specific product names, models, supported versions and end-of-support dates are set out in the product support pages, product documentation or lifecycle statements. For products that are no longer supported or have reached end of life, we will still accept reports and assess them according to impact, user risk, technical feasibility and available compensating measures.

Vulnerabilities in third-party components may also be reported through this policy. We will coordinate with the relevant suppliers, open-source project maintainers, coordination bodies and other stakeholders according to the responsibility boundary.

3. Reporting Channels

Please report potential vulnerabilities through any of the following channels. Reports received through ordinary channels will not be rejected; when follow-up communication requires transferring exploit code, customer data, keys, configuration files or other sensitive material, we will agree with the reporter on a move to a secure communication channel.

Machine-readable security contact information is available in our security.txt file (RFC 9116).

Reporters may report anonymously. Anonymous reports may limit our ability to request additional information or provide progress updates, but will not affect the registration and initial assessment of the report.

4. Secure Communication

When a report contains PoC, exploit code, logs, configuration, customer data, credentials, keys or other sensitive information, please use the following secure methods where possible:

• Contact us by email and we will arrange a secure channel for sensitive material.
• Encrypt email or attachments using our published OpenPGP public key.

Secure communication should protect both the confidentiality and the integrity of the transmitted content. If a reporter cannot use the secure methods above, we will still accept the report and agree on other available and accessible communication methods as appropriate.

5. What to Include

To help us verify and handle the vulnerability in a timely manner, the report should ideally include the following information. Incomplete information will not cause the report to be rejected; we may contact the reporter to request additional material as needed.

• Reporter name, organisation and contact information.
• Affected product name, model, hardware identifier, software or firmware version, and related components.
• Vulnerability description, discovery date, affected functions and potential security impact.
• Reproduction steps, test environment, preconditions and reproduction results.
• PoC, screenshots, logs, network captures or other verification material.
• Temporary mitigation measures taken or suggested.
• Whether the vulnerability has been reported to other manufacturers, coordination bodies or related parties.
• Expected public disclosure date, and whether you agree to be acknowledged in the security advisory.

6. Acknowledgment and Ongoing Communication

We will handle external vulnerability reports according to the following schedule. Actual timing may vary with vulnerability complexity, report completeness, supply-chain coordination, and remediation development and testing cycles. If we cannot meet the timelines below, we will explain the current status and next steps to the reporter.

The tracking ID should be used consistently in follow-up emails, tickets, meeting notes and security advisories, so that reporters and related parties can identify the same vulnerability matter.

7. Vulnerability Handling Principles

After receiving a report, we carry out the following activities according to our internal vulnerability handling process:

• Register the report and restrict non-public vulnerability information to personnel authorised by need-to-know.
• Verify the vulnerability and identify affected products, versions and components.
• Assess exploitability, severity, user impact and supply-chain impact, using the Common Vulnerability Scoring System (CVSS) for severity scoring.
• Define a remediation, mitigation or risk-acceptance plan, and complete the necessary development and testing.
• Coordinate security updates, mitigation measures, security advisories and notifications to affected parties.
• Continue to monitor remediation effectiveness and related vulnerability information after publication.
• Continuously improve product security and the vulnerability handling process based on lessons learned.

While handling non-public vulnerability information, we apply appropriate access control, confidentiality marking and secure communication measures to prevent sensitive information from unauthorised access, modification or premature disclosure.

8. Coordinated Disclosure Principles

We apply coordinated vulnerability disclosure. Reporters, relevant suppliers, open-source project maintainers, coordination bodies and other affected parties should, as far as possible, keep non-public technical details of a vulnerability confidential until a fix or effective mitigation is available.

The disclosure date and coordination period are determined after initial verification, based on the following factors, and communicated to the reporter and related parties:

• Vulnerability severity, exploitability and real-world attack activity.
• Affected products, versions, number of users and deployment environment.
• Time required for remediation development, testing, publication and user deployment.
• Complexity of coordination with upstream suppliers, downstream customers, open-source projects or multiple parties.
• Whether early disclosure would significantly increase user risk.

As a general target, once a fix or effective mitigation is available, we aim to publish a public advisory within 90 days, subject to the factors above.

In line with the CRA, where a vulnerability affecting our products is actively exploited, we will fulfil our mandatory reporting obligations to the European cybersecurity authorities: an early warning within 24 hours and a vulnerability notification within 72 hours, submitted through the relevant reporting channel (ENISA / CSIRTs). This reporting runs in parallel with, and does not replace, our coordination with the reporter.

If an agreed disclosure date needs to change, we will explain the reason and re-coordinate with the relevant parties. Where remediation information could be used directly by attackers and the risk of early disclosure outweighs the security benefit, full technical details may be delayed; we will provide affected users with the necessary mitigation information that does not increase exploitation risk, and notify the planned disclosure date.

9. Security Advisories and Remediation Information

After a vulnerability is remediated or an effective mitigation is available, we may publish information through the website security advisories, product security notices, customer emails, release notes or security update announcements. Security advisories will include, as applicable:

• Vulnerability description and identifiers, such as internal ID, CVE or other coordination IDs.
• Affected products, models, software or firmware versions.
• Potential impact and severity.
• Remediation version, update method, mitigation measures and installation instructions.
• First publication date, update date and any necessary disclosure notes.

View security advisories

10. Reporter Guidelines

To avoid unnecessary impact on users, products and business, reporters should observe the following rules:

• Do not conduct unauthorised testing against production environments.
• Do not disrupt the normal operation of products.
• Do not access, modify or disclose user data.
• Do not carry out denial-of-service attacks or implant malicious code.
• Do not exceed the minimum scope necessary to verify the vulnerability.
• Keep non-public vulnerability information confidential.

11. Good-Faith Research and Safe Harbor

For vulnerability reports made in good faith, within the scope of this policy and the guidelines above, and with the aim of improving product security, we will handle them cooperatively and will make reasonable efforts not to pursue legal action in respect of such good-faith research.

This statement does not apply to unlawful access, obtaining data beyond authorised scope, malicious attacks, concealing or disclosing sensitive information, extortion, actions affecting customer business continuity, or actions that may create personal-safety risk. If you have doubts about the scope of testing, please confirm with us through the security email before testing.

12. Privacy and Data Protection

We process the contact information and materials provided by reporters only for the purpose of receiving, verifying, handling and coordinating the disclosure of vulnerabilities, and we take measures in line with applicable data-protection requirements. Please avoid submitting personal data or customer data that is not relevant to vulnerability verification. To request deletion, correction or restriction of processing of personal information, please contact us via our Privacy Policy contact details.

13. Acknowledgment

Where the reporter agrees, and where permitted by law, contract and confidentiality obligations, we may publish the reporter’s name, alias or organisation in a security advisory or acknowledgment page. Reporters may choose to remain anonymous or explicitly decline public acknowledgment.

Recognition, where granted, is at our discretion and is conditional on full compliance with this policy. It will only be considered after the vulnerability has been fully resolved and disclosed in coordination with us. YTL does not operate a cash-based bug bounty program.

14. Policy Updates

We review and update this policy regularly according to regulatory and standard requirements, product lifecycle, vulnerability-handling experience and communication-mechanism changes. Updated versions will be published on the security page of our official website, with a version number and update date. Material changes may be notified to relevant users and stakeholders through appropriate channels.