Coordinated Vulnerability Disclosure Policy

1. Purpose

Kaptura GmbH is committed to continuously improving the security of its products and services.

We encourage security researchers, customers, partners and other parties to report suspected security vulnerabilities to us responsibly. This policy describes how we receive, assess, coordinate and disclose vulnerability reports.

Our goal is to resolve vulnerabilities in a timely manner while protecting our customers, users and the reporting party.

2. Scope

This policy applies to security vulnerabilities affecting products and infrastructure operated or provided by Kaptura GmbH.

A vulnerability report is considered within the scope of this policy when it concerns a security weakness affecting a product or infrastructure of Kaptura GmbH.

3. Security Contacts

3.1 Product Security / PSIRT

Security vulnerabilities affecting our products should preferably be reported to our Product Security Incident Response Team (PSIRT):

Email: psirt@cvd.kaptura.de

The current OpenPGP encryption key and its fingerprint are published together with our security contact information.

3.2 Cloud Service and Infrastructure Security / CSIRT

Security incidents and vulnerabilities requiring coordination with our organisational CSIRT can be reported to:

Email: csirt@cvd.kaptura.de

The current OpenPGP encryption key and its fingerprint are published together with our security contact information.

3.3 National CSIRT

The competent national CSIRT for Kaptura GmbH is:

Bundesamt für Sicherheit in der Informationstechnik (BSI)

Contact and escalation information is maintained by our PSIRT and CSIRT.

4. How to Report a Vulnerability

Reports may be submitted by email to the PSIRT or CSIRT contact addresses published in our security.txt.

Where available, reporters may also use our vulnerability reporting web form:

https://cvd.kaptura.de/

Reports may be submitted anonymously.

For confidential reports, we recommend encrypted communication using the OpenPGP key published for the relevant contact.

We recommend that vulnerability reports contain, where available:

• affected product and version;
• affected component;
• description of the vulnerability;
• steps required to reproduce the issue;
• proof of concept or other technical evidence;
• potential impact;
• relevant logs or screenshots;
• information about whether exploitation has been observed;
• a preferred contact method.

A reporter should provide only information necessary for investigating the vulnerability.

5. What We Consider a Valid Vulnerability

A valid vulnerability is a security weakness affecting a product or infrastructure of Kaptura GmbH.

Reports should, where possible, contain sufficient technical information to reproduce and assess the reported issue.

Information that is already publicly known may still be reviewed and assessed.

Automated scan results without supporting technical information may be insufficient to establish the existence or impact of a vulnerability.

6. Our Commitments to Security Researchers

We will handle vulnerability reports in good faith and will work with reporters to understand, assess and remediate reported vulnerabilities.

6.1 Confidentiality

We will treat vulnerability reports confidentially to the extent permitted by applicable law and will restrict access to persons who require the information for vulnerability handling.

6.2 Personal data

Personal data provided by the reporter will not be disclosed to third parties without the reporter's explicit consent, unless disclosure is required by law or is otherwise legally necessary.

6.3 No NDA requirement

We do not require a non-disclosure agreement as a prerequisite for submitting a vulnerability report.

6.4 Legal action

We will not initiate criminal proceedings against a reporter for activities carried out in good faith and in accordance with this policy.

This commitment does not apply where there are recognisable criminal intentions or other clearly unlawful activities.

6.5 Contact throughout the process

We will remain available to the reporter throughout the CVD process and will provide status information as appropriate.

We recommend that sensitive information exchanged during the CVD process be transmitted using encrypted and digitally signed communication.

7. Communication

We will process vulnerability reports to the best of our ability.

Email addresses and telephone numbers are accepted as valid communication channels for vulnerability reports.

We welcome status enquiries from reporters.

Where additional technical information is required, we will contact the reporter using the available contact information.

We aim to communicate respectfully and transparently throughout the CVD process.

8. Response Times

8.1 Initial response

