1. Introduction

The security of our products and services and the protection of the customer data entrusted to us are BlueRange’s highest priority. This applies to the BlueRange Smart Building Platform as well as to the gateways, the mesh firmware and the apps in use in our customers’ buildings. Independent security researchers make a valuable contribution by uncovering vulnerabilities that might otherwise go undetected.

This policy describes how to search for vulnerabilities in an authorized manner, how to report findings to us, and what you can expect from us in return. We appreciate the cooperation of everyone who helps, in good faith, to make our products more secure for all.

This policy may be updated from time to time; the effective date and version number will be adjusted accordingly. Please read the current version before starting any testing.

2.1 In-Scope Systems

The following resources fall within the scope of this policy:

• BlueRange Smart Building Platform and the associated services hosted on domains operated by BlueRange
• Web applications, portals and public APIs operated by BlueRange under *.bluerange.io
• BlueRange Gateway OS: the operating system image of the BlueRange gateways
• BlueRange Gateway Application: the software running on the gateways that connects the mesh networks to the platform
• BlueRange Mesh Firmware: the firmware of BlueRange-enabled mesh nodes (sensors, actuators, beacons, luminaire modules), including Bluetooth Low Energy communication between nodes and between nodes, gateways and apps
• BlueRange apps published in official app stores, including the BlueRange Office App and the BlueRange Setup App
• The BlueRange website and related web pages

Testing of gateways and mesh nodes is only permitted on devices that you own or for which you have the owner’s explicit permission, and only in your own test environment, separate from production installations.

2.2 Out-of-Scope Systems

The following targets are not authorized for testing under this policy:

• BlueRange software and hardware operated by our customers, partners or third parties, in particular gateways, mesh networks and platform instances installed in buildings
• Any other systems, networks or applications of our customers, partners or third parties
• Third-party services integrated into our products (e.g. identity providers, cloud infrastructure, analytics services), as well as hardware and firmware from third-party manufacturers, such as luminaires or building technology into which BlueRange modules are integrated
• Physical premises and facilities of BlueRange GmbH

If you are unsure whether a target is in scope, please contact security@bluerange.io before starting any testing.

3.1 Authorized Activities

Provided you comply with this policy, the following activities are expressly permitted:

• Evaluation of publicly available information about our systems (e.g. DNS records, SSL certificates, publicly available documentation and publicly available source code)
• Testing for common web application vulnerabilities (e.g. injection vulnerabilities, authentication flaws, access control issues, security misconfigurations)
• Examination of API endpoints for security vulnerabilities
• Analysis of client-side code delivered through our web applications
• Provided the artifacts in question originate from BlueRange and were obtained legitimately through official distribution channels or with your own hardware:
  • Analysis of Gateway OS images, update packages and the Gateway Application
  • Analysis of the Mesh Firmware, including reverse engineering and examination of the update mechanisms (e.g. DFU)
  • Examination of the radio communication (Bluetooth Low Energy) and network communication of your own devices
  • Reverse engineering, including decompilation, of the BlueRange apps

3.2 Conditions for Authorization

To act within the scope of this authorization, you must:

1. Act in good faith: with the sole aim of identifying and reporting security vulnerabilities
2. Minimize harm: avoid actions that could affect system availability, data integrity, other users or building operations
3. Mind the radio range: conduct radio-based tests in such a way that no third-party mesh networks, gateways or devices within range are affected
4. Stop upon discovery: once the existence of a vulnerability has been confirmed, stop further testing and report your findings; do not demonstrate the impact by accessing further data, systems or devices
5. Protect data: do not access, copy, modify or delete other users’ data; if you accidentally access such data, stop immediately, do not store or share the data, and note the incident in your report
6. Maintain confidentiality: do not share vulnerability details with third parties before we have had a reasonable opportunity to fix the issue and a coordinated disclosure has been agreed upon

3.3 Prohibited Activities

The following methods and behaviors are not permitted under any circumstances, not even against in-scope systems:

• Any form of social engineering, phishing, vishing, pretexting or similar methods targeting BlueRange employees, customers or users
• Physical intrusion or attempts to gain physical access to buildings, rooms or installed devices
• Testing of gateways, mesh networks or devices operated in customer installations or other third-party environments, including radio-based attacks from nearby
• Denial-of-service attacks (DoS/DDoS), jamming, or tests aimed at impairing service availability
• Automated vulnerability scanning at a volume or frequency that could affect system performance
• Accessing, downloading or otherwise exfiltrating customer data, personal data or confidential business information
• Modifying or deleting data in any system
• Deploying manipulated firmware or configurations to third-party devices
• Uploading malicious code, backdoors or mechanisms for persistent access
• Attempting to use a discovered vulnerability to access further systems, devices or data
• Spam or unsolicited bulk messages
• Sharing credentials, key material, vulnerability details or proof-of-concept code with third parties
• Public disclosure of vulnerabilities (including as a public issue in a source code repository) before a coordinated disclosure has been agreed upon

4. Legal Position

Towards security researchers who fully comply with this policy, BlueRange commits to:

• Not initiate civil legal action for activities conducted in accordance with this policy
• Not file a criminal complaint for activities conducted in accordance with this policy
• Cooperate in good faith in handling reported vulnerabilities
• Issue a confirmation of authorization upon request, so that researchers can document their status before starting testing

