Security policy
Supported products, how to report a vulnerability in AdiaPure, and how DSH Belgium handles the report.
AdiaPure is manufactured by DSH Belgium. This page explains which products are covered by
our coordinated vulnerability disclosure policy, how to report a problem, and what happens
after you do. The authoritative version of this policy is
SECURITY.md in the
repository.
Supported products and versions
| Component | Supported |
|---|---|
| Controller firmware (application) | the current release; the version is shown in the web interface |
| Bootloader | the version shipped with the current controller firmware |
| Web UI | the web UI served by the current controller firmware |
| BACnet server (BACnet/IP and BACnet MS/TP) | the version built into the current controller firmware |
| Stella screen firmware | the release shipped with the current controller firmware |
Host tools (adiapure-cli, adiapure-config, adiapure-dlviewer, adiapure-ota-host, adiapure-provision, ota-image-tool) | the release matching the current controller firmware |
| Hardware | controller board v0.3, Stella screen and enclosure at the current revision |
Only the current release is supported with security fixes. Older hardware revisions (pre-v0.0.1, v0.1 and v0.2) and firmware older than the current release are out of support. A report about an older version is still welcome, but we may not be able to fix it.
The controller and the Stella screen are supported for 10 years from the first unit placed on the market; security fixes for the current release are provided throughout that period. The end-of-support date will be published before the first shipment.
How to report a vulnerability
Email Leandro Marceddu at [email protected].
Please do not open a public GitHub issue, pull request or discussion for a security problem, and do not disclose it publicly before we have agreed a date.
Include as much of the following as you can:
- Product and component — for example controller firmware, bootloader, web UI, BACnet server, Stella screen firmware, a host tool, or the hardware.
- Version and hardware revision — the firmware version shown in the web interface, and the board revision printed on the controller or screen.
- Impact — what an attacker could do, what access or position they need, and whether the affected unit is reachable from a network or needs physical access.
- Reproduction — the steps, the tools you used, and the smallest proof of concept that demonstrates the problem.
- Logs — relevant log excerpts or screenshots, with serial numbers, credentials, keys and customer data removed.
- Credit — whether you want to be credited, and under what name.
No PGP key is available, so email to this address is not encrypted. Do not send passwords, private keys, customer data or an exploit that could endanger a live installation. Describe what you have first and we will tell you how to proceed.
What happens next
- Acknowledgement — we acknowledge your report within 3 working days.
- Triage — we confirm the problem, assess its severity and the affected versions, and may ask for more detail. Complex reports can take longer to triage; we keep you informed.
- Fix — we develop and test a fix. If a fix will take time, we will discuss an interim mitigation with you.
- Coordinated disclosure — we agree a disclosure date with you. We publish an advisory describing the affected products and versions, the impact, the fixed version and any mitigation, and request a CVE identifier where appropriate.
- Credit — we credit you in the advisory unless you ask to remain anonymous.
Safe harbour
We will not take legal action against you, or report you to law enforcement, for security research carried out in good faith and in accordance with this policy. This statement covers DSH Belgium's own position; it cannot bind third parties.
Good-faith research means:
- testing only devices you own or have explicit written permission to test, on an isolated network rather than a production installation;
- not accessing, modifying, copying or exfiltrating data that is not yours — stop as soon as you have enough evidence, and do not retain the data;
- not disrupting or degrading production systems, or any system you do not own — no denial-of-service testing, no persistence and no pivoting into other systems;
- not using social engineering, phishing or physical intrusion;
- keeping the report and its details confidential until coordinated disclosure;
- complying with applicable law.
If you are unsure whether a test is covered, ask us before you run it.
No bug bounty
We do not run a bug bounty programme and cannot offer monetary rewards. We are happy to acknowledge and credit good-faith reports in the advisory.
Out of scope
- Social engineering and phishing of DSH Belgium staff, customers or suppliers.
- Physical attacks that do not demonstrate a reproducible security impact, such as opening the enclosure, theft or vandalism.
- Third-party services and infrastructure not operated by DSH Belgium, including the hosting provider, GitHub, email providers and distributors. Report those to the provider concerned.
Last reviewed: 23 October 2026.