Contextualizing Security and Privacy of Software-Defined Vehicles: A Literature Review and Industry Perspectives

This paper presents a systematic literature review and industry survey to analyze Software-Defined Vehicle (SDV) security and privacy, resulting in a comprehensive security framework that addresses mixed-criticality challenges, layered defenses, and the harmonization of in-vehicle and cloud-based protections for Intelligent Transportation Systems.

The Gist

Imagine your car is no longer just a machine made of metal, gears, and wires. Instead, think of it as a giant, rolling smartphone on wheels. This is the concept of a Software-Defined Vehicle (SDV).

In the old days, if you wanted your car to go faster or have better brakes, you had to buy a new car or get a mechanic to swap out physical parts. Today, with SDVs, the car's "brain" is software. You can upgrade your car's features, fix bugs, or even unlock new capabilities (like better acceleration or a fancy new dashboard) just by downloading an update, much like updating an app on your phone.

However, just like your phone, if your car is connected to the internet and full of software, it can be hacked. This paper is a massive investigation into how to keep these "smart cars" safe and private.

Here is the breakdown of their findings, explained with simple analogies:

1. The Big Shift: From Hardware to Software

Think of traditional cars as Lego sets where every piece is glued together. If you want to change the shape, you have to break it apart and rebuild it.
SDVs are like LEGO sets with a magic remote control. The physical bricks (hardware) stay the same, but the remote (software) tells them how to behave. You can change the car's personality, features, or even its driving style just by pressing a button in the cloud.

The Problem: Because the car is now mostly software, hackers don't need to break into your garage to steal it; they just need to break into the code.

2. The New Weak Spots (Attack Surfaces)

The researchers found that because cars are now so connected, there are many new ways for bad guys to get in. They identified six main "doors" that need locking:

• The API (The Front Door): APIs are like the doormen that let different apps talk to the car. If the doorman is asleep or confused, a hacker can walk right in.
  • Analogy: Imagine a hotel where the front desk lets anyone in if they say the right password, but the password is written on the door.
• Third-Party Apps (The Guest List): Cars now run apps from outside companies (like Spotify or navigation). If those apps are buggy or malicious, they bring viruses into the car.
  • Analogy: It's like inviting a stranger into your house to fix the Wi-Fi, but they accidentally leave the back door unlocked.
• The Supply Chain (The Ingredients): A car is built from parts made by hundreds of different companies. If one supplier puts a "poison pill" in a chip or a piece of code, the whole car is compromised.
  • Analogy: Imagine a pizza chain where the flour, cheese, and sauce come from different farms. If one farm puts a rock in the flour, the whole pizza is ruined.
• Mixed Criticality (The Traffic Jam): In an SDV, the software that controls the brakes (life-or-death) and the software that plays music (fun but not dangerous) run on the same computer. If the music app crashes, it shouldn't stop the brakes from working.
  • Analogy: It's like having a chef and a clown working in the same kitchen. If the clown trips and knocks over a pot, the chef shouldn't drop the steak on the floor.
• OTA Updates (The Mailman): Over-the-Air (OTA) updates let the car download new software remotely. If a hacker intercepts the mailman, they can send a "fake update" that turns the car into a zombie.
  • Analogy: Imagine your bank sending you a new debit card. If a thief intercepts the mail and swaps it with a fake one, they can drain your account.
• Data Privacy (The Diary): These cars collect everything: where you drive, how fast you brake, and even who you are.
  • Analogy: Your car is keeping a detailed diary of your life. If someone steals that diary, they know your habits, your home, and your secrets.

3. Who Are the Bad Guys?

The paper looked at who might want to hack these cars. It's not just random teenagers anymore.

• Criminals: Want to steal the car or hold it for ransom.
• Nation-States: Might want to disable a fleet of cars during a conflict.
• Competitors: Might want to steal trade secrets.
• The "Script Kiddies": Amateur hackers who just want to cause chaos.

4. How Do We Fix It? (The Shield)

The researchers suggest a "Layered Defense" strategy. You can't just lock the front door; you need a fence, a guard dog, and an alarm system.

