32.3: Aerospace and Defense Supply Chain Verification¶

When counterfeit electronic components were discovered in critical systems on military aircraft in 2011, investigators uncovered a shocking reality: suspected counterfeit parts had infiltrated the defense supply chain at alarming scale. A subsequent Senate investigation found over one million suspected counterfeit parts in the defense supply chain across 1,800 cases. The parts—often salvaged from electronic waste, remarked as new, and sold through layers of brokers—had reached flight-critical systems where failure could cost lives.

The aerospace and defense response to this crisis created some of the most rigorous supply chain verification frameworks in any industry. DO-178C establishes software assurance levels based on failure consequences. DFARS clauses mandate supply chain security for defense contractors. Counterfeit prevention programs require traceability to original manufacturers. These frameworks reflect an environment where failure isn't just expensive—it's potentially catastrophic. While civilian software rarely faces identical stakes, the principles of risk-proportionate verification, supplier qualification, and rigorous traceability offer models for high-assurance software in any context.

Counterfeit Parts Prevention¶

The counterfeit parts problem in aerospace and defense parallels supply chain attacks in software—unauthorized, potentially malicious components entering trusted supply chains through deceptive practices.

Counterfeit types:

Counterfeit electronic parts appear in various forms:

• Recycled parts: Used components removed from scrap, cleaned, and remarked as new
• Overproduced parts: Unauthorized production beyond contracted quantities
• Remarked parts: Legitimate parts relabeled as higher-grade versions
• Cloned parts: Copies of authentic parts without authorization
• Defective parts: Parts that failed testing, diverted instead of destroyed

Detection challenges:

Counterfeit detection is difficult because:

• Sophisticated counterfeits pass visual inspection
• Testing requires expensive equipment and expertise
• Supply chain length obscures origins
• Economic pressure encourages cutting corners

Prevention framework:

Industry and regulatory responses include:

SAE AS6171 - Test Methods: Standardized testing protocols for detecting counterfeit parts: - Visual inspection criteria - X-ray inspection requirements - Electrical testing specifications - Destructive testing procedures

SAE AS6496 - Fraudulent/Counterfeit Avoidance: Procurement practices reducing counterfeit risk: - Authorized source requirements - Broker qualification criteria - Documentation requirements - Traceability verification

GIDEP (Government-Industry Data Exchange Program): Information sharing system where: - Organizations report suspected counterfeits - Industry shares detection methods - Alerts warn of known counterfeit sources - Collective intelligence improves detection

Software parallels:

Software supply chain attacks mirror counterfeit parts:

• Typosquatting: Packages masquerading as legitimate ones (like remarked parts)
• Compromised packages: Legitimate packages modified maliciously (like recycled parts)
• Unauthorized copies: Unofficial distributions of software (like overproduced parts)
• Backdoored versions: Malicious modifications to legitimate software (like cloned parts)

Software countermeasures parallel hardware approaches:

• Verification against authoritative sources (like authorized distributors)
• Cryptographic verification (like testing methods)
• Information sharing about malicious packages (like GIDEP)
• Traceability to original publishers (like traceability requirements)

Supplier Qualification¶

Aerospace and defense supplier qualification involves rigorous assessment before and during supplier relationships.

Qualification elements:

Initial qualification: - Facility audits assessing capabilities and controls - Process validation ensuring consistent quality - Management system certification (AS9100 for aerospace) - Financial stability assessment - Security clearance verification where required

Ongoing qualification: - Regular surveillance audits - Performance monitoring and scorecards - Corrective action verification - Requalification after significant changes

Technical capability: - Design capability assessment - Manufacturing process validation - Testing capability verification - Configuration management evaluation

Tiered qualification:

Qualification intensity varies by supplier role:

• Critical suppliers: Most rigorous qualification, frequent audits
• Major suppliers: Full qualification, annual audits
• Standard suppliers: Basic qualification, periodic audits
• Commodity suppliers: Certification requirements, spot audits