We will provide a non-automated acknowledgement or status update within 5 working days of receiving a vulnerability report.

8.2 Detailed response

Within 10 working days, we will provide detailed feedback containing at least one of the following:

• confirmation or rejection of the reported vulnerability;
• meaningful questions required to clarify or technically assess the report; or
• an explanation why the assessment requires additional time and a commitment to provide a further update within 10 working days.

These guaranteed response times do not apply to anonymous reports where no communication channel is available for responding to the reporter.

9. Anonymous Reports

Anonymous vulnerability reports are accepted.

Anonymous reporters may use the available web-based reporting mechanism without providing identifying information.

Because we cannot contact an anonymous reporter, we may be unable to request additional information, clarify technical details or provide status updates.

If the available information is insufficient to assess or remediate the reported vulnerability, the report may therefore not be fully processed.

10. Vulnerability Assessment and Coordination

Each report will be assessed to determine:

• whether it concerns a vulnerability;
• which products, versions or infrastructure are affected;
• the potential security impact;
• whether exploitation is known or suspected;
• whether mitigation or remediation is required;
• whether coordination with additional stakeholders is necessary.

For vulnerabilities that are actively exploited, we will inform the competent national CSIRT without undue delay and coordinate relevant information, mitigation measures and remediation plans with it.

11. Vulnerability Remediation

For confirmed vulnerabilities, we will determine appropriate remediation or mitigation measures.

Depending on the circumstances, remediation may include:

• software or firmware updates;
• configuration changes;
• workarounds;
• security advisories;
• customer notifications;
• other appropriate mitigation measures.

The remediation process will take into account the severity and impact of the vulnerability as well as the risk to affected users.

12. Vulnerability Disclosure

Validated and verified vulnerabilities will be publicly disclosed within 90 days, unless the vulnerability has already been remediated before the relevant product was placed on the market.

Where an additional period is reasonably required, a one-time extension of up to 90 days may be used where there is a valid justification and the extension is closely coordinated with the competent national CSIRT.

Further extensions may be requested from the competent CSIRT where appropriate.

Public disclosure will contain sufficient information to allow affected users to understand the vulnerability and available remediation or mitigation measures.

13. Coordination with the National CSIRT

We will coordinate with the competent national CSIRT where required by the applicable vulnerability handling process.

In particular, coordination will cover:

• actively exploited vulnerabilities;
• relevant new information;
• mitigation measures;
• remediation plans;
• planned disclosure;
• justified disclosure extensions.

14. End of the CVD Process

The CVD process may be considered complete when one of the following applies:

• the report has been determined to be unfounded;
• the affected service or product has been appropriately repaired and the relevant information has been communicated;
• the vulnerability has been remediated through a patch or mitigation and the relevant information has been publicly communicated;
• the reporter has not responded to technical or content-related questions for at least 30 days;
• the vulnerability has already been publicly disclosed and, in coordination with the competent CSIRT, no further remediation is reasonably expected.

Where appropriate, we will notify the reporter when the CVD process is closed.

15. Optional Code of Conduct

We expect security researchers to:

• avoid unnecessary access to data;
• avoid disruption of services;
• limit testing to what is necessary to demonstrate the vulnerability;
• avoid modifying or deleting data;
• avoid attacks against third parties;
• stop testing once sufficient evidence has been obtained.

This section describes our expectations and is not a prerequisite for submitting a vulnerability report.

16. Researcher Recognition

With the researcher's consent, Kaptura GmbH may publicly acknowledge researchers who have responsibly reported vulnerabilities.

No public acknowledgement will be made without the researcher's consent.

17. Policy Maintenance

This policy is reviewed at least once every 12 months and whenever significant changes to our vulnerability disclosure process occur.

The current version, publication date and last review date are publicly available.

18. Related Information

Security contact information:

https://cvd.kaptura.de/.well-known/security.txt

Vulnerability reporting:

https://cvd.kaptura.de/

19. Version History