32.2: Automotive Supply Chain Security¶

A modern vehicle contains more lines of code than a fighter jet—over 100 million in premium models, compared to roughly 8 million in an F-35—running on 70 to 150 electronic control units communicating across multiple networks. When Jeep Cherokees were remotely hacked in 2015, researchers demonstrated they could control steering and brakes through the entertainment system, forcing Chrysler to recall 1.4 million vehicles. The incident marked a turning point: automobiles had become software-defined products, and automotive supply chain security had to encompass code as much as steel.

The automotive industry's response to this transformation offers valuable lessons for software supply chains. With over a century of experience managing complex physical supply chains, automotive manufacturers have developed sophisticated systems for supplier management, quality assurance, and accountability that predate software concerns but increasingly incorporate them. Standards like IATF 16949, ASPICE, and the newer UN R155/R156 cybersecurity regulations create frameworks that the software industry lacks. The automotive model of tiered supplier management—where OEMs manage direct suppliers who in turn manage their suppliers—provides a pattern for scaling supply chain security that software's flat dependency model hasn't yet developed.

As vehicles become rolling computers, automotive and software supply chains converge. The lessons flow both directions: automotive learns software security practices while software can learn automotive's supplier management, quality systems, and accountability mechanisms.

Tiered Supplier Management¶

The automotive industry organizes suppliers into tiers based on their relationship to the original equipment manufacturer (OEM)—the company that assembles and sells the final vehicle.

Tier structure:

Tier 1: Direct suppliers to OEMs, providing major systems (engines, transmissions, electronics modules)
Tier 2: Suppliers to Tier 1 companies, providing sub-components
Tier 3: Suppliers to Tier 2, providing raw materials and basic parts
Further tiers: Additional levels for basic commodities

Management responsibilities:

Each tier manages the next:

OEMs manage Tier 1 suppliers through direct contracts, audits, and requirements
Tier 1 manages Tier 2 suppliers, flowing down OEM requirements
Tier 2 manages Tier 3, continuing requirement flow-down

This cascading model enables OEMs to manage complex supply chains without direct relationships with thousands of suppliers. Requirements, quality standards, and security expectations propagate through contractual relationships at each tier.

Visibility and accountability:

The tiered model creates structured accountability:

Each company is responsible for its direct suppliers
Problems are escalated through the tier structure
OEMs have visibility into lower tiers through Tier 1 reporting
Audit rights typically extend to sub-suppliers

Software contrast:

Software supply chains lack equivalent structure:

Flat dependencies: Applications directly depend on hundreds of packages without intermediate management
No contractual relationships: Open source dependencies typically have no contractual terms
No flow-down: Security requirements don't cascade through dependency trees
Limited visibility: Organizations often don't know their transitive dependencies

The automotive tier model suggests software might benefit from structured intermediaries—entities that take responsibility for managing and vouching for clusters of dependencies. Commercial support vendors (like Red Hat for Linux ecosystem or Tidelift for open source) partially fill this role.

Quality Systems: IATF 16949 and ASPICE¶

Automotive quality systems provide comprehensive frameworks for ensuring supplier quality, including aspects relevant to security.

IATF 16949:

IATF 16949 is the automotive quality management standard, building on ISO 9001 with automotive-specific requirements:

Product safety: Requirements for safety-related products
Supplier management: Systematic supplier development and monitoring
Problem solving: Structured approaches to defect prevention and correction
Traceability: Requirements for production part traceability
Change management: Controls on product and process changes

IATF 16949 certification is effectively mandatory for automotive suppliers—OEMs won't work with uncertified companies. This creates universal baseline quality regardless of specific OEM relationships.

ASPICE (Automotive SPICE):

Automotive SPICE provides a process assessment model for software development, based on the ISO/IEC 330xx series of standards (formerly ISO/IEC 15504):

Process areas include: - Software requirements analysis - Software architectural design - Software detailed design and unit construction - Software integration and integration testing - Software qualification testing - Software configuration management - Software problem resolution management

Capability levels: - Level 0: Incomplete process - Level 1: Performed process - Level 2: Managed process - Level 3: Established process - Level 4: Predictable process - Level 5: Optimizing process

