Safeguard
Software Supply Chain•

Construction equipment software: what a vulnerable dependency means

Software on site equipment ages like any other. See what a vulnerable library means for machines, how OT standards frame patching, what to ask suppliers.

Safeguard Security Team
4 min read

A vulnerable dependency in construction equipment software is a flaw in a library that a machine, a gateway or a site system uses. It matters on the shop floor only if an attacker can reach the code and the device does something physical. Ask suppliers what is inside, how long it is supported and how patches reach you.

This is a calm explainer. We cite standards we fetched and describe no incident.

Why does a library flaw matter for a machine?

Modern site equipment contains software: controllers, telematics units, building automation, door and gate systems, Wi-Fi gateways and remote support tools. Most of that software uses open source components, and any component can have a flaw.

NIST SP 800-82 Revision 3, the Guide to Operational Technology Security, defines operational technology as programmable systems and devices that monitor or control physical processes. Its examples include industrial control systems, building automation, transportation systems and physical access control. It describes OT security as needing to account for unique performance, reliability and safety requirements. A site system that controls a physical process belongs in that frame, even when the vendor does not call it OT.

A flaw is serious in proportion to three questions. Can an attacker reach the vulnerable code, for example through a network port or remote support link? What can the device do if it is misused? Can the device be updated safely?

Why is patching harder than on an office laptop?

An update to a machine controller is not a monthly reboot. It may need a stopped machine, a supplier visit, a safety re-check and a maintenance window. ISA/IEC 62443 reflects this by treating patch management in industrial automation as its own topic, in part 2-3, and by splitting duties among asset owners, system integrators, product suppliers and service providers.

Part 4-1 of the series sets requirements for a secure product development lifecycle, which is the supplier side of the problem. Part 3-3 defines system security requirements and security levels so an owner can choose protection to match business risk.

The consequence: do not copy an office patching deadline onto a machine. Use a risk based rule that includes the safety case.

How do you decide what to act on?

Use three filters in order.

Is it exposed? A device on an isolated network segment with no remote access is a different case from one reachable from the internet.

Is it exploited? CISA's Known Exploited Vulnerabilities catalogue lists vulnerabilities seen exploited in the wild. A match raises priority.

Is the vulnerable code actually used? A library may be present while the vulnerable function is never called. Reachability analysis helps with that question, though a supplier is usually the one who can answer it for a closed device.

What should you ask suppliers?

Ask for a list of software components inside the product, which is a software bill of materials. Ask how long security updates are provided, how updates are delivered and tested, how to report a vulnerability and how quickly they respond. Ask which remote access paths exist and how they are secured. Put the answers into the purchase contract.

Safeguard works with software bills of materials and dependency analysis for code you build or receive, and the same questions apply to firmware and gateway software you buy.

What to do

  1. List equipment on site that runs software or connects to a network, with the supplier and support end date.
  2. Separate networks so site systems cannot be reached from guest or office Wi-Fi.
  3. Ask each supplier for a component list and an update policy.
  4. Check the supplier's advisories against the Known Exploited Vulnerabilities catalogue each month.
  5. Agree a maintenance window for updates with the safety lead.
  6. Remove or disable remote access that nobody uses.

Quick check

Is an office patch deadline right for a machine?

Not automatically. Machine updates may need downtime, supplier involvement and a safety check. Use a risk based rule that weighs exposure, exploitation and safety.

What is OT under NIST SP 800-82?

Programmable systems and devices that monitor or control physical processes, such as industrial control systems, building automation and physical access control.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.