• Secure Coding: Write the code so it's hard to break, like building a fortress with no weak bricks.
• The "Software Bill of Materials" (SBOM): A full list of every ingredient in the car's software, so if a bad ingredient is found, you know exactly where to look.
• Encryption: Scramble the data so even if hackers steal it, they can't read it. It's like sending a letter in a code only the recipient can crack.
• Anonymization: Remove your name from the data. Instead of "John Doe drove to the park," the data just says "A car drove to the park."
• Testing: Constantly try to break the car's software before the bad guys do.

5. The Big Takeaway

The paper concludes that we are in a transition period. We are moving from cars that are "hardware" to cars that are "software." This is amazing because it means cars can get better over time, but it also means security is no longer an afterthought; it must be built into the car from day one.

The Golden Rule: Just as you wouldn't leave your house key under the doormat, we can't leave our cars' software unguarded. We need a mix of strong technology, strict laws, and smart companies to ensure that our future "smart cars" stay safe, private, and under our control.

In short: The future of driving is exciting and customizable, but it requires us to treat our cars like the complex, connected computers they have become, protecting them with the same care we use for our bank accounts and personal data.

Technical Summary

1. Problem Statement

The automotive industry is undergoing a paradigm shift from hardware-centric vehicles to Software-Defined Vehicles (SDVs), where functionality is controlled by software rather than fixed hardware. While this enables flexibility, continuous updates, and new business models (e.g., subscriptions), it significantly expands the attack surface and introduces complex security and privacy challenges.

Key problems identified include:

• Lack of Consensus: There is no unified definition of SDVs, and existing literature often conflates them with Connected Vehicles (CVs) or Autonomous Vehicles (AVs).
• Emerging Threats: The shift to software-centric architectures introduces new vulnerabilities, including insecure APIs, third-party library risks, supply chain compromises, and mixed-criticality interference (where low-criticality software affects safety-critical functions).
• Regulatory Gaps: While standards like ISO/SAE 21434 and UNECE R155/156 exist, their application to dynamic, software-updatable SDV architectures remains an open challenge.
• Privacy Concerns: SDVs generate massive amounts of sensitive data (location, behavior, biometrics), raising risks of re-identification, profiling, and unauthorized data sharing, often exacerbated by opaque consent mechanisms.

2. Methodology

The authors employed a mixed-methods approach combining a systematic literature review with industry expert elicitation to address four Research Questions (RQs).

• Systematic Literature Review (SLR):

  • Process: Adapted the SALSA (Search, Appraisal, Synthesis, Analysis) method.
  • Sources: Primary databases (IEEE Xplore, ACM, ScienceDirect, Springer) and secondary sources (Google Scholar, ResearchGate).
  • Filtering: Used specific queries ("software defined vehicle") and inclusion/exclusion criteria (peer-reviewed, English, post-2004). A snowballing technique (backward/forward reference chasing) was used to expand the dataset.
  • Outcome: A curated set of articles categorized by RQs (Attack Surfaces, Mitigations, OTA, Privacy).

• Expert Elicitation:

  • Participants: 11 industry experts (50% response rate) from OEMs, Tier 1/2/3 suppliers, and cybersecurity stakeholders.
  • Instrument: A structured questionnaire with 65 items using Likert scales and open-ended questions.
  • Analysis: Descriptive statistics (median, Interquartile Range) and Top-Two-Box Agreement (TTBA) were used to measure consensus on threat relevance and mitigation priority.

3. Key Contributions

A. Conceptual Clarification

The paper provides a refined definition of SDVs, distinguishing them from CVs and AVs:

• SDV: A vehicle where hardware is abstracted, and functionality is managed via software with continuous OTA updates as a core requirement.
• Differentiation: Unlike AVs (focused on automation levels) or CVs (focused on connectivity), SDVs focus on the software-centric lifecycle, enabling dynamic feature activation/deactivation and business model innovation.

B. Attack Surface Taxonomy (RQ1)

The authors identified and categorized six primary attack surfaces specific to SDVs (S1–S6), alongside legacy surfaces (S0):

