Product licenses and terms of use

Coordinated Vulnerability Disclosure Policy

Version 1.0
Effective date: June 24, 2026.

1. Purpose

Skylum is committed to maintaining the security, integrity and resilience of its products, services and supporting systems. Skylum values the contribution of independent security researchers, customers, partners and other members of the security community who identify and responsibly report potential security vulnerabilities.

This Coordinated Vulnerability Disclosure Policy establishes a structured process for reporting, assessing, remediating and disclosing security vulnerabilities. It is intended to support compliance with Regulation (EU) 2024/2847, the Cyber Resilience Act, including the vulnerability-handling requirements applicable to manufacturers of products with digital elements.

2. Scope

This Policy applies to security vulnerabilities affecting products with digital elements developed, supplied or maintained by Skylum.

The scope includes currently supported Skylum desktop and mobile applications, plugins, extensions, websites, customer accounts, licensing and activation services, application programming interfaces, cloud-based functionality, software distribution systems, update mechanisms and other infrastructure operated by Skylum in connection with its products.

A vulnerability in a third-party product, service, platform, library or infrastructure is not ordinarily within scope where the affected system is not operated or controlled by Skylum. Where a vulnerability results from Skylum’s implementation, configuration or integration of a third-party component, Skylum will assess the matter and, where appropriate, coordinate with the relevant component manufacturer, maintainer or service provider.

Reports concerning products that are no longer within their published support period may be assessed at Skylum’s discretion, taking account of the severity of the issue, the number of potentially affected users, the feasibility of remediation and any continuing legal or contractual obligations.

3. How to report a vulnerability

Security vulnerabilities should be reported by email to [email protected].

The subject line should begin with “Security Vulnerability” and identify the affected product or service where known.

A reporter who is unable to use email may submit a report by post to Shinyfields Limited, Attention: Information Security, 4 Spyrou Kyprianou, Office 401, 4001 Mesa Geitonia, Limassol, Cyprus.

Reports may be submitted using the reporter’s name, a pseudonym or anonymously. Skylum may be unable to acknowledge, investigate collaboratively or provide status information in relation to a fully anonymous report that does not include a secure return communication channel.

A report should provide sufficient information for Skylum to reproduce and assess the issue. Relevant information ordinarily includes the affected product or service, version or build number, operating system or environment, vulnerability type, technical description, reproduction steps, proof-of-concept material, potential impact, prerequisite conditions, relevant logs or screenshots, suggested remediation and details of any prior or intended disclosure. Reporters should remove or redact personal data, authentication credentials, customer content and other information that is not necessary to demonstrate the vulnerability.

4. Good-faith security research

Research will be treated as good-faith research where it is conducted solely to identify, verify and report a security vulnerability, avoids unnecessary harm, complies with this Policy and applicable law, and is not undertaken for financial coercion, competitive advantage, disruption or any other improper purpose.

Researchers should use accounts, devices, licenses, content and data that they own or are expressly authorized to use. Testing should be limited to the minimum activity reasonably necessary to confirm the existence and potential impact of a vulnerability.

If a researcher unexpectedly accesses personal data, customer content, confidential business information, credentials or other sensitive information, the researcher should stop testing, avoid further access, notify Skylum promptly and follow Skylum’s reasonable instructions concerning secure deletion or preservation. Sensitive information should not be downloaded, copied, retained, altered or disclosed except to the minimum extent necessary to provide Skylum with evidence of the vulnerability.

Researchers should not establish persistence, modify or delete data, access another user’s account, execute code on another person’s device, interfere with product availability or degrade the performance of any Skylum or third-party system.

5. Prohibited testing

This Policy does not authorize denial-of-service or resource-exhaustion testing, destructive testing, high-volume automated scanning, credential stuffing, password spraying, brute-force activity, malware deployment, ransomware simulation, physical intrusion, social engineering, phishing, impersonation, spam or testing that may affect the confidentiality, integrity or availability of systems or data belonging to another person.

This Policy does not authorize testing of Skylum employees, contractors, offices, communications systems, suppliers, hosting providers, payment processors, analytics providers, application stores or other third parties unless Skylum has provided prior written permission for the specific test.

Researchers must not demand payment, threaten disclosure, withhold technical details as leverage, sell access to a vulnerability or use a vulnerability to obtain a commercial or personal benefit.

6. Matters ordinarily outside scope

Skylum may close a report as informational or outside scope where the reported condition does not create a demonstrable security impact.

