A vulnerable dependency inside inspection drone software matters on a shop floor when that software touches plant networks, safety systems or inspection records. The practical steps are to get a software bill of materials from the supplier, check each flagged component for reachability, and keep the drone's data path separated from control systems.
Why would a drone's software library matter to a plant?
Inspection drones are flying computers with an operating system, a flight stack, a camera pipeline, a companion app and a cloud or local sync service. All of that is built from open source and vendor code. A flaw in any library is a flaw in the product.
What turns a software flaw into a plant problem is the connection. Does the drone's ground station join the same network as production equipment? Does it import maps or mission files from a shared drive? Does its output feed maintenance decisions? Those questions decide the impact more than the severity score does.
This post describes no specific incident. It is a method for thinking about one.
Which standards frame the work?
Two published documents are worth knowing.
NIST SP 800-82 Rev. 3, published in September 2023, is a guide to operational technology security. It defines OT as programmable systems and devices that interact with or monitor the physical environment, and it covers topologies, common threats and vulnerabilities, and recommended countermeasures, while accounting for performance, reliability and safety needs.
ISA/IEC 62443 is a series of standards for industrial automation and control systems. It splits responsibility among asset owners, integrators, product suppliers and service providers. Part 4-1 sets secure product development lifecycle requirements, and part 2-3 addresses patch management in these environments. For you as an asset owner, part 2-1 covers the security program you run.
ISO 10218, the robot safety standard, is outside what this post fetched, so it is not discussed here.
How do you trace a vulnerable dependency?
Start with the ground station and companion software, since that is where a laptop or tablet meets your network. Ask the supplier for an SBOM that lists direct and transitive components with versions.
Then take each advisory and ask three things. Is the vulnerable component actually in the build you run? Is the vulnerable function reachable from how the product is used? Can an attacker reach the input, from a network, a file or a radio link?
Many alerts end at the second question. Reachability analysis exists for that reason: it separates a library that is present from a library whose risky code path can run.
What to do
- Inventory every drone, ground station and companion app, with software versions.
- Request an SBOM from each supplier, and ask how often they update it.
- Ask whether the supplier follows a secure development lifecycle such as the one in ISA/IEC 62443-4-1.
- Put ground stations on a segment that cannot reach controllers or safety systems.
- Treat imported mission files and firmware updates as untrusted until verified.
- Define who can approve an update, and how you roll back if inspection quality drops.
- Check new advisories against the SBOM, and record which ones are reachable.
- Keep a manual inspection fallback, so a security hold on the drone does not stop safety checks.
Quick check
Is every vulnerable library in drone software urgent?
No. Urgency depends on whether the component is in the build, whether the vulnerable code can run, and whether an attacker can reach its input.
Who is responsible for patching, the supplier or the plant?
Both. ISA/IEC 62443 describes shared responsibility among asset owners, integrators, product suppliers and service providers, with patch management addressed in part 2-3.
Sources
Last reviewed: 18 October 2026.
