Supply Chain Complexities in Automotive and the Use Cases for SBOM
Attacks against automotive supply chains have surged lately.
In early February 2025, a Japanese precision parts manufacturer had over 500 GB of sensitive data exfiltrated by a prominent ransomware group targeting various sectors, including automotive suppliers.
The incident is one example of how threat actors can launch full-scale cyber attacks against manufacturers and suppliers in the complex automotive supply chain.
Such incidents underscore how threat actors leverage vulnerabilities within automotive supply chains. An undisclosed vulnerability left undetected in an open-source dependency can exacerbate these threats. Consequently, generating and managing a Software Bill of Materials (SBOM) becomes essential to provide visibility into third-party libraries, dependencies, and interconnected software components, effectively mitigating security gaps before exploitation.
This blog outlines key insights from the Auto-ISAC SBOM Informational Report, emphasizing the impact on supply chains and best practices for collaboration among OEMs, Tier 1 and Tier 2 suppliers.
SBOMs Gaining International Traction Across Governments and Bodies
Implementing SBOM practices aligns automotive manufacturers with critical regulatory requirements, including ISO 26262 for functional safety and ISO/SAE 21434 for cybersecurity. SBOMs provide comprehensive transparency into vehicle-embedded software, facilitating regulatory compliance such as the EU Cyber Resilience Act (CRA), essential for obtaining CE marking.
The table below summarizes the relationship between various governments and bodies with SBOM adoption as outlined in the Auto-ISAC Software Bill of Materials (SBOM) report.
Scope of Global SBOM Impact
Government/Bodies | SBOM |
United States | Cybersecurity and Infrastructure Security Agency (CISA) and the National Highway Traffic Safety Administration (NHTSA) have emphasized SBOM use. EO 14028 emphasizes the importance of an SBOM for improving software supply chain security. OEMs can adopt SBOM practices to evaluate risks in software components and analyze known vulnerabilities throughout the supply chain. |
European Union (EU) | The Cyber Resilience Act (CRA) mandates SBOM compliance for software supply chain security. |
Japan | SBOMs align with US CISA guidelines. The Japanese automotive industry is exploring the implementation of SBOMs in collaboration with METI. |
Gartner projects that in 2025, 60% of organizations procuring mission-critical software will mandate SBOM disclosure in license agreements, highlighting its global significance.
Best Practices for SBOM Sharing & Collaboration
Conducting a Thorough Risk Assessment: Consumer safety and cybersecurity are intertwined. Auto manufacturers must mitigate critical vulnerabilities in the supply chain to protect drivers from roadside accidents. Vehicle software must be updated to address newly discovered threats and patch critical vulnerabilities. OEMs must conduct a thorough risk assessment to minimize the threat surface and meet compliance requirements. ISO/SAE 21434 stresses the importance of conducting a Threat Analysis and Risk Assessment (TARA) to protect the integrity of interconnected vehicle systems and foster collaboration between OEMs and suppliers.
Pre-Sale Considerations: A predefined agreement clause for SBOMs must be established during the purchase negotiation stage to ensure data confidentiality in the Request for Proposal (RFP) and Request for Quotation (RFQ) stages. The report states that SBOM data should be shared with OEMs but not with retail consumers for either vehicles or parts. A Cybersecurity Interface Agreement (CIA) and Development Interface Agreement (DIA) must be included in the pre-sales process beyond the standard NDA to ensure the safe data exchange in an SBOM and outline the responsibilities of design, development, testing, and monitoring.
SBOMs should be incorporated into SLA requirements in all pre-sale documentation, as they impact the workload of Tier 1 and Tier 2 suppliers and influence post-sale security planning for both the supplier and the customer. Releasing a vehicle update is the sole responsibility of the OEM and may result in non-compliance if SBOM management is not properly integrated into the supply chain. Agreements should specify the acceptable and unacceptable licenses for the developed product and associated dependencies.
Development Integration: SBOMs must accurately reflect the software origin for components. The report suggests following several best practices to ensure smooth SBOM adoption for development teams. These practices include declarative dependency management in programming environments and examining project source code and configuration. Manual SBOM generation and maintenance may be substituted if automation methods aren’t available to generate an SBOM.
Vulnerability Management: A complete SBOM exchange facilitates clear communication and transparency between suppliers and consumers for a successful vulnerability management program. Threat intelligence is a critical component of a comprehensive vulnerability management program. Threat intelligence data is collected and aggregated from various sources, including private dark web forums, OSINT, OWASP Top 10, and other cybersecurity frameworks, to analyze the TTPs of attackers.
Security teams can then leverage the threat data to prioritize risk-based vulnerabilities in the supply chain and connected software components during the pre-market design phase. Factors to consider during an SBOM vulnerability management program include severity (typically measured by CVSS or NVD scores), potential data risks to integrity and confidentiality levels, and the complexity of the exploit.
Automation and Tooling: This section is divided into primary and secondary methods.
Primary methods include:
- Vulnerability scanners: Inspect project source code, configuration, and runtime. The sources include a combination of both public and private databases.
- CI/CD systems, specifically CI/CD builds: CI/CD builds inspect dependencies for available updates, analyze license compliance, build artifacts to project binary repositories, and provide teams with project development updates.
- SBOM generation: The report mentions several open-source options, such as OWASP CycloneDX and SPDX, for tracking components and relationships in the supply chain.
Secondary methods include:
- Software Composition Analysis (SCA): SCA scans open-source package files and container images for CVEs and malicious code. SCA may be used as a primary method to inventory received SBOMs and track vulnerabilities found in software products.
- Dynamic analysis or Dynamic Application Security Testing (DAST): This technique tests an application at runtime for vulnerabilities.
- SBOM sending and receiving: This describes cloud storage usage with shared folders and email systems.
- Fuzz testing: Fuzzing is a technique for identifying unknown software bugs and vulnerabilities, particularly in API parameters. The report mentions that many bugs and vulnerabilities were found in open-source software (OSS). Fuzz testing can improve SBOMs by indicating improved component version selections.
Vulnerability disclosure is another key aspect of the sharing and collaboration process. Critical vulnerabilities discovered in any phase of development become the responsibility of the supplier to disclose. Certain metrics may be established and benchmarked to ensure timely vulnerability disclosure. These metrics may include:
- Time to Vulnerability Identification (TTVI)
- Time to Disclosure (TTD)
- Time to Remediation (TTR)
- Number of Unpatched Vulnerabilities
- Vulnerability Recurrence Rate
- Supply Chain Security Compliance Rate
How OEMs and Tier-1 Suppliers can Automate BOM & Vulnerability Management with EVSec
The complexity of managing automotive SBOMs and vulnerabilities demands automated, integrated solutions. C2A Security’s EVSec platform specifically addresses these challenges by:
- Comprehensive SBOM Automation: EVSec automates the creation, management, and validation of SBOMs through advanced binary analysis and dependency scanning, significantly reducing manual workloads and minimizing human error.
- Real-Time Vulnerability Management: By integrating directly with CI/CD pipelines and incident management systems, EVSec continuously updates vulnerability data, ensuring that vulnerabilities are promptly detected, assessed, and prioritized based on real-time risk assessments.
- Advanced Impact Analysis: EVSec enables OEMs and suppliers to swiftly identify and mitigate the exact components impacted by vulnerabilities, providing a clear understanding of risk exposure throughout the software lifecycle.
- Seamless Regulatory Compliance: EVSec automatically generates compliance reports aligned with ISO/SAE 21434, EU CRA, and VEX standards, ensuring that regulatory obligations are consistently met with every development iteration.
Schedule a demo to learn how C2A Security can help automate BOM validation in your supply chain.