OEMs typically require suppliers to achieve ASPICE Level 2 or 3 for software components. Assessments verify not just that good practices exist, but that they're consistently followed.

Security integration:

These quality systems increasingly incorporate security:

ISO/SAE 21434 provides cybersecurity engineering standard for road vehicles
ASPICE assessments include security-relevant processes
IATF 16949 problem-solving applies to security vulnerabilities
Quality systems provide infrastructure for security management

Software lessons:

Software supply chains lack equivalent quality frameworks:

No universal quality certification for open source projects
No mandatory process assessment for package publishers
Quality varies enormously across the ecosystem
No structured supplier development

OpenSSF Scorecard and Best Practices Badge provide partial equivalents, but adoption is voluntary and coverage incomplete. A more structured quality framework for critical software infrastructure might draw on automotive models.

Recall Mechanisms and Accountability¶

When automotive products fail, the recall system provides structured response and accountability.

Recall mechanics:

Regulatory framework: - National Highway Traffic Safety Administration (NHTSA) in the U.S. oversees recalls - Manufacturers must report defects affecting safety - Recalls require notification to all known owners - Remedies must be provided at no cost to consumers

Accountability structure: - OEMs are primarily responsible to regulators and consumers - OEMs may recover costs from responsible suppliers - Liability flows through contractual relationships - Ultimate accountability rests with the entity selling to consumers

Cost allocation:

Recall costs are substantial and create strong incentives:

Average recall costs $500+ per vehicle
Major recalls can cost billions
Supplier contracts typically include warranty and recall provisions
Financial exposure drives quality investment

Software contrast:

Software lacks equivalent recall mechanisms:

No mandatory vulnerability notification to users
No regulatory oversight of security defect remediation
No structured cost allocation for security failures
Limited accountability for downstream impacts

The EU CRA begins to create software recall equivalents through mandatory security update requirements and incident reporting. This represents movement toward automotive-style accountability.

Recall as pattern:

The recall model suggests patterns for software:

Mandatory notification: Users should be notified of security issues affecting them
Remedy provision: Fixes should be provided without additional cost
Regulatory oversight: Government role in ensuring adequate response
Cost internalization: Those responsible should bear remediation costs

Software-Defined Vehicles¶

Modern vehicles are fundamentally software products, creating convergence between automotive and software supply chain challenges.

Scale of software:

Contemporary vehicles contain:

100+ million lines of code in premium vehicles
100+ electronic control units (ECUs)
Multiple network buses connecting systems
Over-the-air update capabilities
Connected services requiring ongoing software support

Supply chain complexity:

Vehicle software comes from diverse sources:

OEM-developed software
Tier 1 supplier software
Commercial software (operating systems, middleware)
Open source components
Third-party applications

Managing security across this diverse supply chain requires approaches borrowing from both automotive and software security traditions.

Emerging challenges:

Software-defined vehicles create new challenges:

Lifecycle mismatch: Vehicles last 15+ years; software support periods are shorter
Update complexity: OTA updates must work across vehicle variants and ages
Integration testing: Software from multiple suppliers must work together
Security boundaries: Connected features create attack surfaces
Liability questions: Who's responsible when software fails?

UN R155 and R156 Requirements¶

United Nations regulations R155 (Cybersecurity) and R156 (Software Updates) establish mandatory requirements for vehicles sold in adopting countries, including the EU, UK, Japan, and South Korea. R155/R156 became mandatory for new vehicle types in the EU in July 2022, with full applicability to all new vehicles from July 2024.

UN R155 - Cybersecurity Management System:

R155 requires manufacturers to implement a Cybersecurity Management System (CSMS) covering:

Risk assessment processes
Security by design
Threat detection and response
Security testing
Supply chain security

Supply chain requirements specifically include: - Managing cybersecurity risks related to suppliers - Ensuring suppliers have appropriate cybersecurity capabilities - Maintaining visibility into supplier security practices - Flowing cybersecurity requirements to suppliers

UN R156 - Software Update Management System:

R156 requires a Software Update Management System (SUMS) covering:

