Vulnerability Handling - Coordinated Vulnerability Disclosure Policy (CVD)

1. Purpose

R3 Solutions GmbH welcomes good-faith reports of potential security vulnerabilities affecting R3 products and related services.

This policy explains:

  • how to report a potential vulnerability to R3;
  • the scope of this policy and the types of vulnerability reports it covers;
  • what information helps R3 investigate a report;
  • what reporters can expect from R3;
  • how R3 coordinates vulnerability disclosure;
  • the expectations for good-faith security research.

 

2. Scope

2.1 Products and Services in Scope

This policy applies to R3 products and related services for which R3 Solutions GmbH is responsible.

A report may concern:

  • a vulnerability in R3 product firmware or software;
  • an affected software or hardware component;
  • a product update mechanism;
  • a product-related R3 service;
  • security information or reporting mechanisms provided by R3.

Where a report concerns a third-party or upstream component used in an R3 product, R3 will assess whether the R3 product is affected and may coordinate with the relevant supplier, manufacturer, maintainer, or other affected party.

If you are unsure whether a potential vulnerability is in scope, report it anyway and R3 will assess it.

2.2 Activities Outside the Intended Scope

Researchers should avoid activities that could harm R3, its customers, users, suppliers, partners, or other parties.

Activities outside the intended scope of this policy include:

  • testing customer, third-party, or production systems or environments without authorization;
  • social engineering or phishing of R3 employees, customers, or partners;
  • physical intrusion or attempts to access R3 premises;
  • denial-of-service or resource-exhaustion testing;
  • disruption of production or customer environments;
  • unnecessary access to, modification of, deletion of, or retention of data;
  • installation of persistent access mechanisms;
  • public disclosure without allowing reasonable time for coordination with R3;
  • demands for payment or other benefits as a condition for withholding vulnerability information.

Where researchers are uncertain whether an activity is appropriate under this policy, they should contact R3 before proceeding.

 

3. How to Report a Vulnerability

Send vulnerability reports to:

security@r3.group

 

R3 accepts reports sent through ordinary unencrypted email.

A report will not be rejected solely because it was submitted through an unencrypted channel.

For particularly sensitive information, reporters should initially provide a short description and avoid sending unnecessary credentials, personal data, customer information, or other sensitive material.

PGP-encrypted communication is available on request.

To request the R3 public PGP key, contact:

security@r3.group

3.1 Anonymous Reports

R3 accepts vulnerability reports without requiring the reporter to provide their real name or other identifying information.

Because reports are submitted by email, a usable sender email address is required for direct follow-up.

Reports submitted without identifying information are assessed according to the same Vulnerability Handling process as other reports.

R3 does not provide a separate anonymous reporting form.

3.2 Supported Languages

R3 accepts vulnerability reports in:

  • English;
  • German.

 

4. Information to Include

A report should include as much of the following information as reasonably available:

  • affected product or service;
  • affected hardware, firmware, or software version;
  • description of the potential vulnerability;
  • steps required to reproduce or verify the issue;
  • proof-of-concept information, logs, screenshots, or other evidence;
  • required access, privileges, configuration, or environmental conditions;
  • potential security or safety impact;
  • known exploitation or public availability of the information;
  • available mitigation or workaround;
  • preferred name or pseudonym for acknowledgment or recognition, where desired.

If the exact product or firmware version is not available, reporters should provide any available product name, device identifier, label information, URL, configuration information, or other details that may help R3 identify the affected product.

Not every item above is required.

A partial report is better than no report. R3 may request additional information where necessary for investigation.

Reporters should avoid including personal data, including personally identifiable information (PII), customer information, credentials, or confidential information unless it is necessary to explain the vulnerability.

 

5. What Reporters Can Expect

5.1 Acknowledgment

R3 acknowledges receipt within:

5 working days

The acknowledgment normally includes:

  • confirmation that the report was received;
  • an R3 SEC-REPORT-<number> case identifier;
  • the next expected step;
  • a request for missing information where necessary.

Acknowledgment does not mean that the vulnerability has been confirmed.

5.2 Initial Triage

R3 completes initial triage within:

10 working days

Initial triage determines:

  • whether the report is relevant to an R3 product or related service;
  • whether enough information is available for investigation;
  • whether urgent handling is required;
  • who is responsible for the technical assessment.

The time required for complete technical verification may depend on the complexity of the report, the affected product, and dependencies on suppliers or component providers.

