What a vulnerable dependency means in a semiconductor fab

In a fab, a vulnerable dependency usually sits inside software you did not write, on equipment you cannot freely patch. So the first job is triage, not updating: find which tool contains it, judge exposure and reachability, then choose a patch window or a compensating control. NIST's OT guidance says updates need testing and planned outages.

This post walks through one hypothetical alert from day zero to resolution. It names no real vendor or incident. We use NIST's operational technology guide for the constraints on a production floor. We did not review semiconductor-specific standards for this article, so none are cited.

Day zero: what do you actually know?

A public advisory lands for an open source library. You know a CVE ID and affected versions. You do not yet know whether any of your equipment includes it. A library can be buried in tool software, a vendor's remote service agent, a data collection gateway or a monitoring server.

The question is "where do we run this?" and it is only answerable if you have an inventory. This is where a software bill of materials helps. CISA describes an SBOM as a nested inventory of the components in software. If your equipment vendors give you SBOMs, you can search them by component name. If they do not, ask. If they will not, you start by asking each vendor directly, and you record the answers.

Day one: is it exposed?

Not every instance matters equally. Use three filters.

1. Network position. Is the component on a segment reachable from the corporate network or from a vendor connection? NIST's OT guide recommends logical separation, a DMZ and layered topology with the most critical communications in the most secure layer.
2. Reachability. Does the software call the vulnerable function? A vendor can often answer this, and a statement that the product is not affected can be shared as a VEX document. CISA describes VEX as an attestation of whether a product is affected by a vulnerability.
3. Known exploitation. Check CISA's Known Exploited Vulnerabilities catalog. A match raises urgency regardless of where you think the component sits.

Week one: can you patch?

On a production floor, rarely quickly. NIST's guide says OT updates cannot always be applied on a timely basis, that they need thorough testing by the vendor and the end user, that outages must be planned days or weeks in advance, and that revalidation may be required. It also notes many OT systems run older operating systems that vendors no longer patch.

So the vendor is part of the answer. Ask for a fix, its test status and its expected release date. Do not patch the tool software yourself in a way that voids support or changes validated behavior.

While you wait: which compensating controls help?

NIST says that when controls are not supported by a legacy OT system, the security program should tailor controls and use compensating ones. Reasonable ones here:

• Remove or restrict the network path that makes the component reachable.
• Require multi-factor authentication for any remote access, which NIST recommends for OT.
• Disable unused ports and services after testing that the change does not affect operation.
• Increase monitoring on the affected segment and on vendor connections.
• Restrict who can log in to the affected host.

Which standards belong in the conversation?

ISA/IEC 62443 is a series of standards for industrial automation and control systems, covering asset owners, service providers and product suppliers. Its part 4-1 covers secure product development lifecycle requirements, which is relevant when you ask a vendor how it handles vulnerabilities in its own components. Whether the series applies to a particular tool is a question for your engineering and compliance staff.

What are the limits?

Triage depends on the quality of your inventory and on vendor cooperation. A "not reachable" answer is a claim to verify where possible. And a compensating control reduces risk without removing the vulnerability, so keep the item open until a patch is applied.

What to do

1. Build or request SBOMs for the software on each production tool.
2. Make the SBOMs searchable by component and version.
3. When an advisory lands, search first, then check exposure, reachability and KEV status.
4. Ask the vendor for a fix date and a VEX statement.
5. Apply compensating controls to the affected segment while you wait.
6. Schedule the patch in a planned outage and keep the item open until it is done.

Quick check

Sources

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• CISA, Software Bill of Materials (SBOM) and VEX
• CISA Known Exploited Vulnerabilities Catalog
• ISA/IEC 62443 series overview

Last reviewed: 18 October 2026.