This policy constitutes an authorization by BlueRange as the manufacturer of the products described in Section 2.1 and as the operator of the systems listed there. We have created it in good faith to protect researchers who likewise act in good faith.

However, this policy cannot and does not guarantee immunity from criminal prosecution. Nor can it grant authorization for systems or devices owned or operated by third parties. We therefore strongly recommend documenting all activities carefully and, if in doubt, obtaining a written confirmation of authorization from us before starting testing.

5. Use of Personal Data

Personal data submitted as part of a vulnerability report will be used solely to investigate and remediate the vulnerability and is subject to the provisions of the General Data Protection Regulation (GDPR) and the German Federal Data Protection Act (BDSG).

6.1 Submitting a Report

Please send vulnerability reports by PGP-encrypted email to: security@bluerange.io

Our public PGP key is available at keys.openpgp.org. The fingerprint is: 60D903B0A3FF279A6EDA52AE72A169D9B8DB47E8.

We also maintain a security.txt.

Please report vulnerabilities in publicly available source code exclusively through this channel as well, and not as a public issue or pull request.

6.2 Report Contents

To help us understand and resolve the issue quickly, please include the following information:

• Description of the vulnerability and its potential impact
• Affected component: platform, Gateway OS, Gateway Application, Mesh Firmware or app, each with URL, version number, build or hardware model, where applicable
• Test environment: hardware used, configuration and, where relevant, radio environment
• Step-by-step reproduction instructions
• Proof of concept: screenshots, logs, captures or code samples demonstrating the vulnerability (without real user data)
• Your own assessment of severity and potential impact
• Contact details for follow-up questions (pseudonymous details are acceptable)
• Sensitive data accidentally viewed: if you unintentionally accessed personal or confidential data, please describe what you saw without including the data itself

Reports may be submitted in German or English.

6.3 What the Report Should Not Contain

• Do not include actual customer data, personal data, credentials or keys from third-party installations
• Refrain from including malicious payloads, working exploit code or manipulated firmware images that could cause harm if handled improperly

7. Response and Disclosure

After receiving your report, we will acknowledge receipt within five business days and begin validating and classifying the reported vulnerability.

Remediation requires reasonable time: we ask for a period of at least 90 days from the initial report before any public disclosure. This gives us the opportunity to validate and fix the issue, verify the fix and roll it out to all customers. Since updates for gateways and mesh nodes have to be deployed in live building installations, a longer period may be necessary in individual cases; we will agree on this with the reporting person.

If necessary, we will contact the reporting person through the established channels to obtain additional information. We will keep you informed about the progress of the investigation and remediation.

If the vulnerability is confirmed, we assign an internal BRVD identifier, which serves as a reference in further communication and in later security advisories.

Once the vulnerability has been fixed, the timing and details of disclosure will be coordinated with the reporting person.

8. Recognition and Rewards

We do not currently operate a monetary bug bounty program. The introduction of such a program in the future is not ruled out; in that case, this policy will be updated accordingly.

Researchers who report a confirmed vulnerability in accordance with this policy are currently eligible for:

• Public acknowledgment on our security advisories page (with the reporting person’s consent)
• Credit by name in the security advisories for the reported vulnerability (with the reporting person’s consent)
• A letter of appreciation suitable for professional portfolios (upon request)

Appendix: Examples of Vulnerabilities

The following examples are intended to illustrate which types of vulnerabilities fall within the scope of this policy and which do not.

Qualifying Vulnerabilities

• Remote code execution, including on gateways or mesh nodes
• SQL injection and other injection vulnerabilities
• Flaws in authentication or session management
• Bypassing authorization mechanisms and privilege escalation
• Cross-site scripting (XSS) with demonstrated impact
• Cross-site request forgery (CSRF) with demonstrated impact
• Disclosure of sensitive data
• Security misconfigurations with recognizable impact
• Server-side request forgery (SSRF)
• Insecure direct object references
• Bypassing signature or integrity verification of firmware and gateway updates
• Weaknesses in encryption, authentication or key management of the mesh communication, e.g. unauthorized joining of a mesh network, replay attacks or unauthorized triggering of control commands via radio
• Extractable key material that can be used beyond the individual device (e.g. for other devices, networks or customers)

Non-Qualifying Reports

The following are generally not considered qualifying vulnerabilities:

• Vulnerabilities that require physical access to a user’s device, unless they have an impact beyond that individual device
• Vulnerabilities in third-party applications, services, hardware or firmware
• Social engineering attacks
• Denial-of-service vulnerabilities and disruption of radio communication through jamming (please report them anyway; however, due to the testing restrictions, they are not eligible for recognition under this policy)
• Issues identified by automated scanners without demonstrated exploitability
• Missing security headers without demonstrated impact
• Clickjacking without a demonstrated security-relevant action
• Self-XSS (script execution only possible in your own session)
• CSRF on non-security-relevant functionality
• Disclosure of non-sensitive information, including Bluetooth advertising data that is broadcast publicly by design (e.g. beacon identifiers)
• Disclosure of software versions without an associated vulnerability
• Theoretical vulnerabilities without a proof of concept
• Vulnerabilities that are already known or have been previously reported