Third-Party Component Risk Scoring for Automotive Software

Modern vehicles contain between 100 million and 300 million lines of code, and a substantial share of that code comes from third-party sources: open-source libraries, commercial middleware stacks, AUTOSAR BSW modules from independent vendors, and firmware components from semiconductor suppliers. The software bill of materials (SBOM) for a single vehicle program can easily list thousands of components spanning dozens of suppliers. Each of these components carries its own risk profile: known vulnerabilities, licensing constraints, maintenance health, and transitive dependency chains that can amplify exposure in ways that are invisible without systematic analysis.

ISO/SAE 21434 clause 7 explicitly addresses distributed cybersecurity activities and requires organizations to assess the cybersecurity capabilities and risks of their supply chain partners. UNECE R155 requires OEMs to demonstrate that they manage cybersecurity risks throughout the supply chain, including third-party software. The EU Cyber Resilience Act (CRA), entering enforcement in 2027, will impose specific obligations on software component suppliers. These regulatory pressures make third-party component risk scoring not just a best practice but a compliance requirement.

This guide provides a comprehensive framework for building a risk scoring system for third-party software components in the automotive context, covering vulnerability analysis, contextualised CVSS scoring, component criticality weighting, license risk, maintainer health metrics, transitive dependency analysis, and integration with ISO/SAE 21434 processes.

Why Generic Risk Scoring Fails for Automotive

Most software composition analysis (SCA) tools produce risk scores based on the number and severity of known CVEs in a component. While this is a useful starting point, it is woefully insufficient for automotive for several reasons:

Safety Context Changes Everything

A medium-severity vulnerability (CVSS 5.0) in a library used by an infotainment system has very different implications than the same vulnerability in a library used by the ADAS perception pipeline or the brake-by-wire controller. Generic SCA tools treat all instances of a CVE identically regardless of where the affected component runs. In automotive, the deployment context — specifically whether the component executes in a safety-critical ECU, a connected but non-safety ECU, or an isolated subsystem — fundamentally changes the risk.

Attack Feasibility Differs from IT

A vulnerability that requires local network access to exploit is critical in an enterprise environment where attackers can easily reach internal servers. In a vehicle, the same vulnerability may require physical access to a specific ECU or exploitation through a multi-hop attack chain from a remote interface through multiple network gateways. CVSS base scores do not account for the automotive-specific attack surface, which includes physical isolation, gateway firewalls, domain separation, and limited debug interface availability.

Long Vehicle Lifecycles Amplify Risk

Enterprise IT systems are typically refreshed every 3–5 years. Vehicles remain in production for 5–7 years and operate on roads for 15–20 years. A component with a healthy maintenance community today may be abandoned in five years, leaving vehicles in the field running unmaintained code with no security patches available. Automotive risk scoring must account for the long-term sustainability of components, not just their current vulnerability status.

Regulatory and Safety Standards Impose Structure

Automotive software is subject to ISO 26262 (functional safety), ISO/SAE 21434 (cybersecurity), AUTOSAR standards, and type approval regulations. These standards impose specific requirements on the quality, traceability, and verification of software components. A component that meets basic functionality requirements but lacks the process documentation required for ASIL qualification or CAL verification creates compliance risk that is distinct from vulnerability risk.

The Risk Scoring Framework

An effective automotive third-party component risk scoring framework evaluates each component across six dimensions. Each dimension produces a sub-score, and the sub-scores are combined using configurable weights to produce an overall component risk score.

Dimension 1: Vulnerability Exposure

Vulnerability exposure measures the component’s current and historical association with known security vulnerabilities. This is the dimension that most SCA tools focus on, but for automotive it must be contextualised.

• Active CVE count and severity: The number of unpatched CVEs affecting the component’s exact version, weighted by CVSS base score. Critical (9.0–10.0) and high (7.0–8.9) CVEs receive disproportionate weight.
• CVE age: The time since each CVE was published without a patch being applied. A CVE that has been known for 180 days without remediation represents higher risk than a newly disclosed CVE, because the window of exposure is longer and exploit code is more likely to be publicly available.
• Exploit availability: Whether public exploit code exists (e.g., in Exploit-DB, Metasploit, or GitHub proof-of-concepts) and whether the vulnerability is being actively exploited in the wild (per CISA KEV or other threat intelligence feeds). Exploited-in-the-wild CVEs receive the highest weight.
• Historical CVE density: The total number of CVEs filed against the component over its lifetime, normalised by lines of code and time. Components with a consistent history of security issues are statistically more likely to have undiscovered vulnerabilities.
• Patch lag: The average time between CVE disclosure and patch availability for this component. Components whose maintainers consistently deliver patches within days carry less risk than those where patches take months.

