In January 2011, RTCA and EUROCAE published DO-178C, replacing a 1992-era standard that had never anticipated software built from dozens of third-party libraries, commercial RTOS kernels, and outsourced code modules. Today, DO-178C software supply chain security is the single biggest gap in avionics certification: the standard rigorously verifies that code does what it's supposed to do, but says almost nothing about whether the components that make up that code came from a trustworthy, tamper-free source. A Level A flight control system can pass all 71 applicable objectives and still ship with an unpatched open-source library, an unverified compiler toolchain, or a subcontractor build environment nobody audited. Airlines and OEMs are discovering that certification and supply chain integrity are not the same problem, and treating them as one is how vulnerabilities make it onto aircraft that have been "fully certified" for years.
What does DO-178C software supply chain security actually require?
DO-178C itself requires very little supply chain security directly — it was written to assure software behavior, not provenance, and that gap is exactly what makes this topic urgent. The standard defines five Design Assurance Levels (DAL A through E) tied to failure condition severity, and it requires objective-based evidence: Level A software must satisfy all 71 objectives, 33 of which need independent verification, while Level D needs only 26 and Level E none. None of those objectives ask "where did this code come from" or "who touched the build pipeline before it reached us." Supplements like DO-330 (tool qualification) and DO-332 (object-oriented technology) added rigor for specific technical gaps, but the core standard still assumes a relatively closed development environment — an assumption that hasn't matched reality for at least a decade. Modern avionics suites routinely integrate software from 30 or more suppliers spanning multiple DALs, each with its own toolchain, each a potential entry point for a dependency that was never independently assessed for tampering or unpatched vulnerabilities, only for functional correctness.
How do airborne software assurance levels change what vendor risk means?
Airborne software assurance level assignment determines how much scrutiny a component gets, but it does nothing to verify the integrity of the supply chain that produced it. A DAL A component controlling primary flight surfaces gets exhaustive structural coverage analysis and independent verification; a DAL D cockpit display driver gets comparatively light review. The problem is that DAL classification is applied to functions, not to the full dependency graph underneath them. A Level A application can statically link a cryptographic library, a JSON parser, or a math kernel that was itself never developed to DAL A rigor — it was simply "included" and then verified functionally within the larger certified system. This is precisely the mechanism experts point to when they warn that DAL classification creates a false sense of security about supply chain provenance: the assurance level tells you how hard the top-level function was tested, not whether every artifact feeding into the build was authentic, unmodified, and traceable back to a known-good source.
Why do aerospace software vendor audits struggle to catch supply chain risk?
Aerospace software vendor audits struggle because they are built around document review and process compliance, not continuous verification of what actually ships. A typical Tier 1 prime like Boeing or Airbus runs supplier audits against DO-178C objectives and configuration management records, checking that a supplier followed the plans they said they'd follow (PSAC, SDP, SVP, SCMP) and produced the required artifacts. That process can take months per supplier and is usually annual or triggered by a design change — meaning a vulnerability introduced into a shared library in month two of an audit cycle can sit undetected until the next review, if it's caught at all. Audits also rely heavily on supplier self-attestation for third-party and open-source components, since DO-178C predates the software bill of materials concept entirely. When the FAA and EASA push for tighter airworthiness security review under DO-326A/ED-202A, they're implicitly acknowledging that the traditional audit model — a periodic paper-based check — was never designed to catch a compromised build server or a maliciously altered dependency between audit cycles.
What's changed since DO-178C was written in 2011, and why does it matter now?
What's changed is the scale and speed of software supply chain attacks, and DO-178C's underlying assumptions haven't kept pace. When DO-178C was finalized, "supply chain attack" wasn't yet a term threat modelers used routinely; the 2020 SolarWinds compromise, which affected roughly 18,000 organizations through a trojanized software update, hadn't happened, and neither had the CrowdStrike content-update failure on July 19, 2024, which grounded and delayed flights worldwide by knocking out airline operations systems — a vivid, non-hypothetical demonstration of how a single vendor's software update can cascade into aviation disruption at global scale. Neither incident involved DO-178C-certified flight software directly, but both illustrate the exact failure mode avionics programs are now racing to close: a trusted vendor pushes an update, and nobody downstream had the visibility to catch the problem before it reached production systems. In response, RTCA and EUROCAE working groups have been extending DO-326A/ED-202A-aligned security processes and exploring formal SBOM guidance for airborne software, and U.S. federal policy — from Executive Order 14028 to NDAA Section 224 SBOM mandates for defense software — is pushing aerospace suppliers toward the same provenance transparency that commercial software vendors have had to adopt since 2021.
Can a single unverified dependency undermine an aircraft already in certified service?
Yes — because DO-178C certification is a point-in-time judgment, not an ongoing guarantee, and most avionics software stays in service for 20 to 30 years without re-certification of its underlying dependencies. A component that was compliant at certification can still be running a cryptographic library, RTOS module, or third-party driver with a vulnerability disclosed years later, and there is no standard mechanism in DO-178C for continuously tracking which certified systems contain which version of which component. This is the practical consequence of avionics software certification focusing on functional and structural verification rather than component inventory: certifying authorities have excellent visibility into whether code meets its requirements, and very poor visibility into which of the thousands of build artifacts underneath that code originated from a compromised or unpatched source. For fleets that fly for three decades, that's not a theoretical gap — it's a multi-decade window in which a supply chain vulnerability can sit unaddressed simply because no process exists to re-examine it once the type certificate is issued.
How Safeguard Helps
Safeguard closes the gap between "certified" and "verified" by treating avionics software supply chains as something to be continuously monitored, not periodically audited. For programs pursuing DO-178C software supply chain security, Safeguard builds and maintains a live software bill of materials across every DAL-classified component and its dependencies — mapping which suppliers, libraries, toolchains, and build environments contributed to a given certified artifact, and flagging when a newly disclosed vulnerability lands inside something already flying. Rather than waiting for the next scheduled aerospace software vendor audit to surface a problem, Safeguard gives prime contractors and suppliers real-time visibility into provenance and integrity across the entire supplier tier, with evidence formatted to support DO-326A/ED-202A airworthiness security reviews alongside existing DO-178C objectives. The result is a supply chain security layer that runs continuously underneath certification — catching the compromised dependency, the unpatched library, or the unverified build step long before it becomes the kind of incident that grounds fleets or triggers an airworthiness directive, and giving certification teams the traceability that DO-178C alone was never designed to provide.