Ä¢¹½tv

How can the Autonomous Vehicle Cybersecurity Development Lifecycle help AV developers?

In 2022, 19-year-old David Colombo demonstrated that he could , accessing systems such as the stereo and headlights. Since then, other hackers have shown they can override speed controls, bypass keyless entry, and confuse autonomous vehicles with altered road signs. 

Hacking like this poses a direct safety threat to AV users and the public: robotaxis could be rerouted to cause urban disruption, sensitive data could be breached, or critical vehicle functions could be disabled remotely. As vehicles become more autonomous and connected, cybersecurity and safety are inseparable, becoming as fundamental to vehicle development as brakes or airbags. 

For automakers,  on attack methods, stricter regulatory demands, and recent AV program suspensions all show how quickly trust can erode when cybersecurity is neglected. To address this, the  offers a comprehensive, evidence-based framework created by security professionals to position cybersecurity as a native engineering discipline and embed auditable cybersecurity practices throughout the entire AV development process, from concept to decommissioning.

How are cybersecurity research and regulations evolving? 

Regulators are increasingly recognizing cybersecurity risks, scrutinizing how autonomous systems will defend against the growing number and modes of attacks. 

Autonomous systems are increasingly defined by their software, relying on sensors and learning models to interpret an uncertain world, with AVs epitomizing both the potential of advanced technologies and their vulnerabilities to bad actors. Attacks on LiDAR point clouds or camera pipelines can or , causing phantom braking or missed detection — hazards that are indistinguishable from hardware faults. Similarly, global navigation satellite system (GNSS) spoofing has long been a vulnerability in maritime and aviation, where attackers  to confuse or redirect vehicles. 

To manage these risks, , Europe's  regulations, and ISO/SAE 21434 treat cybersecurity as a prerequisite, not just a best practice. Gaining market access now depends on auditable cybersecurity engineering throughout the vehicle lifecycle. Cybersecurity is also fundamental to the overarching goal of an AV safety case, because any successful cyberattack or cybersecurity failure can directly affect sensing, decision-making, or control functions, turning compromised software into a physical safety hazard.

To credibly claim that an AV is "safe," vehicle developers must demonstrate that critical systems are protected against cyber threats across their lifecycle, including design, development, deployment, updates, and decommissioning. This means cybersecurity is no longer a box to check — it is part of the connective tissue of every AV safety case and the foundation of trustworthy autonomy.

What challenges face safety‑critical AV programs?

As AVs continue to develop, industry is encountering an expanding attack surface across perception, connectivity, and cloud operations. For hackers, the proliferation of systems offers new territory to probe for opportunities.

• Adversarial sensing and machine learning robustness: Even small perturbations to input data can produce unsafe behaviors. Testing methods for these pathways remain immature.
• Operational governance and recalls: When vulnerabilities demand over‑the‑air (OTA) patches, companies must balance fast response with validated safety — the "patch velocity versus certification" dilemma.
• Regulatory heterogeneity: Global vehicle markets now face divergent cybersecurity requirements that must be reconciled in one engineering pipeline.
• Supplier complexity: Cyber obligations propagate across OEMs, Tier‑1s, and software vendors. Absent formal agreements, accountability disappears.

How does the AVCDL address AV cybersecurity challenges? 

The AVCDL is a structured process model that details cybersecurity activities, work products, and their mappings to ISO/SAE 21434, ISO 24089 (software update engineering), and UNECE R155/R156. This detailed framework can help AV developers build security into their projects and manage cybersecurity throughout the life of the product instead of adding it on after development work is complete. By aligning evidence with regulatory expectations, it replaces paper safety with verifiable integration.

Imagine an AV program with good security design: strong encryption, well-segmented networks, secure boot, and extensive code reviews. Three years after launch, however, a widely used third-party library in the vehicle's connectivity stack is found to have a remotely exploitable vulnerability, and the operations team has also added a remote diagnostic interface in the field without the same rigor as the original design. Because there's no mature lifecycle process for continuous monitoring, patch management, change control, or secure decommissioning, thousands of vehicles are exposed, attackers find the new diagnostic interface, and a purely "post-design" change becomes a path to influence vehicle motion control.

That scenario marks a critical difference between standard development and one that is informed by a framework like the AVCDL: if teams only "build in" cybersecurity during design and implementation, they are at best only secure for a moment in time. Treating cybersecurity as a full-lifecycle discipline (covering supplier changes, updates, incident response, configuration drift, and retirement) keeps the safety case valid as the system, ecosystem, and threat landscape all evolve.

A defining feature of the AVCDL is the use of cybersecurity interface agreements (CIAs) between OEMs, suppliers, and toolchains. CIAs enumerate measurable obligations — software bills of materials, vulnerability response service level agreements (SLAs), update signing, and attestation logs — making every interface testable and auditable. The AVCDL lifecycle forces every security activity to leave some form of evidence. 