Dimension 2: Automotive Context Weighting

This dimension adjusts the vulnerability exposure score based on where and how the component is deployed in the vehicle architecture. The same vulnerability in the same component produces different risk scores depending on context.

• ECU criticality tier: Components deployed on safety-critical ECUs (ASIL B/C/D rated — powertrain, braking, steering, ADAS) receive the highest context multiplier. Components on connected but non-safety ECUs (telematics, infotainment) receive a moderate multiplier. Components on isolated subsystems with no external attack surface receive the lowest multiplier.
• Network exposure: Components that process data from external interfaces (cellular, Wi-Fi, Bluetooth, OBD-II, V2X) have higher context weight than components that only handle internal bus communication.
• Privilege level: Components running with root or kernel privileges are weighted higher than those running in sandboxed user-space processes.
• Data sensitivity: Components that handle cryptographic keys, authentication credentials, PII, or safety-critical control signals receive elevated context weighting.

Dimension 3: Component Health and Maintenance

Component health metrics assess the long-term sustainability and maintenance quality of the component. For automotive’s extended lifecycle requirements, these metrics are as important as vulnerability counts.

• Maintainer activity: Frequency of commits, releases, and issue responses over the past 12 months. A component with no commits in 12 months is likely abandoned.
• Contributor diversity: The number of active contributors and the bus factor (how many people would need to leave for the project to stall). Single-maintainer projects carry higher risk.
• Release cadence: Regular, predictable releases indicate an active maintenance process. Irregular or absent releases suggest potential abandonment.
• Issue responsiveness: The median time to first response on security-related issues. Components where security issues languish for weeks without acknowledgment are higher risk.
• CI/CD and testing maturity: Whether the component has automated testing, continuous integration, code coverage reporting, and security scanning (SAST, fuzzing) integrated into its development pipeline.
• Vendor support status: For commercial components, whether the vendor provides active support, has published an end-of-life date, or has been acquired or dissolved.

Dimension 4: License Risk

Software license compliance in automotive is a significant concern because of the long product lifecycle, the complexity of the supply chain, and the regulatory environment. License risk scoring considers:

• Copyleft exposure: Components under strong copyleft licenses (GPL, AGPL) require careful analysis of how they are integrated to avoid triggering obligations that may be incompatible with proprietary code distribution models. Components under weak copyleft (LGPL, MPL) or permissive licenses (MIT, BSD, Apache 2.0) carry lower risk.
• License compatibility: Whether the component’s license is compatible with the licenses of other components in the same binary or system. Incompatible license combinations can create legal risk that requires architectural changes to resolve.
• License ambiguity: Components with unclear, missing, or contradictory license declarations carry elevated risk because the legal obligations are uncertain.
• Patent clauses: Some licenses include patent grant clauses (Apache 2.0) or patent retaliation clauses. The presence or absence of patent protection affects risk, particularly for components implementing standards-essential patents.
• Export control implications: Components containing cryptographic code may be subject to export control regulations. Components with cryptographic functionality should be flagged for export compliance review.

Dimension 5: Transitive Dependency Risk

A component’s risk is not limited to its own code. Every dependency that a component pulls in (and every dependency of those dependencies) expands the attack surface and the compliance scope. Transitive dependency risk is one of the most underestimated dimensions in automotive software.

• Dependency depth: The maximum depth of the transitive dependency tree. Deeply nested dependencies are harder to audit, harder to patch, and more likely to introduce unexpected behavior changes during updates.
• Dependency count: The total number of unique transitive dependencies. The larger the dependency tree, the higher the probability that at least one dependency contains a vulnerability or problematic license.
• Transitive vulnerability exposure: The aggregate CVE exposure across all transitive dependencies, weighted by the same contextual factors as direct vulnerability exposure.
• Dependency freshness: Whether the component is using the latest versions of its dependencies or is pinned to outdated versions that may contain known vulnerabilities.
• Phantom dependency risk: Dependencies that are declared but not actually used in the automotive build configuration still inflate the SBOM and create confusion during vulnerability analysis. Conversely, dependencies that are used but not declared create blind spots.

Dimension 6: Supply Chain Provenance

