Software supply chain risk becomes physical when the code in question sits in operational technology, the systems that measure and move things. A flaw in a library inside a controller, gateway or monitoring package can affect equipment that people work around. On a mine site, the consequence is safety, not just downtime.
This post explains the mechanism and what to ask. It does not describe any specific mining incident, because none of the sources fetched for this article documented one, and we will not invent one.
What counts as operational technology on a mine?
NIST's Guide to Operational Technology Security, SP 800-82 Revision 3 (September 2023), covers industrial control systems, building automation, transportation, physical access control, and physical environment monitoring and measurement. Its stated aim is to secure OT while accounting for performance, reliability and safety requirements.
CISA describes industrial control systems and OT as the systems and devices that interact with the physical environment. Mining is not named on the CISA page we fetched, so we make no claim about how CISA classifies it. The mechanism, however, does not depend on a label.
Typical examples at a site, depending on what you operate, are fleet management and dispatch software, ventilation and gas monitoring, pumping and dewatering control, conveyor control, and remote operation consoles. Check your own asset list for the real answer.
How does a software dependency become a physical risk?
Walk the chain in four steps.
First, a vendor ships a product built from open source and commercial components. Few buyers see the list.
Second, one component has a flaw. It may be a parsing library, a web server embedded in a device, or an update client.
Third, the device sits on a network that reaches other devices. Remote support links, contractor laptops and flat networks make that reach wider.
Fourth, the affected function matters for safety. A monitoring system that stops reporting, or a controller that accepts a wrong command, changes what people on the ground can trust.
Not every flaw gets that far. Many are not reachable, and many devices are well isolated. The point of supply chain work is to find out which ones are.
Why are OT updates slower than IT updates?
NIST frames OT security around performance, reliability and safety. That is the reason a patch cannot always be pushed on a Tuesday. A restart may stop a process, and a change may need testing before it touches equipment people rely on. So known flaws can live in OT for a long time.
That makes inventory more valuable, not less. If you cannot patch quickly, you need to know exactly what is exposed so you can isolate it, monitor it and plan the change.
Who is responsible?
The ISA/IEC 62443 series assigns requirements to asset owners, product suppliers, integrators and service providers, and calls shared responsibility an essential building block of automation cybersecurity. Part 4-1 covers secure product development lifecycle requirements for suppliers. Part 2-3 addresses patch management. For a mine operator, this gives you vocabulary for supplier contracts: you can ask a vendor how its development lifecycle aligns to 4-1 without claiming the vendor is certified.
What to do
- List every OT product and the vendor behind it, including remote support tools.
- Ask each vendor for a software bill of materials. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components.
- Match the components against known vulnerability data and mark which ones are reachable from a network you do not control.
- Segment networks so that a flaw in a monitoring package cannot reach control functions.
- Put patching and compensating controls in the contract: response times, advisories, and who tests changes.
- Review contractor and vendor remote access paths first. They are the most common bridge from IT into OT.
- Write down which functions are safety relevant and check them against NIST SP 800-82 guidance with your safety team.
For your own software, such as site dashboards and integrations, Safeguard can generate SBOMs and run reachability analysis to separate flaws that matter from noise. It does not replace OT specific monitoring, and you should apply it to code you can scan.
Quick check
Does a vulnerable library always put people at risk?
No. It depends on whether the code is reachable and whether the affected function matters for safety. Inventory and reachability tell you which cases matter.
Why not simply patch faster?
OT changes can affect performance, reliability and safety, so they often need testing and a maintenance window. Isolation and monitoring cover the gap.
What is the first document to ask a vendor for?
An SBOM, followed by their vulnerability response and patch process.
Sources
- NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
- CISA: Industrial Control Systems
- ISA/IEC 62443 series of standards
- CISA: Software Bill of Materials
Last reviewed: 18 October 2026.
