Coordinated Vulnerability Disclosure Policy

Purpose and scope

What this policy covers, where our authorization ends, and how project-specific security instructions apply.

Purpose

At Lunaris Digital Solutions, security is part of how we develop and maintain software.

We welcome reports from security researchers, users, customers and members of the open-source community who identify potential security vulnerabilities in software maintained by Lunaris.

This Coordinated Vulnerability Disclosure Policy describes:

which systems and projects are covered;
how to report a potential vulnerability;
what information helps us investigate a report;
what security researchers can expect from us;
how we coordinate remediation and disclosure.

Our objective is to identify, understand and remediate security vulnerabilities while protecting users and allowing researchers to report findings safely and responsibly.

Scope

This policy applies to software and other digital products for which Lunaris Digital Solutions GmbH & Co. KG is responsible for development or maintenance.

This includes, in particular:

open-source software maintained by Lunaris;
software repositories maintained under the Lunaris Digital Solutions GmbH & Co. KG GitHub organization at https://github.com/lunarisdigitalsolutions;
official releases and supported versions of these projects;
online services operated by Lunaris where those services form part of a Lunaris product or project.

Individual repositories may contain a SECURITY.md file defining supported versions, project-specific security boundaries or additional reporting instructions. These project-specific instructions supplement this policy.

Customer projects

Software, systems or infrastructure belonging to our customers are not automatically within the scope of this policy, even where Lunaris contributed to their development.

If you discover a vulnerability in a customer system, please do not perform additional testing against that system. Contact us and provide enough information for us to identify the affected system. We will coordinate with the responsible party where appropriate.

Third-party systems

Services and infrastructure operated by third parties, including GitHub itself, are outside our authorization scope. Vulnerabilities affecting those systems should normally be reported directly to the responsible provider.

However, if a third-party vulnerability affects a Lunaris-maintained product, we welcome reports explaining the potential impact on our software.

Report a vulnerability

Use a confidential channel and include enough technical detail for us to understand and reproduce the finding.

How to report a vulnerability

Please do not create a public GitHub issue, discussion, pull request or other public post for a previously undisclosed vulnerability.

We accept vulnerability reports in English and German.

Preferred method: GitHub Private Vulnerability Reporting

For a Lunaris GitHub repository that supports Private Vulnerability Reporting, please use the repository's private security reporting function.

This is our preferred method for repository-specific vulnerabilities because it allows technical details, discussions and proposed fixes to remain confidential while the vulnerability is being investigated.

Email

For vulnerabilities that cannot be reported through GitHub Private Vulnerability Reporting, concern multiple projects or otherwise relate to Lunaris products or services, contact:

security@lunaris.digital

Please use a subject such as:

Security Vulnerability Report - [project/product]
or
Schwachstellenmeldung - [Projekt/Produkt]

Encrypted communication

If your report contains sensitive technical details, proof-of-concept information or other confidential material, we recommend using OpenPGP encryption.

Our current security contact information and OpenPGP encryption details are published in our security.txt file: https://lunaris.digital/.well-known/security.txt

Please use the OpenPGP key referenced there for encrypted email communication.

Do not send passwords, API keys, customer data or other sensitive production data by unencrypted email.

If sensitive information is necessary for the investigation and you are unable to use OpenPGP, send us an initial description without the sensitive material. We will coordinate an appropriate secure exchange method.

What to include in your report

Please provide as much of the following information as reasonably possible:

affected product or repository;
affected version, release, branch or commit;
description of the vulnerability;
potential security impact;
steps required to reproduce the issue;
required configuration or preconditions;
proof of concept, where appropriate;
relevant logs, screenshots or traces, with sensitive information removed;
CWE, CVE or CVSS information, if already known;
whether you believe the vulnerability is currently being actively exploited;
whether the vulnerability has already been disclosed to another party or publicly;
your preferred contact information.

Please use synthetic test data wherever possible.