5.3 Verification and Progress Updates

Where a usable communication channel is available, R3 provides the reporter with:

  • the verification result;
  • requests for relevant additional information;
  • meaningful progress updates at least every 30 days while the case remains active;
  • notification when remediation or suitable protective measures become available;
  • information about planned disclosure where appropriate.

R3 may limit information where sharing it would:

  • create an unnecessary security risk;
  • expose confidential information;
  • adversely affect customers or users;
  • interfere with remediation;
  • interfere with legal or regulatory obligations.

 

6. Coordinated Disclosure

R3 supports coordinated vulnerability disclosure.

R3 targets disclosure within:

90 days of receiving the vulnerability report

Disclosure may occur earlier where:

  • remediation is available;
  • suitable protective measures are available;
  • active exploitation is known or suspected;
  • urgent user protection is required;
  • the vulnerability is already publicly known;
  • continued confidentiality is no longer effective.

The disclosure period may be extended where:

  • remediation requires more time due to technical complexity;
  • supplier or multi-party coordination is necessary;
  • release or testing constraints create a justified delay;
  • premature disclosure would create a greater security risk.

Any extension beyond the normal disclosure target shall be justified, documented, and risk-assessed, and should be coordinated with the reporter and affected parties where reasonably possible.

Where a vulnerability affects an upstream component or multiple organizations, R3 may coordinate with the relevant supplier, maintainer, other affected parties, or an appropriate vulnerability coordinator.

Reporters are requested to:

  • keep vulnerability details confidential during the agreed coordination period;
  • avoid publishing exploit code before users have had a reasonable opportunity to apply remediation;
  • inform R3 before publishing vulnerability details;
  • coordinate changes to the expected disclosure date;
  • avoid statements that could misrepresent the verification or remediation status.

Where earlier disclosure is necessary to protect users, R3 will coordinate the content and timing as far as circumstances permit.

 

7. Good-Faith Security Research

R3 asks reporters to act responsibly and in good faith.

Good-faith security research means that the reporter:

  • limits testing to what is reasonably necessary to identify and demonstrate the potential vulnerability;
  • minimizes access to personal data, customer information, confidential information, and other sensitive data;
  • stops testing and informs R3 if sensitive data is encountered;
  • does not use the vulnerability or information obtained during testing for malicious purposes;
  • follows the scope and activity restrictions described in Section 2 of this policy;
  • provides R3 with a reasonable opportunity to investigate, remediate, and coordinate disclosure;
  • acts in accordance with applicable law.

Testing customer or production systems requires authorization from the relevant system owner.

R3 will not pursue legal action against researchers who conduct good-faith security research in accordance with this policy.

 

8. Reporter Recognition and Bounties

R3 may acknowledge a reporter in a published Security Advisory where:

  • the reporter requests recognition;
  • the reporter agrees to the proposed wording;
  • recognition does not expose confidential or personal information.

If a reporter chooses to remain anonymous, R3 will not publish identifying information about the reporter.

A reporter who wishes to be acknowledged under a name or pseudonym may request this before publication.

R3 does not operate a vulnerability bounty programme.

Submission of a vulnerability report does not create an entitlement to:

  • payment;
  • compensation;
  • employment;
  • another reward.

 

9. Confidentiality and Personal Data

R3 handles non-public vulnerability information through appropriate access-controlled systems.

Information may be shared with relevant internal teams, suppliers, maintainers, vulnerability coordinators, or authorities where required for:

  • verification;
  • risk assessment;
  • remediation;
  • release preparation;
  • coordinated disclosure;
  • protection of customers or users;
  • fulfilment of legal or regulatory obligations.

R3 will not publish the reporter's identity without consent unless disclosure is legally required.

Reporters should not submit personal data that is unrelated to the vulnerability.

Where a report unintentionally exposes personal, customer, or confidential data, the reporter should:

  1. stop accessing the data;
  2. avoid copying or retaining it;
  3. notify R3 immediately;
  4. follow R3's instructions for secure deletion or transfer.

 

10. Security Advisories

Where information about a fixed or mitigated vulnerability needs to be communicated publicly or to affected users, R3 may publish a human-readable Security Advisory.

An advisory may include:

  • vulnerability description;
  • vulnerability identifier, such as a CVE where assigned;
  • affected product and versions;
  • potential impact;
  • severity;
  • remediation or mitigation information;
  • release date;
  • advisory update date;
  • reporter acknowledgment where agreed.