This approach turns abstract principles into concrete proof. Each artifact — threat models, safety‑security co‑analyses, telemetry retention plans, etc. — binds decisions to evidence across the lifecycle. Security engineering becomes as traceable and certifiable as functional safety itself.

• The AVCDL begins with concept and hazard analysis. From the first concept review, safety and security teams must co‑engineer risk models. A joint hazard and threat analysis (HARA + TARA) identifies failures initiated by cyber means — spoofed sensors, corrupted updates, falsified telemetry, etc. — and quantifies their safety impact. The resulting artifact, the "Threat Model and Security Goals," links directly to safety goals in the AVCDL traceability matrix.
• Next, the AVCDL recommends designing the vehicle so that critical systems are separated and only get the access they really need. Security hardware and processes — like special chips that verify the software, secure boot so only trusted code can run, and careful key management — are treated as safety features because they stop unauthorized software from taking over. Sensors can be checked against each other and monitored for unusual behavior so spoofing or jamming can be detected. Strong AV design can also spell out how the vehicle will "fail safely," such as shrinking its operating conditions or moving to a minimal risk maneuver/stop if something goes wrong. The outputs of this work include a security architecture and combined safety-security plan that aligns with ISO 21434 and current NHTSA guidance.
• During implementation and integration, secure‑development lifecycle controls mirror . Continuous integration pipelines are hardened; dependencies are enumerated in signed software bills of materials (SBOMs) so that when a flaw is identified, recall campaigns can be more precise. For ML components, the discipline extends to datasets and models: lineage tracking, version control, adversarial robustness testing, and red‑teaming perception stacks. Emerging SSDF‑AI practices provide structure. Artifacts include the Secure‑Development Plan, SBOMs, and a model card and threat‑robustness report.
• Security testing becomes safety evidence during the next phase of verification and validation (V&V). Penetration tests of in‑vehicle networks, simulated sensor spoofing, and failed‑safe rehearsals verify that cyber events trigger defined safety responses. OTA pipelines are subjected to attestation and rollback tests. Evidence is consolidated in a V&V report explicitly tracing cybersecurity test results to previously identified safety hazards. The results of this report can then be used to help remediate those hazards.
• Once the AV is operating outside test environments (AKA "in the wild"), software updates still pose serious cybersecurity risks. The AVCDL process complies with UNECE R155/R156 and ISO 24089 and requires operational cybersecurity and software‑update management systems (CSMS and SUMS). These govern keys, patch orchestration, and fleet‑wide threat monitoring. Telemetry retention — covering model versions and sensor frames around incidents — underpins both forensics and regulatory reporting. Operational artifacts include CSMS/SUMS audit packets and update‑attestation logs.
• Even when an AV has been decommissioned, cybersecurity risks remain. The AVCDL closes the loop with end‑of‑life security: key revocation, data sanitization, and a verified OTA shutdown to prevent orphaned assets from becoming entry points. A formal decommissioning plan ensures security persists beyond vehicle or asset life.

What should AV leaders do next?

Executives guiding AV or other safety‑critical transportation programs can adopt the AVCDL and weave cybersecurity into their programs not only from start to finish but as a guiding principle of ongoing development, updates, and future product generations. These steps can help position organizations to demonstrate, not merely declare, safety through cybersecurity.

1. Make the lifecycle auditable 
   Adopt AVCDL or an equivalent framework that binds artifacts to decisions and maps them to global standards (21434, 24089, R155/156). Negotiate supplier CIAs with measurable deliverables — SBOM cadence, vulnerability SLAs, and update attestation proofs.
2. Harden perception and positioning (PNT)
   Conduct adversarial‑robustness testing and sensor‑fusion redundancy. Integrate anti‑spoof techniques and inertial backups to maintain integrity when GNSS is unreliable.
3. Institutionalize OTA and incident response. 
   Run your cybersecurity and software-update programs with the same rigor you'd expect in aviation. Carefully control who can sign and send updates, roll changes out in stages, watch the fleet closely for problems, and follow clear, pre-agreed playbooks when something goes wrong. Track mean time to detect, patch, and validate safety impact.
4. Secure the AI supply chain.
   Expand SSDF practices to datasets and models — signing, lineage, evaluation for safety‑critical behaviors. Align assurance expectations with FDA‑style precedents for medical devices. 

In safety‑critical systems, cybersecurity failures are safety failures. The path forward demands lifecycle‑grade engineering, not afterthought defenses. Leaders need artifacts, metrics, and frameworks that stand up to regulators, auditors, and the court of public trust. The AVCDL offers a pragmatic bridge between engineering reality and regulatory proof, as well as a framework for building a "cybersecurity mindset" — awareness and prioritization of cybersecurity as a continuous consideration that is part of the full AV lifecycle, helping autonomy, and the people it serves, move safely through both physical and digital worlds.