Vulnerability Management Lifecycle for Connected Vehicles

A single connected vehicle can contain over 100 million lines of code distributed across 70 to 150 electronic control units, running software from dozens of Tier-1 and Tier-2 suppliers. Every component — from the infotainment operating system and the telematics connectivity stack to the AUTOSAR basic software and the Ethernet switch firmware — carries potential vulnerabilities. In 2025 alone, over 400 CVEs were published that directly affected automotive software components, and that number represents only publicly disclosed vulnerabilities in tracked components. The true exposure is far larger.

For automotive OEMs and Tier-1 suppliers, vulnerability management is no longer a best-effort activity. UNECE R155 requires that the Cybersecurity Management System (CSMS) include processes for identifying, assessing, and remediating vulnerabilities throughout the vehicle lifecycle. ISO/SAE 21434 dedicates an entire clause (Clause 8) to continuous cybersecurity activities including vulnerability monitoring. This guide provides a comprehensive, end-to-end framework for vulnerability management in connected vehicles, covering every stage from discovery through remediation and regulatory reporting.

Vulnerability Sources

Effective vulnerability management begins with comprehensive intake from all relevant sources. Relying on a single source — such as NVD alone — guarantees blind spots. A mature automotive vulnerability management program aggregates intelligence from at least the following channels:

Public Vulnerability Databases

The National Vulnerability Database (NVD) and the CVE program operated by MITRE are the primary public sources for disclosed vulnerabilities. Automotive teams must monitor NVD not only for vulnerabilities in directly used software (e.g., Linux kernel, OpenSSL, FreeRTOS) but also for vulnerabilities in libraries and components that are embedded within supplier-provided binaries. This is where SBOM-driven vulnerability matching becomes essential: without a complete software bill of materials for every ECU, you cannot reliably determine whether a newly published CVE affects your vehicle. The NVD publishes approximately 25,000–30,000 CVEs per year, of which 3–8% typically affect components found in automotive software stacks. Automated matching against SBOM data is the only practical approach at this volume.

Supplier Notifications

Tier-1 and Tier-2 suppliers are often the first to know about vulnerabilities in their components, sometimes weeks or months before public disclosure. A structured supplier notification channel — typically formalized through contractual obligations in the cybersecurity interface agreement (as recommended by ISO/SAE 21434 Clause 7) — ensures that suppliers proactively inform the OEM when they discover vulnerabilities in delivered components. The notification should include the affected component and version, a preliminary severity assessment, whether an exploit is known, and the expected timeline for a patch. Mature programs use a standardized format such as VEX (Vulnerability Exploitability eXchange) or the CSAF (Common Security Advisory Framework) to enable automated processing of supplier notifications.

Bug Bounty Programs

Several major OEMs now operate bug bounty programs (either directly or through platforms like HackerOne and Bugcrowd) that invite security researchers to find and responsibly disclose vulnerabilities in vehicle systems. Bug bounties are particularly effective at uncovering vulnerabilities in externally accessible attack surfaces: mobile companion apps, cloud API endpoints, Bluetooth and Wi-Fi interfaces, and OTA update mechanisms. A well-structured automotive bug bounty program defines clear scope (which vehicle systems and software versions are in scope), provides researchers with test environments or documentation, establishes response SLAs, and offers competitive rewards calibrated to the safety impact of findings.

Internal Security Testing

Internal testing including static application security testing (SAST), dynamic application security testing (DAST), fuzz testing, penetration testing, and red team exercises generates vulnerability findings that never appear in public databases. Automotive-specific testing should include CAN bus fuzzing, ECU firmware binary analysis, diagnostic protocol testing (UDS, DoIP), OTA update mechanism testing, and V2X message injection testing. Findings from internal testing follow the same vulnerability management lifecycle as externally sourced vulnerabilities, but with the advantage that the OEM has full context on the affected component, deployment scope, and remediation options.

SBOM-Based Continuous Scanning

SBOM scanning tools continuously cross-reference the components listed in your software bill of materials against vulnerability databases, generating alerts when new vulnerabilities are published for any component in any ECU in any vehicle in production. This is the only reliable method for catching vulnerabilities in deeply embedded third-party components that your engineering team may not directly track. Effective SBOM scanning requires that SBOMs are comprehensive (listing all components down to the library level), accurate (correct version numbers), and current (updated whenever software is modified through OTA updates or production line changes).

