Coordinated Vulnerability Disclosure Policy
Covering DA Drive Analyzer: Windows, macOS, ASUSTOR NAS App, and the ULINK Cloud AI Engine
Published in accordance with Regulation (EU) 2024/2847, Article 13(8) and Annex I, Section 2(5)
This document is intended for publication on ULINK's website, for example at security.ulink.com, and for reference from a security.txt file at /.well-known/security.txt on all ULINK web properties. It is written for an external audience: security researchers, users, and the wider community, not for internal ULINK staff. Internal escalation procedures live in the separate Incident Response Runbook.
Our Commitment
ULINK Technology Inc. takes the security of DA Drive Analyzer seriously. We welcome reports from security researchers, users, and anyone who discovers a potential vulnerability in our products, and we are committed to working with reporters in good faith to understand, verify, and remediate issues quickly.
This policy describes coordinated vulnerability disclosure: a process in which a reporter privately shares a vulnerability with us, we work together on a fix, and details are published once a remediation is available or a mutually agreed timeline has passed. We use this term, rather than the older phrase responsible disclosure, in line with current practice under ISO/IEC 29147, since it does not imply that a reporter acting differently is behaving irresponsibly.
This policy is maintained in accordance with the vulnerability handling obligations of the EU Cyber Resilience Act, Regulation (EU) 2024/2847, and follows the structure recommended by ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling processes).
Scope
In scope
This policy covers the following ULINK products and services:
| Product | Notes |
|---|---|
| DA Drive Analyzer for Windows | Both Cloud mode and Standalone mode |
| DA Drive Analyzer for macOS | Both Cloud mode and Standalone mode |
| DA Drive Analyzer for ASUSTOR NAS | Cloud mode |
| ULINK Backend and Cloud AI Engine | The backend service used by all Cloud mode deployments, including its APIs and telemetry processing |
| ULINK websites | ulink-da.com, ulinkda.com and any subdomains used to distribute or support DA Drive Analyzer |
Out of scope
The following are outside the scope of this policy. Reports concerning them will not receive a substantive response through this channel.
- DA Drive Analyzer for QNAP NAS. QNAP maintains its own security disclosure process for applications distributed through QNAP App Center; please report issues in that deployment directly to QNAP.
- Denial-of-service testing against production infrastructure, including the ULINK Cloud AI Engine.
- Social engineering, phishing, or physical attacks against ULINK staff, offices, or facilities.
- Automated, high-volume vulnerability scanning that degrades service for other users.
- Vulnerabilities in third-party infrastructure that ULINK does not operate, including cloud hosting providers, even where DA Drive Analyzer runs on that infrastructure.
- Reports based solely on automated scanner output without a demonstrated, product-specific impact.
- Issues that require physical access to a user's device.
Testing must not access, modify, or destroy data that does not belong to you, must not degrade service for other users, and must stop immediately if you encounter data belonging to someone else. If you believe you have accessed personal data during testing, stop and notify us immediately at the contact below rather than continuing to investigate.
How to Report a Vulnerability
Reporting channels
You may report a vulnerability through either of the following channels, whichever you prefer:
| Channel | Detail |
|---|---|
| cra.team@ulinktech.net | |
| Web form | ulink-da.com/security/report |
Both channels are monitored continuously by a human security team member; neither is an automated-only intake. Please do not use general customer support channels for security reports, since they are not routed to our security team and may delay handling.
What to include
A useful report significantly speeds up triage. Where possible, please include:
- The affected product and, if known, the specific version and platform (Windows, macOS, or ASUSTOR NAS)
- A clear description of the vulnerability and its potential impact
- Step-by-step reproduction instructions
- Proof-of-concept code, screenshots, or network captures, where applicable
- Whether you have tested against production systems, and if so, what data or accounts were involved
- Whether you intend to publish details independently, and if so, on what timeline
You do not need to provide your legal name to submit a report. If you would like recognition for a valid report, see the Recognition section below.
What Happens After You Report
Our process follows five stages, consistent with the vulnerability handling lifecycle described in ISO/IEC 30111.
| Stage | What we do |
|---|---|
| 1. Acknowledge | A member of our security team personally reviews and acknowledges your report. We do not use automated-only responses for this step. |
| 2. Validate | We attempt to reproduce the issue and confirm its scope and severity, scored using CVSS v4.0. |
| 3. Remediate | We develop and test a fix, or an interim mitigation if a full fix will take longer. We may contact you with follow-up questions during this stage. |
| 4. Deploy | We release the fix to affected platforms and, for actively exploited or high-severity issues, follow our obligations under the EU Cyber Resilience Act to notify ENISA within the required timeframes. |
| 5. Disclose | We publish a public security advisory describing the issue once a fix is available, and coordinate timing with you if you plan to publish your own writeup. |
Response timeline commitments
These are internal targets we hold ourselves to. They are not a substitute for the legal deadlines that apply to us under the Cyber Resilience Act where a vulnerability is actively exploited; those are handled through our own regulatory reporting process regardless of this policy.
The acknowledgement and severity assessment targets below describe how quickly we aim to communicate substantively back to you. They do not describe how quickly we recognise a report internally. Any report indicating evidence of active exploitation is flagged immediately, independent of this timeline, for emergency classification under our internal incident response process, since the Cyber Resilience Act requires us to notify ENISA within 24 hours of becoming aware of such a vulnerability. You do not need to wait for a formal acknowledgement for that internal process to begin.
| Milestone | Target | Notes |
|---|---|---|
| Acknowledgement | 5 business days | A human response confirming we have received your report |
| Initial severity assessment | 10 business days from acknowledgement | CVSS v4.0 score and validation outcome |
| Remediation, Critical severity | 30 days from validation | CVSS 9.0 or above |
| Remediation, High severity | 60 days from validation | CVSS 7.0 to 8.9 |
| Remediation, Medium severity | 90 days from validation | CVSS 4.0 to 6.9 |
| Remediation, Low severity | 180 days from validation | CVSS 0.1 to 3.9 |
Coordinated Disclosure Timeline
We ask that you give us 90 days from the date of your report before publishing details publicly. This is a widely used industry default, not a requirement set by the Cyber Resilience Act, and we are willing to discuss a different timeline where it is justified, for example a shorter period for an actively exploited issue that already poses immediate risk to users, or a longer period for a complex fix that requires coordinated changes across multiple platforms.
If we are unresponsive, or if 90 days pass without a fix or clear progress and without agreement on an extension, you are free to publish in accordance with the principles of coordinated disclosure. We ask that any public writeup avoid including exploit details that would allow immediate misuse before affected users have had a reasonable opportunity to update.
Once a fix is available, we publish our own security advisory describing the issue, the affected versions, and the remediation. We are glad to coordinate the publication date with you if you plan to publish independently.
Safe Harbour
ULINK Technology Inc. will not pursue legal action against, or support third-party legal action against, a researcher who:
- Makes a good-faith effort to comply with this policy
- Reports a vulnerability through the channel described above
- Avoids privacy violations, service disruption, and destruction of data
- Does not exploit a vulnerability beyond what is necessary to demonstrate it
- Gives us a reasonable opportunity to investigate and remediate before any public disclosure
This commitment applies regardless of whether we agree with every detail of a report's severity assessment or timeline expectations, provided the researcher's conduct stayed within the scope and testing limits described in this policy.
The Cyber Resilience Act itself does not mandate a specific safe harbour clause; this commitment reflects our own policy and current industry good practice under ISO/IEC 29147 and CISA's joint guidance on coordinated vulnerability disclosure programmes.
Recognition
We do not currently operate a paid bug bounty programme. We are, however, glad to publicly credit researchers who submit valid, in-scope reports in our published security advisories, provided the researcher consents to being named. If you would prefer to remain anonymous or to be credited under a handle rather than your legal name, let us know when you report.
Vulnerability Identifiers
We assign every confirmed report an internal reference identifier so that you and we can track its progress through our process. If your report concerns an actively exploited vulnerability or a severe security incident and we are required to notify ENISA under the Cyber Resilience Act, that notification receives its own reference number from the ENISA Single Reporting Platform, which we can share with you on request.
Policy Governance
| Field | Detail |
|---|---|
| Policy owner | ULINK Technology Inc., Security Incident Response Lead |
| Legal basis | Regulation (EU) 2024/2847, Article 13(8) and Annex I, Section 2(5) |
| Standards referenced | ISO/IEC 29147 (vulnerability disclosure), ISO/IEC 30111 (vulnerability handling) |
| Version | 1.0 |
| Effective date | 11 September 2026 |
| Review cadence | Annually, and after any material change to affected products or the ULINK backend and Cloud AI Engine |
| Publication location | security.ulink.com.tw, referenced from /.well-known/security.txt on all ULINK web properties |
| Contact | cra.team@ulinktech.net or security.ulink.com.tw/report |