Supply chain provenance evaluates the trustworthiness and integrity of the component’s distribution chain from source to deployment.

• Source verification: Whether the component’s source code is available for review, whether the binary distribution matches the source (reproducible builds), and whether the component is distributed through authenticated channels.
• Signing and integrity: Whether component releases are cryptographically signed, whether the signing key is properly managed, and whether consumers can verify signatures before integration.
• SBOM availability: Whether the component supplier provides a machine-readable SBOM (CycloneDX or SPDX) covering the component and its dependencies. ISO/SAE 21434 clause 7 and the EU CRA both point toward SBOM as a supply chain transparency mechanism.
• Supplier cybersecurity maturity: For commercial components, whether the supplier has an ISO/SAE 21434-aligned CSMS, conducts security testing, and provides vulnerability disclosure and incident response processes.
• Geopolitical and regulatory risk: Whether the component or its maintainers are subject to sanctions, export controls, or regulatory restrictions that could affect availability or support.

Risk Scoring Matrix

The following matrix shows how each risk dimension contributes to the overall component risk score. The weights are configurable based on the organization’s risk appetite and the specific vehicle program requirements.

The overall component risk score is calculated as the weighted sum of all dimension scores: Risk = (0.30 x Vuln) + (0.25 x Context) + (0.15 x Health) + (0.10 x License) + (0.10 x TransDeps) + (0.10 x Provenance). The result is a score from 0 to 10, which maps to risk levels: Low (0–3), Medium (4–6), High (7–8), and Critical (9–10).

SBOM as the Foundation for Risk Scoring

Effective component risk scoring is impossible without an accurate, comprehensive Software Bill of Materials. The SBOM is the inventory that tells you what components exist in your system, which versions are deployed, what their dependencies are, and where they came from. Without an SBOM, risk scoring is guesswork.

SBOM Generation Approaches

There are three primary methods for generating SBOMs in automotive, and each has different implications for risk scoring accuracy:

• Build-time generation: SBOMs generated during the build process (e.g., by instrumenting the build system or package manager) are the most accurate because they capture exactly which components and versions are compiled into the final binary. Tools like Syft, Trivy, or CycloneDX generators can be integrated into CI/CD pipelines to produce SBOMs automatically with each build.
• Binary analysis: When source code and build systems are not available (common for third-party commercial components), binary analysis tools can extract component information from compiled binaries through string analysis, library detection, and binary fingerprinting. Binary analysis is less precise than build-time generation but is the only option for components delivered as opaque binaries.
• Supplier-provided SBOMs: Increasingly, automotive suppliers are required to deliver SBOMs alongside their software deliverables. The quality and completeness of supplier SBOMs varies widely, and validation against independent analysis is recommended.

SBOM Format Selection

The two dominant SBOM formats in the automotive industry are CycloneDX and SPDX. Both are machine-readable, support component identification, vulnerability correlation, and license declaration. CycloneDX has gained significant traction in automotive due to its native support for vulnerability data (VEX), its extensibility through custom properties, and its alignment with the OWASP ecosystem. SPDX, an ISO standard (ISO/IEC 5962), has broader adoption in some regulatory contexts and stronger support for license compliance workflows. The choice of format should be guided by your tooling ecosystem, supplier requirements, and regulatory expectations.

A risk scoring framework is only as good as the SBOM it operates on. Invest in SBOM accuracy and completeness before investing in sophisticated scoring algorithms. The most accurate risk score applied to an incomplete inventory gives a false sense of security.

Contextualising CVSS for Automotive

The Common Vulnerability Scoring System (CVSS) provides a standardised method for rating vulnerability severity. The CVSS base score reflects the intrinsic characteristics of a vulnerability (attack vector, complexity, privileges required, user interaction, scope, and impact on confidentiality, integrity, and availability). However, the CVSS base score is context-free — it does not account for how or where the vulnerable component is deployed.

CVSS Temporal and Environmental Metrics

CVSS v3.1 and v4.0 include temporal and environmental metric groups specifically designed for contextualisation. The temporal group adjusts scores based on exploit code maturity, remediation level, and report confidence. The environmental group allows organisations to modify the base score based on the importance of the affected component in their specific environment. Despite being part of the CVSS specification, these contextual metrics are rarely used in practice because most organisations lack the processes to systematically evaluate them.

Automotive-Specific Contextualisation

For automotive, we recommend applying the following contextual adjustments to CVSS base scores:

