Coordinated Vulnerability Disclosure Policy

Document Classification: Public

1. Purpose

Catalogic Software (“Catalogic,” “we,” “our”) values the contribution of independent security researchers and members of the public who help us find and fix security vulnerabilities in our products. This policy explains how to report a suspected vulnerability in Catalogic DPX or Catalogic CloudCasa, what you can expect from us in response, and the terms under which we authorize good-faith security research.

This policy also reflects Catalogic’s obligation, as a manufacturer of “products with digital elements” under the EU Cyber Resilience Act (Regulation (EU) 2024/2847, the “CRA”), to maintain and enforce a coordinated vulnerability disclosure process (CRA Annex I, Part II(5)) and to publish a single point of contact for vulnerability reports (CRA Annex II(2)).

2. Scope

2.1. In scope

• Catalogic DPX and vStor – all currently supported versions (see the DPX Support Lifecycle / End-of-Support schedule).
• Catalogic CloudCasa – the CloudCasa SaaS platform and all currently supported self-hosted/connector components.
• Vulnerabilities in Catalogic-authored code, configuration, and Catalogic-operated infrastructure directly supporting these products.

2.2. Out of scope

• Denial-of-service, spam, social engineering, or physical attacks against Catalogic staff, offices, or data centers.
• Automated vulnerability scanning that generates significant load against Catalogic-hosted services without prior coordination.
• Third-party services, dependencies, or infrastructure not controlled by Catalogic (please see Section 8 for how to report those).
• Products that have reached end of support, unless otherwise stated in the applicable end-of-support notice.

3. Key terms

• Vulnerability – a weakness, susceptibility, or flaw in a product with digital elements that can be exploited by a cyber threat.
• Actively exploited vulnerability – a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner (CRA Article 3(42)). This is a legal trigger for Catalogic’s own regulatory reporting duties under CRA Article 14 – see Section 7.
• Coordinated Vulnerability Disclosure (CVD) – a process by which a reporter privately discloses a vulnerability to the vendor, allowing time for assessment and remediation before any public disclosure.
• Good-faith security research – accessing a product solely to test, investigate, and/or correct a security issue, in a manner designed to avoid harm, and reported promptly to Catalogic.

4. How to report a vulnerability

Please report suspected vulnerabilities to our single point of contact:

• Email: security@catalogicsoftware.com
• This contact is also published in machine-readable form at https://www.catalogicsoftware.com/.well-known/security.txt and https://cloudcasa.io/.well-known/security.txt.

If you believe a vulnerability is being actively exploited, or poses immediate risk to customer data, please say so explicitly in your subject line (e.g. “ACTIVE EXPLOITATION”) so it can be triaged immediately – see Section 7.

5. What to include in your report

• Product and version(s) affected (e.g. DPX x.x, CloudCasa component/date).
• A description of the vulnerability and its potential impact.
• Step-by-step reproduction instructions, proof-of-concept code, or a request/response capture, where possible.
• Whether you believe the vulnerability is already being exploited in the wild, and any evidence supporting that.
• Your preferred contact method and, if you wish to be publicly credited, the name/handle to use.

Please do not include actual customer data, credentials, or other sensitive information in your report; describe access instead of exfiltrating data.

6. Our commitment to you

Once we receive a valid report through the channel above, we commit to:

• Acknowledge receipt and assign a tracking reference.
• Investigate and validate the report, and keep you informed of material progress.
• Work to remediate confirmed vulnerabilities within the timelines below, prioritized by severity.
• Not pursue legal action against researchers who comply with this policy (see Section 9).
• Credit reporters who wish to be acknowledged, once a fix is available (no monetary bounty program at this time).

The response-time targets above are proposed internal service targets aligned with common industry practice (e.g. ISO/IEC 29147 and 30111 principles). They are not mandated by the CRA, which does not set a numeric response SLA for CVD programs.

7. Coordinated disclosure timeline and active exploitation

We ask reporters not to publicly disclose a vulnerability until a fix or mitigation is available, or until 90 calendar days have passed since the report was acknowledged as valid, whichever is sooner – unless we agree on a different timeline together.

If, at any point, Catalogic determines that a reported vulnerability meets the CRA definition of an “actively exploited vulnerability” (Article 3(42)) – or if a severe incident affecting the security of DPX or CloudCasa occurs – Catalogic is legally required to notify the competent coordinator CSIRT and ENISA under CRA Article 14, within 24 hours of becoming aware (early warning), 72 hours (notification), and with a final report thereafter. This regulatory obligation runs in parallel with, and does not replace, our coordination with the reporter.

8. Third-party and open-source components

Where a reported vulnerability originates in a third-party or open-source component used within DPX, vStor or CloudCasa, we will, where practicable, coordinate with the upstream maintainer or steward and factor their disclosure timeline into our own, consistent with CRA Annex I, Part II(6).

9. Safe harbor

Catalogic will not initiate legal action against, or refer to law enforcement, a researcher who: (a) makes a good-faith effort to comply with this policy; (b) avoids privacy violations, destruction of data, or interruption/degradation of our services; (c) does not access, modify, or exfiltrate data beyond what is strictly necessary to demonstrate the vulnerability; and (d) reports the finding promptly and does not exploit it beyond what is necessary for verification.

10. Public advisories

Once a fix is available, Catalogic will publish advisory information describing the vulnerability, affected products/versions, severity, and remediation guidance, consistent with CRA Annex I, Part II(4). Advisories are published at catalogicsoftware.com and cloudcasa.io.

11. Policy governance

• Owner: Security Team
• Review cadence: at least annually, and upon material regulatory change (e.g. new Commission/ENISA CRA guidance) or product-scope change.
• This policy applies jointly to DPX and CloudCasa; product-specific advisory pages may supplement it.