Examples may include missing security headers without a practical exploit, clickjacking on pages that do not perform sensitive actions, self-cross-site scripting, user or email enumeration with no material consequence, rate-limiting observations that do not enable account compromise or service disruption, outdated browser behavior, publicly available information, non-sensitive version disclosure, theoretical weaknesses without a viable attack path and vulnerabilities that require an already fully compromised device.

Product defects, application crashes that do not create a security impact, feature requests, licensing disputes, software piracy issues, content moderation matters, image-processing quality, artificial-intelligence output quality, copyright complaints and general privacy enquiries are not handled under this Policy. An issue involving an artificial-intelligence feature is within scope only where it causes a demonstrable failure of a security boundary or compromises the confidentiality, integrity or availability of a Skylum product, system or user’s data.

A decision that a report is outside scope does not prevent Skylum from addressing the underlying issue through its product-quality, privacy, legal, fraud-prevention or customer-support processes.

7. Safe-harbor statement

To the extent permitted by applicable law, Skylum does not intend to initiate legal action or request a law-enforcement investigation against a researcher for accidental or technically necessary conduct performed in good faith and in accordance with this Policy.

Skylum will consider activity compliant with this Policy to constitute authorized security research in relation to systems controlled by Skylum. Where a researcher is uncertain whether a proposed action is permitted, the researcher should contact Skylum before performing that action.

Safe-harbor treatment does not apply to conduct that is reckless, deceptive, destructive, coercive, unlawful or materially exceeds what is necessary to demonstrate a vulnerability. It also does not apply where the researcher fails to protect accessed information, continues testing after being asked to stop, publicly discloses a vulnerability contrary to the coordinated-disclosure process or violates the rights of another person.

Skylum cannot authorize research involving systems controlled by third parties and cannot bind an independent third party, regulator or public authority. Where appropriate and legally permissible, Skylum may confirm that research was reported and handled in accordance with this Policy.

8. Skylum’s vulnerability-handling process

Skylum will acknowledge a report submitted through the designated reporting channel, normally within five business days. The acknowledgement may include a tracking reference and a request for additional information.

Skylum will seek to complete an initial assessment within ten business days after receiving sufficient information to reproduce or otherwise validate the reported issue. The initial assessment will consider whether the report is within scope, whether the issue can be reproduced, the affected products and versions, potential exploitability, impact, prevalence, existing mitigations and whether there is evidence of active exploitation.

Validated vulnerabilities will be assigned an appropriate severity and remediation priority using a risk-based methodology. Skylum may consider recognized scoring systems such as the Common Vulnerability Scoring System together with product context, user exposure, attack complexity, privileges required, availability of mitigations and potential impact on confidentiality, integrity and availability.

Skylum will endeavor to provide meaningful progress updates at least once every thirty calendar days while a validated vulnerability remains unresolved. The nature and frequency of updates may depend on the complexity of the matter, the sensitivity of the investigation and whether third-party coordination is required.

Acknowledgement, assessment and remediation periods are operational targets rather than guarantees. Skylum may accelerate its response where a vulnerability is critical, actively exploited or likely to create a material risk to users.

9. Remediation and security updates

Skylum will document validated vulnerabilities and assess their implications for the affected product and its cybersecurity risk assessment.

Skylum will take appropriate action to eliminate, remediate or mitigate vulnerabilities without undue delay, taking account of the nature and severity of the risk. Remediation may include a software update, configuration change, server-side control, temporary mitigation, product instruction, feature restriction or other corrective measure.

Security updates will be distributed through mechanisms intended to protect their authenticity and integrity. Where required by applicable law, security updates addressing vulnerabilities will be made available to users without charge during the relevant support period.

10. Coordinated public disclosure and Reporting

A reporter should keep vulnerability information confidential while Skylum investigates and implements appropriate corrective measures.

Unless another period is agreed in writing, the expected coordinated-disclosure period is ninety calendar days from the date on which Skylum confirms that the vulnerability has been validated. The disclosure date may be brought forward where a security update has been broadly deployed, or extended where remediation is technically complex, dependencies outside Skylum’s control are involved, deployment requires additional user action or premature disclosure would materially increase the risk to users.

Where there is evidence of active exploitation, imminent harm or prior public disclosure, Skylum and the reporter should seek to agree an accelerated disclosure and mitigation plan.