• Attack vector adjustment: CVSS defines attack vectors as Network, Adjacent, Local, and Physical. In automotive, a “Network” vulnerability in a component that is only reachable through a multi-hop path (external interface, telematics gateway, central gateway, target ECU) should be downgraded to reflect the actual attack path complexity. Conversely, a “Local” vulnerability in a component accessible through the OBD-II port (which is physically accessible in every vehicle) may warrant less downgrading than a “Local” vulnerability requiring access to a sealed ECU.
• Impact adjustment for safety: CVSS impact metrics cover confidentiality, integrity, and availability. In automotive, a loss of availability or integrity in a safety-critical system can cause physical harm. The CVSS base score treats all “High” integrity impact equally, but an integrity violation in a brake controller has fundamentally different real-world impact than an integrity violation in an infotainment playlist database. Automotive contextualisation should upweight impact scores for safety-critical components.
• Exploitability adjustment for automotive attack surface: Many CVEs assume an IT-typical attack surface (internet-facing services, standard operating systems, interactive user sessions). The automotive attack surface is different: limited network services, real-time operating systems, no interactive user sessions on most ECUs. Some CVEs that are trivially exploitable in an IT context require significant adaptation for automotive exploitation.

Transitive Dependency Analysis in Depth

Transitive dependencies are the hidden amplifier of third-party risk. A vehicle program that directly integrates 200 components may have 2,000 or more transitive dependencies. The infamous Log4Shell vulnerability (CVE-2021-44228) demonstrated how a single transitive dependency vulnerability can cascade across thousands of applications. In automotive, the same dynamic applies.

Challenges of Transitive Analysis in Automotive

• Heterogeneous build systems: Automotive software combines components built with different toolchains (Yocto/OpenEmbedded for Linux-based ECUs, AUTOSAR build systems for classic platforms, Android build system for infotainment, proprietary build environments for RTOS-based ECUs). Tracing transitive dependencies across these heterogeneous environments requires tooling that understands multiple package managers and build systems.
• Vendor-provided binaries: Many automotive components arrive as pre-compiled binaries without dependency metadata. The transitive dependencies of these components are invisible without binary analysis or explicit SBOM delivery from the vendor.
• Static vs. dynamic linking: Whether a dependency is statically linked (compiled into the binary) or dynamically linked (loaded at runtime) affects both the attack surface and the update strategy. Statically linked dependencies cannot be patched independently — updating them requires rebuilding the entire component.
• Version pinning and conflict resolution: Automotive build systems often pin dependency versions for stability and reproducibility. This means that transitive dependencies may be held at older, vulnerable versions even when newer patched versions exist, because updating them risks breaking compatibility.

Managing Transitive Risk

Effective transitive dependency risk management requires:

1. Complete dependency tree resolution: Generate the full transitive dependency tree for every component, not just the direct dependencies. Tools like OWASP Dependency-Track, Snyk, or ThreatZ SBOM Manager can automate this for supported ecosystems.
2. Vulnerability propagation analysis: When a CVE is filed against a deeply nested transitive dependency, automatically identify all components and ECUs in the vehicle program that are affected through the dependency chain.
3. Update impact assessment: Before updating a transitive dependency to patch a vulnerability, assess the compatibility impact on all components that depend on it (directly or transitively). Automotive cannot afford to break a component by updating a sub-dependency without thorough testing.
4. Dependency minimisation: Actively reduce transitive dependency counts by selecting components with smaller dependency trees, by vendoring critical dependencies (copying them into the component rather than pulling them from external sources), and by eliminating unused dependencies from build configurations.

Integrating Risk Scoring with ISO/SAE 21434

ISO/SAE 21434 clause 7 (Distributed cybersecurity activities) and clause 15 (Cybersecurity monitoring and vulnerability management) provide the normative framework for integrating third-party risk scoring into the automotive cybersecurity lifecycle.

Clause 7: Supplier Cybersecurity Assessment

When a component is sourced from a third party, clause 7 requires the OEM to establish a cybersecurity interface agreement (CIA) that defines the supplier’s cybersecurity responsibilities, including vulnerability management and incident reporting. The third-party component risk score can be used to determine the appropriate level of supplier scrutiny: components with high risk scores should trigger more rigorous supplier assessment activities, including on-site audits, evidence review of the supplier’s development processes, and independent security testing of the delivered component.

Clause 15: Continuous Monitoring