Software identification (unique identifiers for software versions)
Software version tracking across vehicle fleet
Update integrity protection
Update failure handling
Update documentation and record-keeping

Compliance implications:

Without R155/R156 compliance, vehicles cannot be sold in adopting markets:

Type approval requires CSMS and SUMS certification
Audits verify implementation
Non-compliance blocks market access
Requirements apply to entire supply chain

Lessons for software:

R155/R156 provide regulatory model:

Mandatory security management: Not optional best practice
Supply chain scope: Requirements extend to suppliers
Update management: Systematic approach to software maintenance
Accountability: Clear responsibility with market access consequences

EU CRA represents similar approach for software generally—mandatory requirements with market access implications.

OEM-Supplier Security Requirements¶

OEMs increasingly impose specific security requirements on suppliers through contracts and specifications.

Typical requirements:

Development process: - Security development lifecycle (SDL) implementation - Threat modeling for supplied components - Security testing including penetration testing - Secure coding practices - Security training for developers

Supply chain security: - SBOM provision for software components - Open source component disclosure - Vulnerability monitoring and notification - Patch management processes - Sub-supplier security requirements

Incident response: - Vulnerability disclosure to OEM - Response time commitments - Coordination on remediation - Support for OEM incident response

Product security: - Secure boot and code signing - Cryptographic key management - Secure communications - Authentication and access control - Secure update mechanisms

Enforcement mechanisms:

OEMs enforce requirements through:

Contractual obligations: Security requirements in supplier agreements
Audits: Regular and for-cause security assessments
Testing: Security testing of delivered components
Scorecards: Supplier ratings including security performance
Business consequences: Security failures affect future business

Software adaptation:

Similar mechanisms could apply to software:

Contractual requirements: Organizations could impose security requirements on key dependencies
Commercial support: Support vendors could provide contractual assurances
Audits: Security audits of critical projects
Ratings: Scorecard and similar assessments
Funding consequences: Funding tied to security practices

Lessons for Software Supply Chains¶

The automotive model suggests several directions for software supply chain security.

Structured supplier management:

Tiered relationships: Some entities taking responsibility for managing clusters of dependencies
Requirements flow-down: Security requirements cascading through supply chains
Contractual accountability: Clear responsibility through agreements
Audit rights: Ability to verify supplier practices

Quality frameworks:

Universal standards: Common quality expectations across the ecosystem
Certification: Verification of practice implementation
Process assessment: Evaluation of how software is developed, not just what it does
Continuous improvement: Structured development of supplier capabilities

Accountability mechanisms:

Clear responsibility: Known entity accountable for each component
Recall equivalents: Mandatory notification and remedy for security issues
Cost allocation: Financial consequences for security failures
Regulatory oversight: Government role in ensuring adequate security

Lifecycle management:

Long-term support: Commitment to maintain software over extended periods
Update management: Systematic approach to deploying fixes
Version tracking: Knowledge of what software is deployed where
End-of-life planning: Clear communication about support cessation

Recommendations¶

We recommend adapting automotive supply chain lessons to software:

For the software industry:

Develop tiered models where entities take responsibility for managing dependency clusters
Create quality frameworks establishing universal expectations for critical software
Build accountability structures with clear responsibility for components
Implement lifecycle management with long-term support commitments for critical infrastructure

For organizations:

Apply automotive supplier management concepts to critical software dependencies
Require security commitments in agreements with commercial software suppliers
Assess suppliers systematically using structured evaluation approaches
Plan for long lifecycles especially for embedded and infrastructure software

For policy makers:

Study automotive regulation (R155/R156) as model for software requirements
Consider mandatory security management systems for critical software producers
Require update management capabilities for software in regulated contexts
Create accountability frameworks establishing clear responsibility

For automotive industry:

Extend traditional practices to software suppliers and open source components
Integrate software security into existing quality frameworks
Develop supplier capability in software security practices
Share lessons with broader software industry

The automotive industry didn't develop sophisticated supply chain security overnight—it evolved over decades through regulation, liability exposure, and market pressure. Software supply chains are earlier in this evolution, but automotive experience provides patterns that can accelerate maturation. As vehicles become software and software becomes critical infrastructure, the industries have much to learn from each other.