Nexilica runs a coordinated vulnerability disclosure (CVD) programme for its products and sites. If you have found a security vulnerability, this page tells you how to report it, what we commit to in return, and the rules that keep good-faith research protected. It is the same policy kept as SECURITY.md in the product repositories; where the two ever differ, this page is authoritative.
1. Reporting a vulnerability
Email with the details. Do not open a public issue, pull request, discussion, or social-media post for a security vulnerability, and do not disclose it to any third party, until we have coordinated a disclosure with you: a public report hands the vulnerability to everyone before there is a fix. Email is the only reporting channel.
A good report names the affected component and the version, image tag or commit you tested; the type of issue and its impact; step-by-step instructions to reproduce it, with proof-of-concept code, requests or configuration where that helps; and any logs, screenshots or CVSS v3.1 vector you already have. You do not need to provide a fix or a score - we triage and score every report ourselves.
2. Scope
In scope: the NeMo platform and its gateway; TestHive, the test application and its hardware; the electronics and firmware Nexilica ships under its own name; and the nexilica.com, nemo.nexilica.com and testhive.nexilica.com sites with the services behind them. For versioned products a supported release applies: the current stable-channel one and the one before it. Issues that reproduce only on an unreleased build are still welcome but are not counted against the fix targets.
Out of scope: findings that require physical access to a device or host; social engineering of Nexilica staff or customers; volumetric denial of service; reports from automated scanners with no demonstrated impact; and vulnerabilities in third-party dependencies that we already track and patch, unless you can show an exploit path specific to one of our products.
3. What we commit to
Timelines start when your report reaches . We confirm receipt within 3 business days. We validate the report and assign a CVSS v3.1 severity within 10 business days, and tell you our assessment. From triage, we fix critical issues within 30 days, high within 60 days, medium within 90 days, and low with the next scheduled release. If we cannot meet a target we will say so and give you a revised date rather than letting it lapse in silence.
4. Coordinated disclosure
We disclose in coordination with you. Public disclosure happens once a fix is available, or 90 calendar days after we acknowledge the report, whichever comes first; the deadline is extendable by mutual agreement, for example when a fix needs a coordinated fleet rollout. We ask that you hold your own disclosure until the coordinated date. An advisory names the affected versions, the fixed-in version and the CVSS score. For products deployed as self-updating nodes, such as NeMo, a fix is available when the fixed image is published on the stable channel, not merely merged.
5. Actively exploited vulnerabilities
A vulnerability we have evidence is being actively exploited is not only a disclosure matter: under Regulation (EU) 2024/2847 (Cyber Resilience Act), article 14, it additionally triggers a regulated reporting procedure to ENISA and the relevant CSIRT on a statutory clock. If your report concerns active exploitation, say so explicitly so we start that procedure immediately.
6. Safe harbour
We will not pursue or support legal action against you, and we consider your research authorised under this policy, for security research conducted in good faith that respects these rules: report through and give us reasonable time to fix the issue before disclosing it to anyone else; do not access, modify, copy or exfiltrate data that is not your own - in a multi-tenant platform that means never reading, altering or retaining another tenant's or customer's data, and using only accounts and data you own or have explicit permission to test; do not degrade, disrupt or deny service to our systems or their users; do not use social engineering, phishing or physical intrusion against Nexilica, its staff or its customers; stop as soon as you have demonstrated a vulnerability, and do not use it beyond what the proof of concept needs. Research that breaks these rules is outside this safe harbour, and the commitments above do not apply to it.
7. Credit
With your permission, we credit reporters by name or handle in the published advisory. Tell us in your report how you would like to be credited, or that you would prefer to stay anonymous. Nexilica does not currently run a paid bug-bounty programme; recognition is by credit in the advisory.
Machine-readable contact: /.well-known/security.txt (RFC 9116).