Clause 15 requires continuous monitoring for new vulnerabilities affecting the vehicle throughout its lifecycle. The SBOM, combined with automated CVE correlation and risk scoring, is the operational implementation of this requirement. When a new CVE is published that affects a component in the vehicle SBOM, the risk scoring framework automatically evaluates the contextualised risk and triggers the appropriate response workflow: immediate incident response for critical-risk components, planned remediation for high-risk, monitoring for medium-risk, and documentation for low-risk.

Integration with TARA

Third-party component risk scores should feed into the TARA process as input to attack feasibility assessment. A component with a high vulnerability exposure score and high automotive context weight represents a credible attack entry point. When the TARA team evaluates threat scenarios involving third-party components, the component risk score provides quantitative input to the feasibility assessment rather than relying on subjective expert judgment alone.

Operationalising the Framework

Building a risk scoring framework is an engineering exercise. Operating it at scale across multiple vehicle programs, thousands of components, and continuous vulnerability disclosure is an operational challenge. The following practices are essential for successful operationalisation:

Automated SBOM Ingestion and Correlation

The risk scoring pipeline must ingest SBOMs automatically from build systems and suppliers, correlate component identifiers (CPE, PURL, SWID) against vulnerability databases (NVD, OSV, GitHub Advisory Database, supplier advisories), and update risk scores in near-real-time as new vulnerability data becomes available. Manual SBOM processing and manual CVE correlation do not scale beyond a single vehicle program.

Risk Score Dashboards and Alerting

Product security teams need visibility into component risk scores across all vehicle programs. Dashboard views should show the highest-risk components across the fleet, trending risk scores over time, components approaching end-of-life, and newly disclosed vulnerabilities affecting fleet components. Alert thresholds should trigger automated notifications when component risk scores exceed defined levels.

Remediation Workflow Integration

When a component risk score crosses a threshold, the system should automatically create a remediation ticket with the affected vehicle programs, ECUs, and component versions; the CVE details and exploit status; the recommended remediation actions (patch, upgrade, replace, mitigate); and the timeline constraints based on the risk level. This integration connects risk scoring to engineering action rather than leaving it as a reporting exercise.

Supplier Communication and SBOM Exchange

Establish automated SBOM exchange channels with suppliers so that component inventories are kept current without manual data collection. Define contractual requirements for SBOM format (CycloneDX or SPDX), update frequency, and minimum content (component identifiers, versions, licenses, dependencies). Include risk score thresholds in cybersecurity interface agreements — suppliers whose components consistently score above a defined threshold must provide remediation plans.

How ThreatZ Supports Third-Party Risk Scoring

ThreatZ SBOM Manager provides an integrated platform for automotive third-party component risk scoring. The platform ingests SBOMs in CycloneDX and SPDX formats, automatically correlates components against NVD and OSV vulnerability databases, applies automotive-specific context weighting based on ECU criticality and network exposure configurations, evaluates component health metrics for open-source components, analyses license compliance risk, resolves transitive dependency trees, and produces a contextualised risk score for every component in every vehicle program.

The platform integrates with ThreatZ TARA to feed component risk scores directly into threat analysis and risk assessment workflows. When a new vulnerability is disclosed, ThreatZ automatically re-evaluates affected risk scores and triggers alerting and remediation workflows based on configurable thresholds. Supplier SBOM exchange is managed through the ThreatZ supplier portal, providing a structured channel for receiving and validating supplier SBOMs.

Key Takeaways

• Generic SCA risk scores are insufficient for automotive because they ignore safety context, automotive-specific attack feasibility, long vehicle lifecycles, and regulatory requirements.
• An effective automotive risk scoring framework evaluates six dimensions: vulnerability exposure, automotive context weighting, component health, license risk, transitive dependency risk, and supply chain provenance.
• CVSS base scores must be contextualised for automotive by adjusting attack vector ratings for actual vehicle network topology, upweighting impact scores for safety-critical components, and adjusting exploitability for the automotive attack surface.
• Transitive dependencies amplify risk invisibly. Complete dependency tree resolution, vulnerability propagation analysis, and dependency minimisation are essential practices.
• The SBOM is the foundation: risk scoring accuracy depends entirely on SBOM completeness and accuracy. Invest in SBOM generation quality before investing in scoring sophistication.
• ISO/SAE 21434 clause 7 and clause 15 provide the normative hooks for integrating risk scoring into supplier management and continuous monitoring processes.
• Operationalising the framework requires automated SBOM ingestion, real-time CVE correlation, configurable alerting, and remediation workflow integration.