An inspection drone is a flying computer made of other people's software: flight firmware, a ground control app, a mobile app and a cloud service. A flaw in a dependency there is not only a data risk. It can change what the aircraft does. Operators should inventory that software, question suppliers, and keep manual control available.
Where does the software sit?
Think of five layers, each with its own supply chain.
- Flight controller firmware. Code that stabilizes the aircraft and obeys commands. Updates are delivered by the vendor, sometimes over the air.
- Payload and sensor software. Cameras and other sensors with their own drivers.
- Ground control application. Runs on a laptop or tablet, plans missions and sends commands.
- Phone or tablet app and its libraries. Often built on open source components.
- Cloud services. Where flight logs, images and mission plans are stored and sometimes where updates come from.
This is an architecture sketch, not a description of any product. Real systems vary. The method is to ask your vendor which of these layers exist in the systems you operate.
How does a software flaw become a physical effect?
Consider the general pattern that NIST describes for operational technology: systems that interact with the physical environment, where performance, reliability and safety requirements shape what security measures are practical. A drone fits that definition. A vulnerable component in the ground control path could let someone alter a mission plan. A corrupted firmware update could affect how the aircraft behaves. A compromised cloud account could expose inspection images of critical sites, a confidentiality risk of its own.
The honest framing is that these are plausible chains to test for, not claims about specific events. This article does not describe any incident.
What do official sources say?
CISA and the FBI publish joint guidance on drone cybersecurity, titled Cybersecurity Guidance: Chinese-Manufactured UAS. The CISA page says it raises awareness of threats posed by those systems and offers recommendations to reduce risks to networks and sensitive information. Read the full PDF for its recommendations, which this article does not summarize. For the general software side, NIST SP 800-161 Revision 1 addresses risks from products and services that may contain malicious functionality or be vulnerable due to poor development practices, and NIST SP 800-218, the Secure Software Development Framework, gives a common vocabulary for what to ask a software producer.
What can an operator check?
Ask suppliers for a software bill of materials for each layer you operate, or for a written statement of how they track component vulnerabilities. Compare the SBOM against vulnerability data on a schedule. Reachability analysis tells you which flaws sit on code that is actually exposed in your configuration, such as a ground app that never opens a network port.
Also check procedure. How are firmware updates verified before a flight? Who signs off on a version change? Can you roll back? Are inspection images and logs encrypted, and who can access the cloud account?
Open the SCA dependency inventory demo
What stays physical?
Software controls do not replace flight safety practice. Keep a trained pilot able to take manual control, maintain fail-safe behaviors such as return-to-home settings reviewed by someone who understands them, and test updates away from critical infrastructure before flying near it. Safety and security reviews should happen together.
What to do
- List every software layer in your drone operation, from firmware to cloud.
- Ask each supplier for an SBOM or a written process for tracking component vulnerabilities.
- Review the CISA and FBI drone guidance with your operations lead.
- Verify and approve firmware and app updates before field use, with a rollback path.
- Restrict and log access to the cloud account holding images and plans.
- Compare component lists against vulnerability data on a schedule.
- Rehearse manual control and failure scenarios at least yearly.
Quick check
Is a drone vulnerability a safety issue or a cybersecurity issue?
Both. Drones interact with the physical world, so a software flaw can affect behavior as well as data. Review them together.
Do we need an SBOM for every drone?
None of the sources reviewed mandates one, but it makes questions about component flaws answerable. Ask your supplier what they can provide.
Sources
- CISA: Cybersecurity Guidance: Chinese-Manufactured UAS
- NIST SP 800-82 Revision 3
- NIST SP 800-161 Revision 1
- NIST SP 800-218: Secure Software Development Framework
Last reviewed: 18 October 2026.