Do not include live credentials, customer information or unrelated personal data in a vulnerability report.

A report generated solely by an automated scanner without sufficient information to understand or reproduce the finding may not be sufficient for us to validate a vulnerability.

Research guidance

Boundaries for good-faith testing and the commitments researchers can expect from Lunaris.

Security research guidelines

We support good-faith security research.

When investigating a potential vulnerability, please:

limit testing to what is necessary to confirm and document the vulnerability;
use your own accounts, environments and data wherever possible;
stop testing if you encounter personal, confidential or customer data;
minimize access to data and do not retain information that is not necessary for the report;
avoid modifying or deleting data;
avoid disrupting services or other users;
give us a reasonable opportunity to investigate and remediate the issue before public disclosure.

Please do not:

perform denial-of-service or distributed denial-of-service attacks;
perform destructive testing;
perform brute-force attacks that may affect production services;
use social engineering, phishing or physical attacks against employees, customers or partners;
intentionally access data belonging to other users or customers beyond what is strictly necessary to demonstrate the issue;
modify, delete, exfiltrate or publicly disclose third-party data;
install persistent access mechanisms;
use a vulnerability to gain commercial advantage or demand payment;
sell or distribute exploits for an undisclosed vulnerability.

If you are unsure whether a proposed test is appropriate, contact us before performing it.

Our commitment to security researchers

If you conduct security research in good faith and comply with this policy, Lunaris will:

treat your report and the vulnerability information confidentially while coordination is ongoing;
not initiate legal action against you solely because of security research performed in accordance with this policy;
not require you to sign a non-disclosure agreement as a condition for reporting a vulnerability;
work with you to understand and validate the vulnerability;
keep you informed about significant progress;
coordinate remediation and disclosure with you where reasonably possible;
acknowledge your contribution publicly if you request it and disclosure is appropriate.

This protection does not apply to activity undertaken with malicious or criminal intent or activity that intentionally causes harm beyond what is necessary to demonstrate a vulnerability.

This policy cannot authorize testing of systems or data belonging to third parties.

Response and disclosure

How we acknowledge, assess, remediate, and coordinate disclosure of a confirmed vulnerability.

Our response process

After receiving a report, we use the following process.

Acknowledgement

For reports that include a usable contact method, we aim to provide a personal acknowledgement within 5 working days.

Initial assessment

Within 10 working days, we aim to provide one of the following:

confirmation that we have validated the reported vulnerability;
an explanation that we currently do not consider the reported issue a security vulnerability;
technical questions needed to continue our investigation; or
an explanation that the investigation requires additional time and when you can expect the next update.

These periods describe our communication commitments. They are not remediation deadlines.

Analysis and prioritization

We evaluate confirmed vulnerabilities based on factors including:

technical severity;
exploitability;
affected versions and users;
privileges or access required;
exposure of confidentiality, integrity or availability;
availability of mitigations;
evidence of exploitation;
impact on downstream projects or users.

Where useful, we may use CVSS or other established assessment methods as part of this analysis. A numerical score does not replace our assessment of the actual product context.

Status updates

For an unresolved confirmed vulnerability, we aim to provide an update at least every 30 days, unless another communication schedule has been agreed with the reporter.

Remediation

We aim to address confirmed vulnerabilities without undue delay and according to the risk they pose.

Depending on the vulnerability, remediation may include:

a software update;
a new release;
a configuration change;
a workaround or mitigation;
updated documentation;
disabling or removing an affected feature;
changes to an upstream dependency.

We do not promise that every vulnerability can be fully remediated within a fixed number of days. Remediation time depends on severity, technical complexity, compatibility requirements, upstream dependencies and the risk introduced by the remediation itself.

For critical vulnerabilities or vulnerabilities known to be actively exploited, we may accelerate remediation, notification and disclosure.

Coordinated disclosure

Our preference is to disclose a confirmed vulnerability together with a security update, mitigation or other information that allows users to protect themselves.

