On a mining site, a vulnerable dependency is a flaw in a library inside software that reads sensors or commands equipment. Whether it matters depends on whether an attacker can reach that code and what the machine does when it misbehaves. The work is inventory first, then reachability, then a careful patch plan.
Why is a mine different from an office?
Operational technology is the term for programmable systems that monitor or control physical processes. NIST SP 800-82 Revision 3, published in September 2023, covers industrial control, building automation, transportation and physical access control systems. It says securing them must account for performance, reliability and safety needs. That sentence explains the whole problem: you cannot reboot a ventilation controller on a Tuesday afternoon the way you would a web server.
We do not cite any specific mining incident here. The point is the mechanism.
How does a library flaw reach the physical world?
Machine software is assembled from parts. A fleet management system, a gas monitor gateway or an operator display might include open source libraries for networking, parsing or time keeping. A flaw in a parser can let crafted input crash the process. A crash in a monitoring service may mean a blind spot, and a flaw in a command path may mean a wrong value. Whether any of that is possible depends on the network path to the device, which is why segmentation matters as much as patching.
Which standards are worth reading?
- ISA/IEC 62443. A series for industrial automation and control systems. ISA lists ANSI/ISA 62443 4 1 on secure product development lifecycle requirements, 4 2 on technical security requirements for components, and ISA TR62443 2 3 on patch management in the IACS environment. Those three speak directly to vendors, components and patching.
- NIST SP 800-82 Rev. 3. Guidance on OT topologies, threats and countermeasures. NIST's page notes an initial public draft of Revision 4 is open for comment until 30 November 2026.
- CISA on SBOMs. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components, and calls it a key building block in software supply chain risk management. It also describes VEX, a security advisory form that says whether a product is affected by a known vulnerability.
What does a defender do about it?
Ask for the list of ingredients. Request an SBOM from each equipment and software supplier, then ask for a VEX statement when a new flaw appears, so you learn whether your product is affected without reverse engineering it. Match the components against vulnerability data, then ask the harder question: can that code be reached from any network the device sits on? A flaw in a service that only listens on an isolated segment sits lower on the list than one on a gateway bridging into the corporate network.
Some suppliers will not provide an SBOM. Record that as a risk and compensate with network isolation and monitoring.
What to do
- Inventory the connected equipment and software: make, model, firmware, network segment, supplier contact.
- Request SBOMs and VEX statements from suppliers, and put the request in procurement terms.
- Match components against known vulnerability data on a schedule.
- Map the network path to each affected device before ranking urgency.
- Agree patch windows with operations and safety staff, not just IT.
- For anything unpatchable, add isolation, allow lists and monitoring.
- Keep a record of each decision, including why you waited.
Quick check
Should every vulnerable library on a mine be patched at once?
No. Rank by reachability and safety impact, and patch inside windows agreed with operations. Isolate what cannot be patched.
What is a VEX statement?
A supplier statement saying whether a product is affected by a specific known vulnerability.
Sources
Last reviewed: 18 October 2026.