1. S1 - Insecure APIs: Vulnerabilities in backend and in-vehicle APIs allowing authentication bypass and data exfiltration.
2. S2 - Third-Party Apps/Libraries: Risks from unvetted external code, malicious injection, and compromised updates.
3. S3 - Supply Chain Security: Integrity risks in hardware manufacturing, firmware signing, and distribution pipelines.
4. S4 - Mixed Criticality: Risks where non-safety services interfere with safety-critical functions due to shared resources in Service-Oriented Architectures (SOA).
5. S5 - OTA Updates: Vulnerabilities in the update channel allowing malicious firmware injection, rollback attacks, or unauthorized modifications.
6. S6 - Data Privacy: Risks related to the collection, storage, and inference of Personally Identifiable Information (PII) and driver behavior.

C. Mitigation Framework (RQ2)

The paper proposes a comprehensive security framework mapping threats to 10 mitigation strategies (M1–M10) and aligning them with the NIST Cybersecurity Framework 2.0 (Identify, Protect, Detect, Respond, Recover, Govern):

• Prevention/Protection: Secure Software Development Life Cycle (SVSE), Software Composition Analysis (SCA), Automotive Ethernet security (Firewalls, VLANs, TLS), and Data Anonymization.
• Detection: Intrusion Detection/Prevention Systems (IDPS), including AI-based IDS for in-vehicle networks.
• Resilience/Recovery: Security-aware task orchestration (dynamic resource reallocation), Fail-safe mechanisms, and robust OTA defenses (secure boot, digital signatures).
• Governance: Trustworthiness scores, insurance models, and regulatory compliance (GDPR, ISO/SAE 21434).

D. Critical Challenges Analysis (RQ3 & RQ4)

• OTA Security (RQ3): Experts emphasize that while cloud-based architectures are common, PKI-based mechanisms and edge-based approaches are critical for resilience. Key requirements include data integrity, authentication, and fail-safe mechanisms to prevent rollback attacks.
• Privacy (RQ4): The paper highlights that current consent models are insufficient for the dynamic nature of SDVs. It advocates for Data Minimization, Sanitization (removing PII before sharing), and Differential Privacy to balance data utility with user privacy.

4. Key Results & Findings

• Expert Consensus:

  • Highest Risk: Insecure APIs (S1) and Third-Party Software (S2) were rated as the most critical emerging threats.
  • Critical Mitigations: Secure Software Development Life Cycle (SVSE) and Gateway Firewalls were rated as highly critical.
  • Attacker Profiles: Criminals and Nation-States are perceived as the most significant threats; Activists are seen as less relevant.
  • Privacy vs. Security: While security is prioritized, experts agree that privacy (specifically user consent and data sanitization) is a fundamental requirement for trust.

• Framework Gaps: The analysis reveals a structural gap in current research: while "Identify," "Protect," and "Govern" functions are well-covered, mechanisms for "Respond" and "Recover" (post-incident handling and resilience) are under-researched in the context of SDVs.

• Supply Chain Complexity: The reliance on a multi-tier supply chain (OEMs, Tier 1-3) creates significant trust violations, necessitating end-to-end verification (e.g., SBOMs, UPTANE).

5. Significance and Impact

• Roadmap for Industry: The paper offers a practical roadmap for OEMs and suppliers to transition from hardware-centric security to software-centric security, addressing the specific needs of ISO/SAE 21434 and UNECE R155 compliance.
• Holistic View: By integrating academic literature with industry practitioner feedback, the paper bridges the gap between theoretical security models and real-world implementation challenges.
• Future Directions: It identifies critical areas for future research, including:
  • AI-driven adaptive intrusion detection.
  • Decentralized and edge-assisted OTA update mechanisms.
  • Standardization of APIs to reduce misconfigurations.
  • Governance of AI/LLM integration in vehicle security.

In conclusion, this work establishes that securing SDVs requires a multi-layered, lifecycle-oriented approach that harmonizes in-vehicle defenses with cloud-based strategies, prioritizes supply chain integrity, and embeds privacy-by-design principles to ensure the safety and trustworthiness of next-generation intelligent transportation systems.