Open source inside the HMI: the ten risks a GMP site inherits, and the change control that answers them

Monday, ten past nine. The IT security team forwards an advisory: a critical flaw in a widely used open-source library, with exploit code already public. At the production meeting, the QA manager asks whether any of our GMP systems are affected. The SCADA server runs a vendor package on Windows. The operator panels on the packaging line run an embedded Linux image nobody has ever opened. The edge gateway that sends batch data to the historian has its own web interface. The engineering workstation holds three generations of PLC programming tools. Nobody in the room can answer, and the suppliers’ replies come in one at a time over the following three weeks.

Many sites lived exactly that in December 2021, when CVE-2021-44228, the Log4j flaw known as Log4Shell, was published with the maximum CVSS score of 10.0. The vulnerable code was almost never something the site had chosen. It sat inside products, two or three layers down, put there by a developer the site had never met.

Why open source is inside your validated systems

Industrial software is no longer written from the first line. An HMI runtime, a gateway firmware, a historian collector or the installer of an engineering tool is assembled from components: a TLS library for encrypted connections, a compression library, an embedded web server, a database engine, a scripting runtime. Most of them are open source, maintained by projects with no contract with your supplier, let alone with you.

For a GMP site the consequence is simple. The system you qualified is not only the vendor’s application. It is everything underneath, and the parts that change most often are the ones you did not list in the IQ.

The OWASP list, and why only one risk is a CVE

The Top 10 Risks for Open Source Software is an OWASP documentation project whose list was published in 2024, numbered OSS-RISK-1 to OSS-RISK-10. Its starting point is worth quoting, because it is the trap most sites fall into: known vulnerabilities, captured as CVEs, became the key metric of open-source security, yet they “hardly encompass the full spectrum of risks” of depending on open source. Outdated or unmaintained components, name confusion attacks and silent changes do not produce a CVE at all.

In practice, a vulnerability scanner sees the first risk and part of the fifth. The other eight are visible only through an inventory, questions to the supplier and the discipline of change control.

Two cases that show the difference

Log4Shell is risks 1 and 6 together: a classic known vulnerability, made expensive because the library was untracked, buried in Java components of larger products. The only way to know was to ask each supplier, then wait.

XZ Utils is risk 2. On 29 March 2024, CISA reported malicious code embedded in versions 5.6.0 and 5.6.1 of this data compression library, which may be present in Linux distributions, under CVE-2024-3094. CISA’s advice was to downgrade to an uncompromised version. This time the newest release was the dangerous one. A GMP site should remember that the next time someone proposes “always install the latest” as a security policy. What protects the site is knowing which version runs where, and changing it only on purpose.

The SBOM: a lookup table, not a security certificate

The CRA gives the shortest definition. A software bill of materials is “a formal record containing details and supply chain relationships of components included in the software elements of a product” (Article 3(39)). The NTIA report on the minimum elements of an SBOM, published on 12 July 2021, lists seven data fields per component: supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data and timestamp.

Two machine-readable formats dominate: SPDX, standardised as ISO/IEC 5962:2021, and CycloneDX, standardised by Ecma International as ECMA-424 (first edition, June 2024). Either will do.

What an SBOM gives a site is time: “are we affected?” becomes a search answered in minutes, not weeks. It gives no verdict. A listed library may be unreachable in that product, and one missing from a top-level SBOM may still be there. The SBOM tells you where to look and whom to ask.

What the CRA will require of suppliers, and when

Regulation (EU) 2024/2847, the Cyber Resilience Act, entered into force on 10 December 2024. It speaks directly to open source inside products:

• Due diligence on components. Manufacturers “shall exercise due diligence when integrating components sourced from third parties”, including free and open-source components (Article 13(5)), and must report a vulnerability they find in a component to whoever maintains it (Article 13(6)).
• An SBOM, at least for the top level. Annex I, Part II, point (1) requires manufacturers to draw up an SBOM “in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”. Handing it to the user is a choice, not a duty: Annex II, point 9 only covers the case where “the manufacturer decides to make available” the SBOM.
• Security fixes kept apart. Under Annex I, Part II, point (2), “where technically feasible, new security updates shall be provided separately from functionality updates”. For a validated system this is the clause that shrinks the regression testing behind each patch.
• A support period. At least five years, unless the product is expected to be used for less (Article 13(8)); the recitals add that industrial control systems are often used for significantly longer.

Most of this is still ahead. The reporting obligations of Article 14 will apply from 11 September 2026, and the rest of the regulation from 11 December 2027 (Article 71). Products placed on the market before that date fall under the product requirements only if they are substantially modified afterwards (Article 69(2)). The one exception is reporting: Article 69(3) applies the Article 14 obligations to those older products too, so their manufacturer will still have to report an actively exploited vulnerability. For the panels and gateways a site buys this year, that is all the regulation will bring. SBOM, support period and separate security fixes have to be obtained through the contract.

Owners of industrial systems are not left without a text in the meantime. The joint guide Secure by Demand: Priority Considerations for OT Owners and Operators, published on 13 January 2025 by CISA with partner agencies including Germany’s BSI and the European Commission’s DG CONNECT, puts the question plainly under vulnerability management: “Has the manufacturer drawn up a software bill of materials?”

