Purpose and Security Objective

Matrix42 is committed to the responsible, transparent, and coordinated handling of security vulnerabilities. This Vulnerability Disclosure Policy describes the public reporting channel for security researchers, customers, partners, and other third parties, as well as the internal handling of incoming vulnerability reports.

The Policy supports the following objectives in particular:

• Fast and secure reporting of potential vulnerabilities;
• Clear responsibilities for intake, assessment, remediation, and communication;
• Protection of customers, users, data, and services;
• Coordinated disclosure after remediation or risk mitigation;
• Traceability of processing in line with a Product Security Incident Response Team (PSIRT).

Scope

This VDP applies to publicly accessible Matrix42 products, services, and digital offerings, insofar as these fall within Matrix42's area of responsibility.

The following are explicitly out of scope of this VDP:

• Systems, products, or infrastructure of customers, partners, or third-party providers;
• Physical security assessments and attacks on buildings or employees;
• Social engineering, phishing, spam, or deception attempts;
• Denial-of-service tests, load tests, or tests affecting availability;
• Access to data that is not strictly necessary to demonstrate the vulnerability;
• Vulnerabilities in outdated, no-longer-supported product versions, unless a separate support commitment exists.

Roles and Responsibilities

Reporting Channels and security.txt

Vulnerabilities should preferably be reported to the central security contact:

psirt@matrix42.com (PGP encryption available)

https://matrix42.teambeam.de/mailbox/psirt (Web based portal, GDPR compliant)

For public disclosure, Matrix42 additionally provide a security.txt file. The location per RFC 9116 is:

https://www.matrix42.com/.well-known/security.txt

Requirements for a Report

A report should be specific enough for Matrix42 to reproduce, assess, and prioritize the vulnerability. Reporters should only submit information that is necessary for processing the report.

Matrix42 may classify reports as:

• Valid
• Duplicate
• Informative
• Known Issue
• Not Reproducible
• Out of Scope
• Accepted Risk

Permitted and Prohibited Testing

Permitted Testing

• Reproducible, minimally invasive tests to confirm a vulnerability;
• Tests against one's own accounts, own tenants, or explicitly authorized test environments;
• Reading publicly accessible information and passive reconnaissance;
• Testing for misconfigurations, authentication, and authorization flaws without data exfiltration.

Prohibited Testing

• Denial-of-service, load testing, exploit automation, or scans with disproportionate load;
• Accessing, altering, deleting, or exfiltrating third-party data;
• Installing persistent access, malware, or backdoors;
• Circumventing organizational safeguards through social engineering;
• Attacks against employees, locations, or physical infrastructure;
• Publishing technical details before coordinated disclosure has concluded.

Safe Harbor Statement

Matrix42 does not intend to pursue legal action against security researchers who act in good faith and comply with this Policy. This requires in particular that testing is proportionate, authorized within the meaning of this Policy, and free of any misuse of data or services.

This safe harbor statement does not apply to actions that violate applicable law, indicate malicious intent, misuse data, disrupt business operations, or exceed what is necessary to demonstrate the vulnerability.

Handling Process

• Intake: Matrix42 acknowledges receipt of the report via the specified contact channel.
• Initial review: The PSIRT checks scope, completeness, plausibility, and potential security relevance.
• Validation: Functional and technical teams reproduce and confirm the vulnerability.
• Assessment: Matrix42 assesses severity, exploitability, affected products, and customer risk.
• Remediation planning: Responsible teams plan a fix, workaround, configuration guidance, or other mitigation.
• Implementation: Fixes are developed, tested, and made available for affected products or services.
• Communication: Matrix42 coordinates status updates with the reporter and prepares customer communication.
• Disclosure: Once appropriate measures are in place, a coordinated publication takes place if required

Matrix42 manages vulnerability reports through its Product Security Incident Response Team (PSIRT) according to documented internal procedures based on risk assessment, remediation tracking and coordinated disclosure practices.

Assessment, Prioritization, and Timelines

Assessment is risk-based. Matrix42 may consider CVSS, technical exploitability, exposure, customer impact, data protection relevance, active exploitation, and complexity of remediation.

Matrix42 does not commit to fixed remediation timelines, but prioritizes vulnerabilities according to risk, exploitability and customer impact.

Multi-Vendor Vulnerability Coordination

For vulnerabilities affecting third-party or multi-vendor ecosystems, Matrix42 may coordinate disclosure with affected vendors, CERTs, maintainers, or vulnerability coordinators prior to public disclosure.

Communication and Coordinated Disclosure

Matrix42 follows a Coordinated Vulnerability Disclosure approach. The reporter should give Matrix42 reasonable opportunity to validate and remediate the issue before technical details are published.

Reports received through trusted vulnerability coordinators, CERTs or recognized disclosure platforms may be accepted and processed.

Matrix42 may publish advisories where customer action is required, the risk is material, a CVE is assigned, or public awareness improves customer security posture.

Where appropriate, Matrix42 may request, reserve, or publish CVE identifiers through authorized channels.

Depending on risk and impact, Matrix42 may use the following forms of communication:

• Direct feedback to the reporter;
• Security advisory;
• Release notes or knowledge base article;
• Customer notification via existing communication channels;
• CVE entry, provided the vulnerability is CVE-relevant and publication has been coordinated.

Privacy and Confidentiality

Matrix42 processes the reporter's personal data only to the extent necessary to process the vulnerability report, for communication, documentation, and to fulfill legal obligations. Reporters should not submit third-party personal data unless strictly necessary.

If a reporter inadvertently gains access to personal or confidential data, they should immediately stop accessing it, refrain from making copies, and inform Matrix42 without delay.

Recognition of Security Researchers

Matrix42 may publicly recognize security researchers upon request, provided the report was valid, the Policy was followed, and no legal, contractual, or security-related reasons prevent it.

Recognition is granted only with the reporter's consent.

Matrix42 reserves the right to determine the form, timing, and extent of any recognition.

Abuse, exclusions, and Reservation of Rights

Matrix42 may decline or limit the handling of reports that fall outside the scope, are insufficiently described, are submitted in an automated bulk manner, or violate this Policy.

Matrix42 reserves all rights, in particular in cases of malicious behavior, data misuse, impairment of availability, deception, extortion, or other unlawful conduct.

Publication and Maintenance Process

The VDP should be easily discoverable to the public and reviewed regularly. Changes to contact channels, scope, safe harbor provisions, timelines, or publication processes should be versioned and documented traceably.

Normative References and Sources

 Appendix A: Proposed Report Form