Coordinated vulnerability disclosure policy
If you have found a security vulnerability in a GDS Instruments product, we want to hear about it. This page explains how to reach us, what we will do, and the protections that apply to good-faith research.
- Version
- 1.0
- Effective
- 11 September 2026
- Next review
- 11 September 2027, or sooner once product lifecycle work changes a support period
- Applies to
- All GDS Instruments software, firmware and instruments in their supported period
How to report
Email security@gdsinstruments.com. This is a monitored mailbox reaching our engineering and quality teams, not an individual.
If the report contains sensitive detail such as a working exploit, encrypt it with our PGP public key. The same contact details are published in machine-readable form at /.well-known/security.txt and in the user instructions supplied with our products.
What to include
- The product and version affected — for software, the version string from Help → About; for an instrument, the model and firmware version from its serial label or controller display
- A description of the vulnerability and its impact
- Steps to reproduce, ideally with a proof of concept
- Any configuration needed to trigger it, such as a specific network topology or licence mode
- Whether you believe the issue is already being exploited
- How you would like to be credited, if at all
Tell us immediately if exploitation is under way
Put it in the subject line. Where a vulnerability in one of our products is actively exploited, Article 14 of the Cyber Resilience Act requires us to send an early warning to ENISA and our national CSIRT within 24 hours of becoming aware. We cannot meet that clock if the report sits unread in a general mailbox.
What we will do
The timescales below are our operational targets. Complex issues in embedded firmware, or issues in third-party components where we depend on an upstream fix, can take longer — we will tell you when that is the case rather than going quiet.
Three working days is the outside limit for acknowledging a routine report, not the rate at which we look. The mailbox reaches several people rather than one, so a report does not wait on any individual being at their desk, and anything indicating active exploitation is triaged as soon as it is seen: the Article 14 clock runs from the report reaching us, not from someone opening it.
| Stage | Target |
|---|---|
| Acknowledge your report | 3 working days |
| Initial triage and severity assessment | 10 working days |
| Progress updates while we work | Every 14 days |
| Fix or mitigation for critical and high severity | 90 days |
| Fix or mitigation for medium and low severity | Next scheduled release |
| Advisory published once an update is available | With the release |
We assess severity using CVSS v4.0 and publish the base score, which describes the vulnerability itself rather than any one installation. Many GDS instruments run on isolated laboratory networks, and where that is true of yours the practical risk may be lower than the base score suggests — CVSS environmental metrics exist so that you can make that adjustment against your own deployment. We do not make it on your behalf, because we cannot see your network, and we do not treat network isolation as a substitute for a fix.
What you will hear from us
- An acknowledgement, with a case reference and a named contact
- The outcome of triage: whether we reproduced the issue, its severity, the affected versions, and what we plan to do by when
- An update at least every 14 days while we work, even when there is little to report
- The release date before the advisory is published, with the advisory's wording about your report and your credit line for you to check
- A link to the advisory on the day it is published
If we are going to miss a date, we will tell you before it passes, with the reason and a new date.
If we conclude that a report is not a vulnerability, is out of scope, or affects a product beyond its support period, we will tell you in writing and explain why. If you disagree, reply with more information and we will look again.
Disclosure
We ask that you give us 90 days from acknowledgement before disclosing publicly, so that customers have an update to move to. We will:
- Keep you informed as set out above
- Request a CVE identifier where the issue warrants one
- Publish an advisory on this site when the update is available, describing the vulnerability, the affected versions, the severity and the remediation steps
- Credit you by name, handle or organisation, unless you would rather not be named
- Agree a coordinated date with you if you intend to publish your own write-up
If we cannot fix an issue within 90 days we will explain why and agree a revised date with you. We will not ask you to stay quiet indefinitely.
If the details become public in the meantime, or the vulnerability is being exploited, we will tell you and publish an advisory straight away with whatever mitigation we have, rather than wait for the fix.
Coordinators and other vendors
If you would rather report through a coordinator, such as your national CSIRT, we will work with them in the same way and to the same timescales. Where a vulnerability affects several vendors, for example through a shared component, we will work to the disclosure date set by the coordinator or the component's maintainer.
An embargo controls what is published, not what we tell the authorities. Where a vulnerability is actively exploited, the Cyber Resilience Act requires us to notify the authorities and inform affected users, whatever embargo is in place. Notifications to the authorities are not public, and we will tell you when we have made one.
When we find a vulnerability in a third-party component we use, we report it to the component's maintainer and give them the same 90 days we ask of you.
Safe harbour
We are taking legal advice on our safe harbour wording and will publish it here once it is settled. In the meantime, report to us in good faith and we will engage with you in good faith — but we are not yet making a formal legal undertaking, and we would rather say so than publish one nobody has reviewed.
Good faith means staying within these boundaries:
- Test only on equipment and software you own or have written permission to test
- Access only the minimum data needed to demonstrate the issue; stop as soon as you have it
- Do not exfiltrate, retain or publish personal data or customer test data, and delete anything you encounter incidentally
- Do not degrade or disrupt our services or our customers' systems, and do not attempt denial of service
- Do not use social engineering, phishing, or physical intrusion against GDS staff or premises
- Give us a reasonable opportunity to fix the issue before disclosing it
Do not test against instruments running live experiments
Our systems control real specimens under load. A triaxial or consolidation test can run continuously for days or weeks, and interfering with the control loop can destroy an irreplaceable specimen, invalidate a commercial testing contract, or damage the apparatus. Please test only on idle equipment on a bench. If you cannot reproduce an issue safely, describe it to us and we will reproduce it ourselves in our own laboratory.
Scope
In scope
- GDSLAB control and acquisition software, all supported versions, and its associated data and results components
- Firmware in GDS instrument controllers, pressure and volume controllers, and data acquisition hardware
- Licensing and update components distributed with our software
- GDS-operated web services, including this site and www.gdsinstruments.com
Out of scope
- Products beyond their published support period
- Third-party software we resell but do not develop — we will forward the report to the vendor and tell you we have done so
- Findings with no demonstrable security impact: missing headers with no exploitable consequence, self-XSS, version disclosure, weak TLS ciphers on a static marketing site
- Reports produced solely from automated scanner output with no analysis or proof of concept
- Denial of service, volumetric or resource-exhaustion testing
- Attacks requiring physical disassembly of an instrument the attacker already controls
- Social engineering of GDS staff, customers or suppliers
Recognition
We do not operate a paid bug bounty programme. We recognise reporters by crediting them in the published advisory and in an acknowledgements list, where they wish to be named. We would rather be straightforward about that than imply a reward that does not exist.
We will ask how you would like to be credited and show you the wording before the advisory is published. If you would rather not be named, we will not name you to anyone outside the team handling your report. If several people report the same issue independently, we credit each of them.
If you are unhappy with our response
If you believe we have mishandled a report or are not taking an issue seriously, escalate to security@gdsinstruments.com marked for the attention of the Managing Director. You also have the option of reporting to your national CSIRT, which can coordinate with us on your behalf.
Policy status
This policy describes how we intend to handle reports. It is not a contract, does not create legal rights, and does not authorise you to act unlawfully or to breach obligations you owe to anyone else. We may update it; material changes will be noted here with a new version number and date.