What does a vulnerable dependency mean in a chemical plant?

In a chemical plant, a vulnerable dependency is an outdated open source library inside software or firmware that runs or supports process equipment, such as an operator screen, a gateway or an engineering tool. The risk is real but the fix is slower than in office IT, because changes to running plants need testing and planned windows.

Where do dependencies hide in a plant?

Office software is easy to picture: a web app with a package.json. A plant has a longer list. Operator workstations run HMI and historian software. Gateways and protocol converters sit between networks. Engineering laptops hold configuration tools for controllers. Remote access tools reach vendors and contractors. Every one of them is built from components, many of them open source, and the plant operator usually did not choose those components. The vendor did.

That is why the question "are we exposed?" is hard to answer. When a new library flaw is announced, the owner of an office application can search a repository. The owner of a gateway has to ask the vendor, and wait.

Why is the fix not just an update?

The ISA/IEC 62443 series is the family of standards for security of industrial automation and control systems. ISA states that it applies across sectors that use such systems, including process industries such as chemicals and oil and gas. The series has separate parts for different roles, and several matter here:

• Part 2-1 covers security program requirements for asset owners, the plant side.
• Part 2-3 covers patch management in the control system environment, which exists because patching there differs from patching a laptop.
• Part 2-4 covers security program requirements for service providers.
• Part 3-2 covers security risk assessment for system design.
• Part 4-1 covers secure product development lifecycle requirements, aimed at the vendors who build the products.

The existence of a dedicated patch management part tells you something. In a plant, an update may need vendor approval, testing on a spare system and a scheduled shutdown, and a rushed change could affect the process itself. Plants therefore often rely on layered measures while a patch waits, such as network separation, tight remote access control and monitoring. Whether a particular measure is enough depends on your risk assessment, so do that work with your control systems engineers and the vendor, not alone.

How do you triage a vulnerable dependency on the shop floor?

Ask four questions, in this order.

1. Where is the component? Which product, version and site? You need an inventory first. Ask vendors for a software bill of materials for each product, and keep it with the asset record.
2. Can the vulnerable code be reached? A flaw in a library function that the product never calls is a different problem from one on an exposed network service. Ask the vendor for an exploitability statement, such as a VEX document, where they can provide one.
3. What can an attacker reach from there? Look at the network position. A device on an isolated segment with controlled access is in a different place from one reachable from the business network.
4. What is the consequence? For a control system, think about safety, environmental and production impact, not only data loss. The plant's own risk assessment should drive priority.

Then decide: patch in a planned window, apply a compensating measure, or accept the risk with a recorded owner and review date.

What can software tooling do here?

Tooling helps on the software side of the problem. Safeguard can ingest SBOMs and scan dependencies, rank findings by whether the vulnerable code is reachable, and run on premises or in an air-gapped setup for sites that cannot reach the internet. It does not scan live controllers or replace operational technology monitoring, and decisions about changes to plant systems stay with qualified engineers.

CISA describes the chemical sector as turning raw materials into more than 70,000 products, with several hundred thousand facilities handling chemicals along a global supply chain. A sector that wide has a very large number of vendors, which is why supplier information matters so much.

What to do

1. List control system software and firmware by site, with product and version.
2. Ask each vendor for an SBOM and a vulnerability disclosure contact.
3. Keep SBOMs with the asset records, and update them when firmware changes.
4. Write down your patch process with your engineers, including testing and approval steps, using IEC 62443 part 2-3 as a reference.
5. Map network zones and remote access paths for each asset group.
6. For each new vulnerability, apply the four questions and record the decision.
7. Add security and SBOM clauses to purchasing contracts for new equipment.
8. Review the list every quarter and after any major change.

Quick check

Sources

• ISA: ISA/IEC 62443 Series of Standards
• CISA: Chemical Sector
• CISA: Software Bill of Materials

Last reviewed: 18 October 2026.