Threat Intelligence Feeds

Automotive-specific threat intelligence from organizations such as Auto-ISAC (Automotive Information Sharing and Analysis Center), upstream security researchers, and commercial threat intelligence providers supplements vulnerability databases with context about active exploitation, emerging attack techniques, and industry-specific threat actor campaigns. Threat intelligence helps prioritize vulnerability remediation by distinguishing between theoretical vulnerabilities and those actively being exploited in the wild against automotive targets.

Triage and Severity Assessment

Not all vulnerabilities are equal, and the automotive context fundamentally changes how severity should be assessed. A vulnerability with a CVSS base score of 7.5 in a server environment may warrant a different urgency when it affects a safety-critical ECU in a moving vehicle. Automotive vulnerability triage must layer vehicle-specific context on top of standard vulnerability scoring.

Automotive-Contextualized CVSS Scoring

The Common Vulnerability Scoring System (CVSS) version 4.0 provides base, threat, and environmental metric groups. For automotive vulnerability management, the environmental metrics are where the most important adjustments occur:

• Modified Attack Vector: A vulnerability exploitable from the network (AV:N) in a server context may only be exploitable from an adjacent network (AV:A) in a vehicle where the affected ECU is not directly internet-connected but is reachable via the in-vehicle network from a compromised telematics unit.
• Modified Attack Complexity: Exploitation in the vehicle context often requires physical access, specialized hardware (e.g., OBD-II tools), or specific vehicle operating conditions (driving at a certain speed, connected to a specific network), raising the effective attack complexity even when the base score assumes low complexity.
• Safety Impact: CVSS does not natively capture safety impact, but automotive teams must assess whether exploitation could lead to physical harm. A vulnerability that allows arbitrary code execution on the infotainment head unit (confined, non-safety) has fundamentally different urgency than the same vulnerability on a chassis control ECU. ISO/SAE 21434 requires that cybersecurity risk assessment consider safety consequences, and this must be reflected in the effective severity score used for triage.
• Exploitability in the Field: Some vulnerabilities require conditions that are impractical in a real-world vehicle attack: hours of physical access, a specific combination of hardware revisions, or an attacker already having compromised a different subsystem. The environmental score should reflect these practical constraints.

Triage Decision Matrix

The following decision matrix maps the combination of CVSS environmental score and safety impact to a triage outcome with associated response SLAs:

The single most common mistake in automotive vulnerability management is applying IT-centric CVSS base scores without automotive environmental context. A “Critical” CVE in a component that is air-gapped from safety systems and requires physical access to exploit should not consume the same emergency response resources as a remotely exploitable vulnerability in the telematics control unit.

PSIRT Operations

The Product Security Incident Response Team (PSIRT) is the organizational core of automotive vulnerability management. Unlike an IT CSIRT that primarily handles operational security incidents, the automotive PSIRT manages the full lifecycle of product vulnerabilities from intake through remediation and disclosure.

PSIRT Structure and Staffing

An effective automotive PSIRT requires a cross-functional team with representation from cybersecurity engineering, software development, systems engineering, quality assurance, legal, regulatory affairs, and communications. The PSIRT lead must have the authority to escalate vulnerability remediation to engineering management and, for safety-critical issues, to executive leadership. PSIRT team members should be available on-call for emergency-severity vulnerabilities. Organizations that cannot staff a full-time PSIRT should establish a virtual PSIRT model where designated individuals from each function are activated when a vulnerability case is opened.

Case Management Workflow

Every vulnerability that passes initial triage becomes a PSIRT case with a unique identifier, severity classification, affected components and vehicle models, impact analysis, remediation plan, and timeline. The case management workflow tracks the vulnerability through defined stages: intake, triage, investigation, remediation development, testing, deployment, verification, and closure. At each stage transition, the case record is updated with the current status, any changes to severity assessment, and the responsible party. Case management tools should integrate with engineering issue trackers (Jira, Azure DevOps) and SBOM management platforms to maintain traceability from the CVE to the affected components to the remediation change to the OTA deployment.