What GMP already asks, and what the revision adds

Nothing here needs a new quality process. Annex 11 (2011) already covers it, clause by clause. Clause 3.1 requires formal agreements with third parties who supply, configure or maintain a computerised system. Clause 4.5 asks that the supplier “be assessed appropriately”. Clause 10 is the one that applies to every patch: “Any changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure.” Clause 11 lists “upgrade history” and “security” among what a periodic evaluation looks at, which is where outdated and unmaintained components (risks 4 and 5) should surface.

The draft revision of Annex 11, put out for consultation from 7 July to 7 October 2025, is not in force, but it shows the direction. Its section 15.13 expects security patches from platform vendors to be deployed “in a timely manner according to vendor recommendations” and adds: “For critical vulnerabilities, this might be immediately.” A change control that takes three months for every patch will not meet that.

From advisory to closed change

The flow that works on a regulated site has five steps, and only one of them is new.

1. Receive. Advisories reach a named owner per system, not a shared mailbox: the supplier’s own notices, national CERT bulletins, the CVE feeds your IT security team already watches.
2. Look up. Search the SBOMs on file. If the component is there, or the SBOM stops at the top level and cannot exclude it, open a question to the supplier the same day.
3. Assess exposure. Is the vulnerable function reachable, from which zone, by whom? A flaw in a web server on a panel that sits in a closed cell zone is not the same risk as the same flaw on a gateway that talks to the corporate network. Zoning buys time here; see zones and conduits: start from the risk.
4. Change. Raise the change with a risk-based test scope. A security-only update with a clear list of changed components needs a targeted regression test, not a requalification. A bundled functional release needs more, which is exactly why the supplier should keep them apart.
5. Record. Update the SBOM on file, the configuration baseline and the periodic review input. If you decided not to patch, record why, and the compensating control that stands in for the patch.

Seven questions for the supplier

Put them in the request for quotation and check the answers before the factory acceptance test; for what supplier documentation can and cannot replace, see what the supplier’s tests can prove for you.

1. SBOM: will you deliver one per release, in SPDX or CycloneDX, and how deep does it go below the top-level dependencies?
2. Monitoring: how do you watch vulnerabilities in the components you embed, and how long do you take to tell customers whether a new CVE affects your product?
3. Maintenance: which embedded components are unmaintained or near their end of support, and what is the support period of the product itself?
4. Separation: are security fixes released separately from functional changes, with release notes that list the components changed?
5. Build integrity: how do you pin versions and verify the sources you build from, and how do we verify the signature or hash of what you ship?
6. Licences: will you state the open-source licences of the delivered components? Do you run a licence compliance programme, for example to ISO/IEC 5230, the OpenChain specification?
7. Integrator additions: are scripts, drivers and packages added during engineering or commissioning declared and included in the SBOM?

Where to start

Do not begin with a tool. Take the five systems whose loss would stop a GMP line or corrupt a batch record, note the product, version and operating system of each, and ask their suppliers for an SBOM and an advisory channel. Rehearse the flow above once, on paper, with Log4Shell, and time the answer to “are we affected?”: that is your baseline. Then check that your change procedure has a route for a security-only update with a reduced test scope; most do not.

Five common mistakes

• Treating the CVE count as the open-source risk. Eight of the ten OWASP risks never appear in a scanner report.
• Filing the SBOM and never reading it. An SBOM is useful only if someone searches it when an advisory arrives, and replaces it with each release.
• Assuming the CRA covers the installed base. Apart from vulnerability reporting, products placed on the market before 11 December 2027 are caught only after a substantial modification. Ask now, in the contract.
• Patching blindly, or never. “Latest” was the compromised version of XZ Utils; “never” is the panel still running a 2015 library. Both skip the assessment that change control exists to force.
• Forgetting the integrator. Scripts and add-ons installed during commissioning are open source too, and they are the least likely to appear in anyone’s inventory.

You cannot validate what you cannot list: the open source inside a GMP system is part of the system, and its patches are changes like any other.

References

• OWASP, Top 10 Risks for Open Source Software (list published 2024), project repository: github.com/OWASP
• Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 3(39), 13(5), 13(6), 13(8), 14, 69 and 71, Annex I Part II, Annex II: eur-lex.europa.eu
• EudraLex Volume 4, Annex 11 Computerised Systems (2011), clauses 3.1, 4.5, 10 and 11: health.ec.europa.eu
• European Commission, draft revised Annex 11, consultation 7 July to 7 October 2025 (not in force), section 15.13: health.ec.europa.eu
• NTIA, The Minimum Elements for a Software Bill of Materials (SBOM), 12 July 2021: ntia.gov
• CISA and partners, Secure by Demand: Priority Considerations for OT Owners and Operators when Selecting Digital Products, 13 January 2025: cisa.gov
• CISA, alert on XZ Utils, CVE-2024-3094, 29 March 2024: cisa.gov
• The item that prompted this article: ISA / automation.com, Top 10 Open Source Software Security Risks, 6 October 2025: automation.com