After a security update or other corrective measure has been made available, Skylum may publish a security advisory describing the vulnerability, the affected products and versions, its potential impact and severity, and the actions users should take. Skylum may delay publication where it reasonably determines that immediate publication would create a greater security risk and users should first be given an opportunity to apply the relevant corrective measure.

Skylum may coordinate the assignment and publication of a Common Vulnerabilities and Exposures identifier where appropriate. The timing and content of any public disclosure will be determined by Skylum following consultation with the reporter, relevant component maintainers, competent authorities, CSIRTs and other affected parties where necessary.

Skylum will assess whether a validated vulnerability constitutes an actively exploited vulnerability or whether an associated event constitutes a severe incident having an impact on the security of a product with digital elements.

Skylum may notify affected users, competent authorities, ENISA, designated CSIRTs, law enforcement authorities, service providers, business partners or other relevant parties where notification is required by law or is reasonably necessary to protect users and coordinate remediation.

A reporter should not submit a regulatory notification on behalf of Skylum unless expressly authorized to do so. Nothing in this Policy prevents a reporter from exercising a legal right to contact a competent authority.

11. Recognition and compensation

Skylum maintains a vulnerability recognition and compensation program as part of this Coordinated Vulnerability Disclosure Policy. The program is intended to recognize and appropriately compensate individuals and organizations whose good-faith research assists Skylum in identifying and remediating security vulnerabilities in its products with digital elements.

A reporter will be eligible for compensation where the reporter is the first person to submit a previously unknown vulnerability that falls within the scope of this Policy, provides sufficient information for Skylum to reproduce or otherwise validate the vulnerability, complies with the good-faith research requirements of this Policy and observes the coordinated-disclosure process.

Compensation will be determined by Skylum following validation and technical assessment of the vulnerability. The amount will be proportionate to the vulnerability’s severity, exploitability, potential impact, affected user population, affected product versions, quality of the report, reliability of the proof of concept, novelty of the research and the report’s contribution to effective remediation. Skylum may use the Common Vulnerability Scoring System or another recognized risk-assessment methodology as one element of its assessment, but the applicable compensation will be based on Skylum’s overall evaluation of the vulnerability in its product and operational context.

Skylum will communicate its eligibility decision and the proposed compensation to the reporter after the vulnerability has been validated and assessed. Payment will be made through a payment method supported by Skylum and may be subject to identity verification, tax documentation, sanctions screening, export-control requirements and other legally required checks. The reporter is responsible for any personal tax or reporting obligations arising from the payment.

Reports concerning duplicate, previously known, publicly disclosed, non-reproducible, theoretical, out-of-scope or informational issues will not qualify for compensation. Reports will also be ineligible where the reporter has accessed data unnecessarily, disrupted a service, used social engineering, breached another person’s rights, threatened disclosure to obtain payment, withheld material information as leverage or otherwise failed to comply with this Policy.

Where materially different reports concern the same underlying vulnerability, Skylum may compensate the first complete and reproducible report and may recognize subsequent reporters whose independent work made a material contribution to understanding or remediating the issue.

Compensation is provided for the value of eligible security research and does not constitute payment for silence, exclusivity or the waiver of any lawful right. Acceptance of compensation requires the reporter to continue complying with the coordinated-disclosure arrangements set out in this Policy until the agreed disclosure date.

12. Confidentiality and personal data

Skylum will handle vulnerability reports as confidential security information and will restrict access to personnel and third parties who reasonably require the information for investigation, remediation, legal review, regulatory reporting or coordinated disclosure.

Skylum may share relevant information with its affiliates, professional advisers, service providers, component manufacturers, maintainers, distributors, competent authorities, where necessary and subject to appropriate legal and security safeguards.

Personal data submitted in connection with a vulnerability report will be processed in accordance with Skylum’s Privacy Policy and applicable data-protection law. Reporters should provide only the personal data necessary for communication and should avoid including personal data belonging to other individuals.

13. No waiver and limitation

This Policy does not amend any applicable product licence, terms of use, contract or statutory obligation. It does not provide permission to access data or systems beyond the limited authorization expressly described in this Policy.

Nothing in this Policy requires Skylum to disclose confidential information, security architecture, internal investigation material, personal data, legally privileged information or information that could facilitate exploitation.

Skylum reserves the right to reject, suspend or close a report where continued engagement would create a security risk, violate applicable law, prejudice an investigation or be inconsistent with this Policy.

Questions about this Policy should be directed to [email protected].