Supplier Coordination

When a vulnerability affects a supplier-provided component, the PSIRT must coordinate remediation with the supplier. This requires contractual provisions that define supplier response SLAs by severity level, obligate the supplier to provide patches within agreed timelines, and grant the OEM the right to apply compensating controls or workarounds if the supplier cannot meet SLAs. ISO/SAE 21434 Clause 7 explicitly requires cybersecurity interface agreements between OEMs and suppliers that cover vulnerability management responsibilities. In practice, the OEM PSIRT maintains a supplier contact matrix with escalation paths for each critical supplier, and conducts periodic tabletop exercises to validate that the supplier coordination process works under time pressure.

Coordinated Disclosure

When vulnerabilities are discovered by external researchers or reported through bug bounty programs, the OEM must manage the disclosure process to balance transparency with the need to protect vehicle owners during the remediation window.

Disclosure Timeline

The industry-standard coordinated disclosure window is 90 days from the initial report to public disclosure, giving the vendor time to develop and deploy a fix before the vulnerability details are made public. However, automotive remediation timelines are often longer than 90 days due to the complexity of ECU software updates, the need for extensive validation and testing, and the logistics of OTA deployment across a global fleet. Automotive PSIRTs should negotiate disclosure timelines with researchers based on the actual remediation complexity, typically requesting 120–180 days for vulnerabilities requiring ECU firmware updates. Transparency about the reasons for extended timelines and regular progress updates to the researcher help maintain trust and prevent premature disclosure.

Advisory Publication

