SBOMs in the Automotive Industry Real World Insights and Recommendations

### Overview In this session, Cortez Fraser Jr., Director of Product at FOSSA and former cybersecurity architect at GE Power, presents practical recommendations and insights into the Software Bill of Materials (SBOM) lifecycle within the automotive industry. Driven by major supply chain incidents such as the SolarWinds compromise and Log4j, as well as regulations like Executive Order 14028, CISA minimum elements, the European Cyber Resilience Act (CRA), and UN R155, automotive OEMs and suppliers must evolve beyond reactive manual manifest reviews. The talk lays out a three-stage maturity progression: SBOM generation and distribution, internal SBOM aggregation and vulnerability triage, and external supplier SBOM ingestion and policy enforcement.

### Key Topics - **Regulatory & Security Drivers:** Shifts spurred by Executive Order 14028, CISA requirements, and UN R155 mandate visibility into critical components and supply chains. - **Standards and Formats:** Primary standards include SPDX (noted for strong licensing support) and CycloneDX (noted for vulnerability reporting and backward compatibility). - **Static vs. Dynamic Metadata:** Differentiating static components (package name, version, license) from dynamic attributes (vulnerability status, support status, end-of-life notices). - **VEX and VDR:** Combining Vulnerability Disclosure Reports (VDR)—which supply CVE details, CVSS scores, and affected versions—with Vulnerability Exploitability eXchange (VEX) statements asserting status (e.g., affected, not affected, under investigation, fixed) and justifications (e.g., inline mitigations). - **Unique Component Identification:** Relying on Package URLs (PURL) or OmniBOR IDs over plain package names or CPEs, while addressing limitations with generic PURLs and commercial packages.

### Technical Details - **Stage 1: Generation & Distribution:** SBOM generation is recommended immediately after the build phase and prior to deployment to ensure production accuracy. For automotive embedded systems, non-package-managed ecosystems (such as Yocto, Buildroot, and custom Linux distributions) pose major identification hurdles compared to ecosystems like npm, Maven, or Python. License compliance reviews during pull requests are emphasized, as restrictive copyleft licenses can force disclosure of proprietary close-source in-vehicle software, handing blueprints to attackers. Secure distribution involves RBAC, time-based access tokens, and encryption. - **Stage 2: Aggregation & Risk Prioritization:** Aggregating SBOMs across varied repositories and microservices into an application-level view resolves discrepancies in transitive dependencies. Fraser discusses adapting CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) into a tailored decision matrix based on application criticality, external exposure, and exploitability. He cautions that remediations should be analyzed holistically, as upgrading packages (e.g., migrating Bootstrap versions) can inadvertently introduce worse CVEs. - **Stage 3: Supplier Ingestion & Third-Party Governance:** OEMs must enforce strict machine-verifiable SBOM policies on suppliers. Relying on generic PURLs (e.g., type 'generic' or Conan PURLs without an associated OS ecosystem) strips vulnerability mapping capabilities. Automating ingestion allows organizations to ingest supplier VEX statements, codify automated ignore rules for non-exploitable flaws, and pinpoint genuine exposure.

### Takeaways To achieve mature software supply chain security, automotive organizations should generate SBOMs post-build, prioritize rich component identifiers (PURLs) over generic descriptors, and combine VEX/VDR automation with customized risk evaluation frameworks (like SSVC). Ultimately, buyers are refusing software and hardware from suppliers incapable of delivering accurate, dynamic bills of materials.