As a general target, we aim to coordinate public disclosure of a confirmed vulnerability within 90 days.

The timing may be shorter where immediate disclosure is necessary to protect users, particularly where there is evidence of active exploitation.

A longer coordination period may be appropriate where:

remediation requires significant architectural changes;
an upstream project or multiple downstream projects are affected;
releasing details would materially increase the risk to users before mitigation is available;
coordinated disclosure with another maintainer, vendor, CERT or authority is necessary.

Where possible, we will discuss significant changes to the disclosure timeline with the reporter.

The absence of a complete fix does not automatically mean that disclosure will be postponed indefinitely. Where appropriate, we may publish an advisory describing the vulnerability, affected versions, risks and available mitigations even where a complete remediation is not yet available.

Advisories and support

How we publish security information, prioritize supported versions, and handle vulnerabilities in dependencies.

Security advisories and CVEs

For vulnerabilities affecting our open-source projects, disclosure will normally take place through one or more of the following channels:

GitHub Security Advisories;
security information in the affected repository;
release notes;
project documentation;
the Lunaris website.

Where appropriate, we may request or coordinate assignment of a CVE identifier.

Security advisories will normally identify:

the affected project;
affected versions;
vulnerability description;
security impact and severity;
fixed versions;
available mitigations or workarounds;
references to updates or releases.

We may initially withhold technical exploitation details where publishing them would unnecessarily expose users who have not yet had a reasonable opportunity to update.

Supported versions

The SECURITY.md file or other documentation of an individual project defines which versions are currently supported.

Where no project-specific support policy exists, we normally focus security remediation on the current release and actively maintained development branch.

We will still review reports concerning older or unsupported versions where the vulnerability may also affect supported versions or presents a significant security risk.

Archived or explicitly unmaintained projects may no longer receive security fixes. We will make this status visible where reasonably possible.

Vulnerabilities in dependencies

Our projects depend on software maintained by other open-source projects and vendors.

If a reported vulnerability originates in an upstream dependency, we will assess whether and how our products are affected.

Depending on the situation, we may:

update or replace the dependency;
apply a mitigation in our own software;
contact the upstream maintainer;
coordinate disclosure with the upstream project;
publish information explaining whether particular Lunaris versions are affected.

Please avoid publicly disclosing an upstream vulnerability through a Lunaris issue if it is not already public.

Researcher acknowledgement

We appreciate responsible security research.

If you report a valid vulnerability and would like to be credited, tell us the name or alias and optional reference link you would like us to use.

We will not publish your identity in connection with a vulnerability without your consent.

Lunaris does not currently operate a bug bounty programme, and submitting a vulnerability does not create an entitlement to financial compensation.

Governance and contact

Confidentiality, regulatory notifications, current security contact details, and policy maintenance.

Confidentiality and personal data

We process information contained in vulnerability reports only as necessary to investigate, coordinate, remediate and disclose security issues and to comply with applicable legal obligations.

Please minimize personal data in reports.

Information may need to be shared with relevant Lunaris employees, project maintainers, upstream maintainers, service providers, customers or competent authorities where this is necessary to investigate or address the vulnerability or where disclosure is required by law. We will limit such sharing to what is reasonably necessary.

We will not publicly disclose the identity of a reporter without their consent.

Further information about our processing of personal data is available in the Lunaris privacy policy: https://lunaris.digital/datenschutz

Regulatory notifications

This vulnerability disclosure process is separate from any statutory cybersecurity reporting obligations that may apply to Lunaris.

Where applicable, we will fulfil reporting and notification obligations under the Cyber Resilience Act or other applicable legislation in accordance with our internal incident-response and vulnerability-handling processes.

Such regulatory reporting may take place independently of the coordinated public disclosure timeline described in this policy.

Security contact and security.txt

Our current security contact information, supported languages and available encryption mechanisms are published in our security.txt file: https://lunaris.digital/.well-known/security.txt