Software adaptation:

Software supply chains could adopt similar qualification:

• Critical dependencies: Rigorous assessment of security practices, governance, maintenance commitment
• Major dependencies: Full evaluation using tools like Scorecard
• Standard dependencies: Basic verification of provenance and vulnerability status
• Commodity dependencies: Automated checking of basic criteria

Commercial software suppliers could undergo qualification similar to aerospace suppliers. Open source projects could be assessed against qualification criteria, with foundations or commercial supporters providing assurance.

DO-178C Software Assurance¶

DO-178C (Software Considerations in Airborne Systems and Equipment Certification) provides the framework for software assurance in civil aviation, with parallel standards in defense and other domains.

Design Assurance Levels:

DO-178C defines five Design Assurance Levels (DAL) based on failure consequences:

Verification requirements:

Higher DAL levels require more verification activities:

DAL A requirements include: - 100% structural coverage testing (MC/DC coverage) - Complete requirements traceability - Independence between development and verification - Formal methods encouraged - Extensive documentation

DAL D requirements include: - Basic functional testing - Requirements-based test cases - Standard development practices - Basic documentation

Costs scale accordingly:

• DAL A software can cost $100+ per line of code to develop
• DAL D software costs closer to commercial development
• Organizations carefully assign DAL levels to minimize cost while ensuring safety

Software supply chain implications:

DO-178C's criticality-based approach suggests models for civilian software:

• Criticality assessment: Evaluate consequences of component compromise
• Proportionate verification: Scale verification intensity to criticality
• Independence requirements: Separate development and verification for critical components
• Traceability: Document relationships between requirements, code, and tests

Most civilian software wouldn't warrant DAL A rigor, but critical infrastructure, medical devices, and financial systems might justify higher assurance levels.

DFARS Supply Chain Requirements¶

The Defense Federal Acquisition Regulation Supplement (DFARS) includes supply chain security requirements for defense contractors.

Key requirements:

DFARS 252.204-7012 - Safeguarding Covered Defense Information: - Implement NIST SP 800-171 security controls - Report cyber incidents within 72 hours - Preserve forensic evidence - Flow down requirements to subcontractors

DFARS 252.239-7018 - Supply Chain Risk: - Government may exclude suppliers posing unacceptable risk - Contractors must report supply chain concerns - Covers information and communications technology

DFARS 252.246-7007 - Contractor Counterfeit Electronic Part Detection: - Establish counterfeit prevention system - Use trusted suppliers - Report suspected counterfeits - Flow down requirements to subcontractors

CMMC (Cybersecurity Maturity Model Certification):

CMMC 2.0 adds third-party certification:

• Level 1: Basic cyber hygiene (15 requirements)
• Level 2: Advanced (110 requirements, aligned with NIST SP 800-171)
• Level 3: Expert (134 requirements for APT defense)

Contractors must achieve certification matching contract requirements. Third-party assessors verify compliance.

Flow-down requirements:

DFARS requirements cascade through supply chains:

• Prime contractors must flow requirements to subcontractors
• Subcontractors must flow to their suppliers
• Each tier is responsible for next tier's compliance
• Creates accountability through entire supply chain

Civilian software lessons:

DFARS provides model for civilian supply chain requirements:

• Baseline security standards: Common expectations (like NIST SP 800-171)
• Incident reporting: Mandatory notification of security events
• Third-party certification: Independent verification of compliance
• Flow-down: Requirements propagating through supply chains

EU CRA (effective December 2024) creates a similar framework for civilian software in Europe.

Verification Intensity by Criticality¶

A key aerospace and defense principle is scaling verification to criticality—investing most heavily where consequences are most severe.

Criticality determination:

Aerospace determines criticality through safety assessment:

1. Function identification: What does the component do?
2. Failure mode analysis: How could it fail?
3. Consequence assessment: What happens if it fails?
4. Probability estimation: How likely is failure?
5. Risk classification: What assurance level is required?

