Supplier and supply chain security
Our systems contain hardware and software we did not write. Under the Cyber Resilience Act we are responsible for the security of the integrated product regardless of where a component came from, so this is how we handle what we buy in.
Where responsibility sits
Annex I Part II of the Regulation is explicit that a manufacturer must address vulnerabilities in the components integrated into its products, throughout the support period. A vulnerability in a third-party library inside our software is our problem to resolve, not something we can pass to you as the component author's issue.
In practice that means we cannot simply take a supplier's word for it. What we can do is choose components whose maintainers we can rely on, know what we have shipped, and act when something changes.
What we buy in
| Category | Examples | How we handle it |
|---|---|---|
| Open source libraries | Application and user interface frameworks, numerical and symbolic mathematics, spreadsheet export, logging, serial and inter-process communication | Tracked per release, checked against the published advisory database at build time, upstream advisories monitored |
| Commercial software components | Charting and data visualisation | Supplier support and patch commitments checked before adoption; version currency reviewed at each release |
| Embedded software in bought-in hardware | Microcontroller firmware, communications modules, motor and servo drives | Assessed at selection; we ask for the supplier's vulnerability contact and update route |
| Contract manufacturing and assembly | PCB assembly, firmware programming | Firmware provided by us and verified against our signed image; programming is not left to the assembler's discretion |
| Operated services | Hosting, email, source control, CI | Reputable providers with published security practices; access controlled and reviewed |
Choosing a component
Before a new third-party component enters a product we consider:
- Whether it will still be maintained in ten years. Its track record on security fixes, and what we would do if the project were abandoned — we may end up maintaining it ourselves.
- Whether its maintainer has a route for reporting vulnerabilities.
- Whether its licence lets us patch and redistribute. A fix we cannot ship is not a fix.
- What it brings with it. Every transitive dependency becomes ours to track.
Instruments outlive software. A controller placed on the market today carries a ten-year support commitment and few open source projects will promise ten years of security fixes, so in the firmware and control paths we prefer a small dependency we could maintain ourselves to a large one we could not.
Monitoring and response
- Our.NET builds check dependencies against the published advisory database and warn on known vulnerabilities, so a newly published issue in a component we ship is flagged to us rather than discovered by a customer. Firmware carries few third-party components and those are tracked by hand.
- We monitor upstream advisories for the components in our products.
- When something is flagged, we assess whether our product is actually exploitable through it — see VEX statements under software transparency. Presence of a vulnerable component is not the same as a vulnerable product, and we would rather tell you accurately that you are unaffected than push a needless update into a validated laboratory.
- Where we are affected, the issue enters the same process as any other vulnerability: fix, advisory, update.
- Where we find a vulnerability in a third-party component, we report it to the maintainer and share any patch we have written. That obligation is in the Regulation, and it is also how open source is supposed to work.
What we ask of our suppliers
If you supply GDS with hardware containing embedded software, or with software components, we will ask you for:
- A contact address for reporting vulnerabilities, and your disclosure policy if you have one
- Notification when you publish a security update affecting a component we use
- An SBOM, or at minimum a component and version list, for software you supply
- Your support period for the component, and notice before it ends
- Signed or checksummed releases, so we can verify what we have received
- Your own CRA position, where your component forms part of a product we place on the EU market
These are the same questions our customers ask us, and some suppliers will not have good answers yet. Where one cannot, we do the work ourselves rather than assume the risk away. Questions to security@gdsinstruments.com.
How far back this reaches
Not to everything we have ever shipped. Under Article 69, a product placed on the market before 11 December 2027 is caught only if it is substantially modified after that date, so these questions apply to what we place on the market from then on.
Reporting is the exception: the Article 14 duty covers the whole installed base. A 2019 instrument never acquires an SBOM or a cybersecurity CE marking, but a vulnerability being exploited in one is still reportable and still gets an advisory.
What we will actually fix is set by our support periods, not by the Regulation.
Counterfeit and grey-market parts
We buy electronic components only through authorised distribution, never on the broker or open market where counterfeits circulate. A substituted microcontroller is a security problem as much as a quality one: it may not run the firmware we signed, and may not behave as its datasheet says under load.
If you have bought a GDS instrument second-hand or from an unauthorised reseller, contact us with the serial number. We will tell you what it should contain, and whether it is within a support period.