ArduPilot Repository Overview
for SBOM Scan Configuration

1Purpose and Intended Use of This Report

This document is not the SBOM itself. It is a pre-scan briefing: a map of what lives in the ArduPilot repository and what the SBOM tools provider needs to enable so the resulting SBOM is complete enough for an FDA premarket cyber device submission under Section 524B of the FD&C Act.

2Repository at a Glance

3Top-Level Directory Map

4Firmware Families and Build Targets

Each family is a separately built application registered in the root wscript. The submitted SBOM should name the family and vehicle configuration actually shipped on the device.

5Hardware Platforms, HAL and RTOS Mapping

The build target determines which RTOS, toolchain, and driver set enters the binary. The provider needs to know which platform family the medical device uses so reachability analysis can be scoped to that configuration.

The AP_HAL layer (libraries/AP_HAL) defines scheduler, threading, UART/SPI/I2C/CAN, GPIO, RC, storage, and timing interfaces. Board-specific feature selection matters: constrained boards compile out features, so two binaries from the same source tree can have different component inventories.

6Third-Party and Vendored Dependency Inventory

6.1 Declared Git submodules (from .gitmodules)

6.2 Vendored and copied source inside libraries/ (no manifest, needs fingerprinting)

• Lua 5.3.6 (customized) under libraries/AP_Scripting/lua, MIT upstream.
• ARM CMSIS material under AP_GyroFFT.
• Sagetech SDK fragments under AP_ADSB.
• Piccolo CAN protocol material under AP_PiccoloCAN.
• Protocol parsers, numerical code, and device SDK fragments spread across individual driver libraries.

7Scripting and Middleware Components

8Licensing Overview

The main work is GNU GPL version 3 (see COPYING.txt). Third-party components retain their own licenses; there is no repository-wide exception that converts all embedded third-party code to GPLv3.

9Scan Module Configuration Checklist for the Provider

Enable the following modules and data sources when configuring the toolchain for this repository:

10Potentially Safety-Critical Components to Flag

The following areas should be treated as safety-relevant in the SBOM report's criticality column and in SOUP evaluation:

Pill colors: red = flight-critical core, amber = input/output and command surface, green = evidence and diagnostics.

11FDA Submission Considerations

• Section 524B (cyber devices): the submission SBOM must cover the shipped firmware image, its build/toolchain provenance, and every third-party component in it, with plans and evidence for postmarket vulnerability monitoring against this inventory.
• Intended-use and traceability: the manufacturer remains responsible for intended-use analysis, requirements traceability, hazard controls, cybersecurity risk analysis, V&V, configuration control, and postmarket monitoring. An SBOM supports but does not replace these.
• Pin and freeze: record the ArduPilot release tag, submodule SHAs, toolchain version, board hwdef, and vehicle configuration that define the shipped binary. Regenerate all metrics from that exact revision.
• Companion software: ground stations, companion computers, and build/verification containers get their own SBOMs; do not infer them from this repository.
• Reproducible metrics commands for the pinned revision:

git submodule update --init --recursive
./waf list_boards | tr ' ' '\n' | sort -u | wc -l
find libraries/AP_HAL_ChibiOS/hwdef -name hwdef.dat | wc -l
cloc --exclude-dir=.git,build .

Report both "repository including submodules" and "first-party tree excluding submodules" component counts in the SBOM summary.