Software transparency and SBOMs
We maintain a software bill of materials for every product we ship, and we will provide it to you on request. This page explains what it contains, what format it comes in, and why we send it to you rather than posting it publicly.
What we maintain
Ask us for the third-party components in a released version and we will give you the list — component names, versions and licences. Releases are built from tagged commits, so the component set for any version inside its support period is recovered from source control rather than reconstructed from memory.
We do not yet generate that as a machine-readable file automatically at release time. Building it into the release process is in progress; until it lands, the list is compiled when you ask, which is the honest reason the response target below is ten working days rather than the same afternoon.
- Granularity
- Per released version, not per product family
- Depth
- Top-level dependencies, and transitive dependencies where the build tooling resolves them
- Available for
- Any version inside its support period
How to request one
Email security@gdsinstruments.com with:
- The product and exact version — from Help → About, or the firmware version from the controller
- Your preferred format, if you have one
- Who you are and, if you are not the end user, which customer you are acting for
We aim to respond within ten working days. There is no charge. For competent authorities exercising powers under the Cyber Resilience Act, contact us at the same address and we will provide documentation directly through the channel you specify.
Why we do not publish SBOMs openly
The Cyber Resilience Act requires manufacturers to maintain an SBOM and to make it available to authorities on request. It does not require publication, and we have chosen not to publish ours as open downloads.
A complete, versioned dependency inventory for a long-lived instrument is a useful document for an attacker: it says precisely which library version is running inside a machine that may sit on a laboratory network for a decade, and it does so for every customer at once. Sending it to identified requesters gives you the transparency you need for your own vulnerability management without publishing a targeting aid.
We are not using this as a reason to be unhelpful. If you need an SBOM, ask and you will get it — under an NDA if you are not a customer, as below.
Do you need an NDA?
If you are a GDS customer, no. Your supply contract already covers it, and we ask only that you use the SBOM for your own vulnerability management and do not republish it.
If you are not a customer — a distributor, a researcher, or someone assessing us on a third party’s behalf — we will ask you to sign a non-disclosure agreement first. A complete component and version inventory is exactly the document we decline to publish openly, and releasing it outside a contract would undo that.
Competent authorities exercising powers under the Cyber Resilience Act are not asked for an NDA. That is an obligation rather than a commercial arrangement.
VEX statements
An SBOM tells you which components are present. It does not tell you whether a published vulnerability in one of them actually affects the product, and in our experience that is the question customers really need answered.
Scanning an SBOM for our control software will typically return a list of CVEs in bundled libraries, most of which are not reachable in the way we use the component. Rather than leave you to guess, we will issue a VEX (Vulnerability Exploitability eXchange) statement for a specific CVE and product version, saying which of these applies:
| Status | Meaning |
|---|---|
| Not affected | The component is present but the vulnerable code path cannot be reached in our product. We state why. |
| Affected | The product is exploitable. We will publish an advisory and ship a fix. |
| Fixed | The vulnerability applied to an earlier release and has been remediated. We name the version that fixed it. |
| Under investigation | We have not finished assessing it. We will come back to you rather than leave the question open. |
This is particularly useful in accredited laboratories, where an unnecessary software change may trigger revalidation. A documented "not affected" statement is often more valuable than a patch.
The kinds of components we use
Without publishing a full inventory, in broad terms our software includes third-party components for:
- The application runtime, and the user interface and theming frameworks built on it
- Charting and data visualisation
- Numerical and symbolic mathematics, and the parsing of user-entered expressions
- Data storage, serialisation and identifier generation
- Spreadsheet export, for results and reports
- Instrument communication, including serial, network and inter-process channels
- Logging and diagnostics
- Cryptography, used among other things to verify the signature on a licence file
Instrument firmware is smaller again, and a different shape. It runs on bare metal with no operating system, and the third-party content amounts to the processor vendor’s headers and chip support library plus the C runtime that ships with the compiler toolchain. The communications — CAN, RS485, USB, serial — and the signal processing are our own code rather than libraries we import.
If you are a distributor or importer
Distributors and importers placing our products on the EU market have their own obligations under the Cyber Resilience Act, including satisfying themselves that the manufacturer has met theirs. Ask us for what you need. The declaration of conformity and the technical documentation follow the conformity assessment, which is due by December 2027; before then we can give you component lists and the material published here. Contact us at security@gdsinstruments.com.
If you need to deal with a representative established in the Union rather than with us directly, see our authorised representative.