Verification scaling:

Higher criticality triggers:

• More rigorous testing requirements
• More documentation
• More independent review
• More formal methods
• Higher supplier qualification requirements

Lower criticality allows:

• Basic testing
• Standard documentation
• Normal review processes
• Standard practices
• Basic supplier qualification

Software application:

Software supply chains could apply similar principles:

Criticality factors: - Exposure: Is the component accessible to attackers? - Privilege: What access does the component have? - Impact: What could an attacker do through this component? - Prevalence: How widely is the component used? - Replaceability: How difficult is replacement?

Tiered response: - Critical components: Extensive security audit, source verification, reproducible builds - Important components: Security assessment, provenance verification - Standard components: Automated scanning, basic verification - Low-risk components: Standard practices

Most organizations apply uniform (usually minimal) verification regardless of criticality. Risk-proportionate approaches would focus resources where they matter most.

Traceability Requirements¶

Aerospace traceability enables understanding every component's origin and history.

Traceability elements:

Parts traceability: - Original manufacturer identification - Date codes and lot numbers - Complete chain of custody - Certification documentation

Configuration traceability: - Build documentation (what's in each assembly) - Version control for all components - Change history - As-built records

Requirements traceability: - Link between requirements and implementation - Test coverage documentation - Verification evidence

Traceability uses:

Traceability enables:

• Incident investigation: Determining root cause
• Recall execution: Identifying affected units
• Compliance demonstration: Proving requirements met
• Supply chain visibility: Understanding dependencies

Software parallels:

Software traceability through:

• SBOM: Software Bill of Materials documenting components
• Provenance attestations: Build origin documentation
• Commit history: Complete development record
• Dependency graphs: Understanding component relationships

Software has advantages (complete digital records possible) and disadvantages (complex transitive dependencies) compared to hardware traceability.

Lessons for Civilian Software¶

Aerospace and defense practices suggest several directions for civilian software.

Applicable principles:

1. Risk-proportionate assurance: Scale verification intensity to consequence severity

2. Supplier qualification: Assess capabilities and practices before depending on suppliers

3. Traceability requirements: Document component origins and changes

4. Flow-down mechanisms: Cascade requirements through supply chains

5. Information sharing: Exchange threat intelligence across industry

6. Independent verification: Separate development and security assessment for critical components

Adaptation considerations:

Aerospace practices require adaptation for civilian software:

• Cost: Full aerospace rigor is prohibitively expensive for most software
• Scale: Software has far more components than typical aerospace systems
• Pace: Software development cycles are faster than aerospace programs
• Open source: Aerospace typically uses contracted suppliers, not volunteer maintainers

Practical civilian application might include:

• Aerospace-level rigor for most critical infrastructure
• Scaled-down approaches for important systems
• Basic hygiene for general commercial software
• Risk assessment to determine appropriate level

Recommendations¶

We recommend adapting aerospace and defense lessons to software supply chains:

For high-assurance contexts:

1. Apply criticality assessment to software components
2. Scale verification to risk rather than uniform minimal checking
3. Require traceability for critical components
4. Implement supplier qualification for key dependencies
5. Consider independent verification for most critical components

For general software:

1. Learn from counterfeit prevention applying authorized source concepts
2. Adopt information sharing about malicious packages (like GIDEP)
3. Implement basic traceability through SBOM and provenance
4. Flow requirements through supply chains where possible
5. Assess criticality even if resources limit response

For policy makers:

1. Study aerospace regulation as model for critical software
2. Consider tiered requirements based on software criticality
3. Enable information sharing about supply chain threats
4. Require flow-down of security requirements
5. Support verification infrastructure for civilian software

Aerospace and defense developed rigorous supply chain security because failure costs lives. Civilian software increasingly faces similar stakes in critical infrastructure, medical devices, and essential services. The aerospace model—while requiring adaptation for software's unique characteristics—provides proven patterns for achieving high assurance when consequences demand it.