When remediation is deployed, the PSIRT publishes a security advisory in a structured format (CSAF 2.0 is the emerging standard) that describes the vulnerability, affected products and versions, the fix version, and any workarounds for vehicles that have not yet received the update. Advisories should be published on a dedicated security advisory page (e.g., https://security.oem.com/advisories/) and registered with coordination bodies such as Auto-ISAC. For vulnerabilities with safety implications, the advisory should coordinate with the OEM’s safety recall process and, where applicable, with the relevant type approval authority under R155.

Remediation Pathways

Automotive vulnerability remediation is fundamentally different from IT patch management. You cannot simply push an update to a vehicle the way you would to a server. Each remediation pathway has different timelines, costs, risks, and coverage characteristics:

OTA Software Update

Over-the-air updates are the fastest and most scalable remediation pathway for vehicles equipped with OTA capability. The patch is developed, tested, signed, and deployed to the fleet through the OTA update infrastructure. OTA updates can be targeted by vehicle model, ECU, software version, and geographic region. The key constraints are: the affected ECU must be OTA-updatable (many legacy ECUs are not), the update must pass safety and functional validation, the vehicle owner must consent to the update (in some regulatory environments), and the update must be delivered reliably over cellular connections with limited bandwidth. For critical vulnerabilities, OTA deployment timelines of 14–30 days from patch availability to fleet-wide coverage are achievable for well-instrumented fleets.

Dealer Service Campaign

For ECUs that cannot be updated over-the-air, or for vulnerabilities requiring hardware modifications, the OEM initiates a dealer service campaign. Affected vehicle owners are notified and asked to bring their vehicles to an authorized dealer for the update. Dealer campaigns are expensive (dealer labor costs, parts if hardware changes are needed) and slow (achieving 80% fleet coverage may take 6–12 months depending on owner response rates). However, they remain the only option for certain legacy systems. Dealer campaigns should be coordinated with the OEM’s recall management process and, where applicable, reported to safety regulators (NHTSA in the US, KBA in Germany).

Configuration Change

Some vulnerabilities can be mitigated through configuration changes that do not require a software update: disabling a vulnerable feature, changing a default setting, restricting network access to the affected component, or updating firewall rules on the vehicle gateway ECU. Configuration changes can often be deployed more quickly than full software updates and may serve as a compensating control while a permanent patch is developed. The limitation is that configuration changes cannot fix the underlying vulnerability; they only reduce the attack surface or the exploitability conditions.

Compensating Controls

When a vulnerability cannot be patched within the required SLA (because the supplier has not provided a fix, the ECU cannot be updated, or the patch requires extensive validation), compensating controls reduce the risk to an acceptable level. Examples include: adding an IDS rule to the vehicle IDS that detects exploitation attempts against the specific vulnerability, deploying additional network segmentation to isolate the affected ECU, increasing monitoring sensitivity for indicators of compromise associated with the vulnerability, or disabling the affected feature entirely if the risk outweighs the functionality loss. Compensating controls must be documented in the PSIRT case record and reviewed periodically until a permanent fix is deployed.

Remediation Pathway Comparison

SLA Management

Vulnerability management SLAs define the maximum time permitted from vulnerability discovery to completed remediation for each severity level. Automotive SLAs must account for the unique constraints of vehicle software updates:

Internal SLAs

Internal SLAs govern the OEM’s own response timeline. The clock starts when the vulnerability is first identified (by any source) and stops when the remediation is fully deployed to the affected fleet. Recommended internal SLAs for automotive:

• Emergency (safety-critical, actively exploited): Compensating control within 24 hours, permanent fix deployed within 14 days.
• Critical: Compensating control within 72 hours, permanent fix deployed within 30 days.
• High: Permanent fix deployed within 90 days.
• Medium: Permanent fix included in next scheduled release (typically quarterly).
• Low: Tracked, remediated opportunistically or in next major release.

Supplier SLAs

Supplier SLAs define the maximum time from OEM notification to the supplier delivering a validated patch. Supplier SLAs should be shorter than the OEM’s internal SLAs to allow time for the OEM to integrate, test, and deploy the supplier’s patch. Typical supplier SLAs: Emergency 7 days, Critical 14 days, High 45 days, Medium 90 days. These SLAs must be contractually binding through the cybersecurity interface agreement and backed by escalation procedures and, in extreme cases, penalty provisions for repeated SLA failures.

SLA Tracking and Reporting

SLA compliance should be tracked through automated dashboards that show the current vulnerability backlog by severity, the number of vulnerabilities within and outside SLA, the mean time to remediation (MTTR) by severity, and the remediation coverage rate (percentage of affected vehicles that have received the fix). These metrics should be reported to engineering leadership monthly and to the executive team quarterly. SLA breaches should trigger a root cause analysis to identify systemic issues (insufficient testing resources, slow supplier response, OTA infrastructure limitations) and drive process improvements.

Regulatory Reporting Under R155

UNECE R155 imposes specific requirements for vulnerability management that must be integrated into the lifecycle process:

CSMS Vulnerability Management Requirements

R155 requires that the CSMS include “processes used to identify and manage new cyber threats and vulnerabilities” (R155 Annex 5, Section 7.2.2.2). The type approval authority (or their designated technical service) assesses whether the OEM’s vulnerability management process is adequate during the CSMS audit. The process must demonstrate: systematic monitoring of multiple vulnerability sources, a defined triage and severity assessment methodology, documented remediation procedures with SLAs, supplier coordination mechanisms, and evidence that the process is actively used (not just documented).

Post-Production Monitoring

R155 requires that the OEM “shall monitor, detect and respond to cyber attacks, cyber threats and vulnerabilities on vehicle types and shall demonstrate that monitoring processes allow newly identified cyber threats and vulnerabilities to be appropriately addressed within a reasonable timeframe” (R155 Paragraph 7.2.2.3). This means vulnerability management does not end at vehicle production. The OEM must continuously scan for new vulnerabilities affecting vehicles in the field and remediate them throughout the vehicle type’s lifecycle. The type approval authority can request evidence of post-production vulnerability management activity at any time, including during periodic CSMS certificate renewal audits.

Incident Reporting

Under R155, the OEM must report to the type approval authority “successful or attempted cyber-attacks” identified through monitoring. In the context of vulnerability management, this means that if a vulnerability is discovered to have been actively exploited against production vehicles, the OEM must report this to the relevant approval authority. The reporting should include: the nature of the vulnerability, which vehicle types are affected, the extent of exploitation (if known), the remediation plan and timeline, and any compensating controls in place. The specific reporting format and timeline varies by approval authority, but notification within 72 hours of confirming active exploitation is a common expectation.

Lifecycle Stage Diagram

The following table describes each stage of the vulnerability management lifecycle, the key activities at each stage, the responsible parties, and the outputs that feed into the next stage:

Continuous Monitoring and Feedback Loops

The vulnerability management lifecycle is not linear; it operates as a continuous loop where outputs from later stages feed back into earlier stages:

Post-Deployment Monitoring

After a patch is deployed via OTA, the fleet monitoring system must actively verify that the patched ECUs are no longer exhibiting the vulnerable behavior. This includes monitoring for: vehicles that failed to apply the update (requiring re-push or escalation), regression indicators (new anomalies appearing after the update), and continued exploitation attempts against the patched vulnerability (indicating attacker awareness). SentraX fleet monitoring can be configured with detection rules specific to each remediated vulnerability to provide this post-deployment verification.

Threat Intelligence Feedback

When a vulnerability is discovered to be actively exploited, this information must feed back into the triage stage for all related open vulnerabilities. If a vulnerability in OpenSSL is exploited in an automotive context, all other OpenSSL vulnerabilities in the backlog should be reassessed for severity escalation. Similarly, if a particular attack technique emerges (such as CAN bus injection via a specific diagnostic interface vulnerability), all components accessible through that interface should be re-evaluated.

Process Metrics and Improvement

The vulnerability management process itself must be measured and improved over time. Key metrics include: mean time to triage (from discovery to severity classification), mean time to remediation (from discovery to fleet-wide fix deployment), SLA compliance rate by severity, vulnerability backlog age distribution, and the ratio of vulnerabilities found through proactive scanning versus reactive notification. These metrics should be reviewed quarterly with the goal of continuous improvement in response times and coverage.

How ThreatZ Supports Vulnerability Management

ThreatZ integrates vulnerability management directly into the TARA and SBOM management workflow, providing a unified platform for the entire lifecycle:

SBOM-Driven Vulnerability Matching

ThreatZ continuously scans the SBOM for every ECU in every vehicle model against multiple vulnerability databases (NVD, OSV, supplier advisories). When a new CVE is published that matches a component in your SBOM, ThreatZ automatically creates a vulnerability case, maps it to affected vehicle models and ECU variants, and generates a preliminary severity assessment based on the component’s location in the vehicle architecture and its connectivity to safety-critical systems.

Automated CVSS Contextualization

ThreatZ automatically adjusts CVSS base scores with automotive environmental metrics derived from the vehicle architecture model. The platform knows which ECUs are network-connected, which have safety dependencies, and which are OTA-updatable, enabling automated severity classification that reflects actual vehicle-level risk rather than generic IT-centric scores.

Compliance Evidence Generation

ThreatZ generates the documentation required for R155 CSMS audits: a complete audit trail of every vulnerability case from discovery through closure, SLA compliance reports, evidence of continuous monitoring activity, and traceability from TARA threat scenarios to specific vulnerability remediations. This evidence package can be exported in formats accepted by major technical services (TUV, DEKRA, Bureau Veritas) for CSMS assessment.

Key Takeaways

• Effective automotive vulnerability management requires intake from at least six source categories: public databases, supplier notifications, bug bounties, internal testing, SBOM scanning, and threat intelligence feeds.
• Standard CVSS base scores must be adjusted with automotive environmental context — particularly safety impact and in-vehicle exploitability — to produce meaningful severity classifications.
• The PSIRT is the organizational core of vulnerability management, requiring cross-functional staffing and the authority to escalate remediation across engineering teams and suppliers.
• Automotive remediation pathways (OTA, dealer campaign, configuration change, compensating control) have fundamentally different speed, cost, and coverage characteristics that must inform the remediation strategy.
• Supplier SLAs must be contractually binding through the cybersecurity interface agreement and shorter than the OEM’s internal SLAs to allow integration and testing time.
• UNECE R155 requires vulnerability management as part of the CSMS, including continuous post-production monitoring and reporting of exploited vulnerabilities to the type approval authority.
• Vulnerability management is a continuous loop, not a linear process — post-deployment monitoring, threat intelligence feedback, and process metrics drive ongoing improvement.
• SBOM-driven vulnerability matching is the only practical approach for tracking the thousands of components embedded in a modern connected vehicle.