Applying VEX to Vulnerability Information Sharing in Multi-tier Automotive Supply Chains

Yuta Kiyoumi, Honda R&D Co., Ltd.
Akihiko Takahashi, Fujitsu Limited.
2026年10月26日開催 OSSセキュリティMeetup 講演資料

Transcript

1. Applying VEX to Vulnerability Information Sharing in Multi-tier Automotive Supply Chains Yuta Kiyoumi, Honda R&D Co., Ltd. Akihiko Takahashi, Fujitsu Limited.
2. Who are we? • Yuta Kiyoumi ◦ Assistant Chief Engineer / Security Architect, IVI Software & OSPO @ Honda • Akihiko Takahashi ◦ Engineer / Security Architect, OSS Security & OS Distributor @ Fujitsu
3. Thank You for Your Support — OpenSSF Japan WG Is Now a Sandbox Project
4. Agenda • • • Background and Motivation Evaluation Approach and Findings Lessons Learned and Future Work
5. Background and Motivation
6. Vulnerability Assessment at Automotive Supply Chain Scale • Regulatory and Industry Pressure ◦ ◦ • UN R155 requires a Cybersecurity Management System (CSMS) ISO/SAE 21434 provides the engineering framework Type Approval Authority OEM Vehicle maker Complex Multi-Tier Supply Chains ◦ Automotive development spans OEM → Tier-1 → Tier-2; each tier E-mail assesses CVEs in its own scope ◦ Assessment results are often exchanged through emails and Growing vulnerability volume and assessment Spread sheet workload ◦ Rapid growth in reported vulnerabilities increases assessment Tier-2 Tier-2 supplier … workload → manual workflows reaching their limits … • Tier-1 Tier-1 supplier … spreadsheets, requiring manual transcription and consolidation. Vulnerability Report
7. VEX as a machine-readable assessment exchange format VEX enables product impact assessments to be communicated and reused across the software lifecycle. Structured assessment Supply-chain distribution Assessment filtering • Status and rationale captured in a standardized format • Assessment results can be exchanged without manual transcription • Previously assessed vulnerabilities can be distinguished from unresolved items • Downstream organizations can consume supplier assessments automatically • Teams can focus on remaining review and remediation • Machine-readable and human-auditable FOCUS OF THIS STUDY Tier-2 VEX Tier-1 VEX OEM use Evaluating the preservation of assessment meaning across tier boundaries
8. Vulnerability information sharing with VEX Pilot: machine-readable VEX replaces manual exchange between suppliers ! CURRENT CVE Email & Spread Sheets Manual re-entry CVE found OEM Email Tier-1 Spread Sheets Tier-2 in a product Vehicle maker free-form text Tier-1 supplier manual entry Tier-2 supplier ! WITH VEX CVE Machine-readable Reduce manual re-entry CVE found in a product VEX OEM VEX Vehicle maker machine-readable VEX Tier-1 VEX Tier-2 Tier-1 supplier machine-readable Tier-2 supplier
9. Evaluation Approach and Findings
10. Verification Environment: 3-tier supply chain and IVI system Evaluate vulnerability communication using VEX in a simulated three-tier supply-chain scenario Supply Chain Structure System Architecture • OEM: Integrates the IVI system into the final vehicle. • Tier-1: Develops and supplies the complete IVI hardware and base OS. • Tier-2: Develops specialized applications running on the IVI system. Vehicle IVI System OEM AOSP based VEX VEX IVI App APK Tier-1 VEX VEX Tier-2 OEM Tier-1 Tier-2
11. Verification Overview From detection at OEM through investigation and fix at Tier-2, to reporting and release 1 1 OEM detects → investigation request to supprier OEM detects the CVE in a daily scan 2 Sends VEX (Under Investigation) to Tier-1 3 Tier-1 re-checks and attributes it to Tier-2 2 Tier-2 assesses as Affected → initial report 1 Tier-2 assesses it as affected Sends VEX (Affected) to Tier-1 2 3 OEM reports to customers and authorities CVE CVE VEX OEM 3 Under Investigation Under Investigation Tier-1 Tier-2 Investigating how to fix the vulnerability Tier-2 4 ↑ OSS package upgrade Affected Tier-1 Affected 1 upstream SBOM ✓ 2 OEM re-reports and releases the fix Authorities SBOM Re-report APK Tier-2 Re-scan: no longer detect OEM Updated SBOM / VEX → re-report and release Updated SBOM / VEX passed 2 Re-scan confirms the fix OSS Authorities VEX Initial report Remediation at Tier-2 1 Tier-2 updates the affected package Tier-2 VEX VEX IVI App VEX Fixed Tier-1 IVI System VEX Fixed OEM IVI release Fixed software
12. Verification Overview From detection at OEM through investigation and fix at Tier-2, to reporting and release 1 1 OEM detects → investigation request to supprier OEM detects the CVE in a daily scan 2 Sends VEX (Under Investigation) to Tier-1 3 Tier-1 re-checks and attributes it to Tier-2 2 Tier-2 assesses as Affected → initial report 1 Tier-2 assesses it as affected Sends VEX (Affected) to Tier-1 2 3 OEM reports to customers and authorities CVE CVE VEX OEM 3 Under Investigation Under Investigation Tier-1 Tier-2 Investigating how to fix the vulnerability Tier-2 4 ↑ OSS package upgrade Affected Tier-1 Affected 1 upstream SBOM ✓ 2 OEM re-reports and releases the fix Authorities SBOM Re-report APK Tier-2 Re-scan: no longer detect OEM Updated SBOM / VEX → re-report and release Updated SBOM / VEX passed 2 Re-scan confirms the fix OSS Authorities VEX Initial report Remediation at Tier-2 1 Tier-2 updates the affected package Tier-2 VEX VEX IVI App VEX Fixed Tier-1 IVI System VEX Fixed OEM IVI release Fixed software
13. Verification Overview From detection at OEM through investigation and fix at Tier-2, to reporting and release 1 1 OEM detects → investigation request to supprier OEM detects the CVE in a daily scan 2 Sends VEX (Under Investigation) to Tier-1 3 Tier-1 re-checks and attributes it to Tier-2 2 Tier-2 assesses as Affected → initial report 1 Tier-2 assesses it as affected Sends VEX (Affected) to Tier-1 2 3 OEM reports to customers and authorities CVE CVE VEX OEM 3 Under Investigation Under Investigation Tier-1 Tier-2 Investigating how to fix the vulnerability Tier-2 4 ↑ OSS package upgrade Affected Tier-1 Affected 1 upstream SBOM ✓ 2 OEM re-reports and releases the fix Authorities SBOM Re-report APK Tier-2 Re-scan: no longer detect OEM Updated SBOM / VEX → re-report and release Updated SBOM / VEX passed 2 Re-scan confirms the fix OSS Authorities VEX Initial report Remediation at Tier-2 1 Tier-2 updates the affected package Tier-2 VEX VEX IVI App VEX Fixed Tier-1 IVI System VEX Fixed OEM IVI release Fixed software
14. Verification Overview From detection at OEM through investigation and fix at Tier-2, to reporting and release 1 1 OEM detects → investigation request to supprier OEM detects the CVE in a daily scan 2 Sends VEX (Under Investigation) to Tier-1 3 Tier-1 re-checks and attributes it to Tier-2 2 Tier-2 assesses as Affected → initial report 1 Tier-2 assesses it as affected Sends VEX (Affected) to Tier-1 2 3 OEM reports to customers and authorities CVE CVE VEX OEM 3 Under Investigation Under Investigation Tier-1 Tier-2 Investigating how to fix the vulnerability Tier-2 4 ↑ OSS package upgrade Affected Tier-1 Affected 1 upstream SBOM ✓ 2 OEM re-reports and releases the fix Authorities SBOM Re-report APK Tier-2 Re-scan: no longer detect OEM Updated SBOM / VEX → re-report and release Updated SBOM / VEX passed 2 Re-scan confirms the fix OSS Authorities VEX Initial report Remediation at Tier-2 1 Tier-2 updates the affected package Tier-2 VEX VEX IVI App VEX Fixed Tier-1 IVI System VEX Fixed OEM IVI release Fixed software
15. Verification Overview From detection at OEM through investigation and fix at Tier-2, to reporting and release 1 1 OEM detects → investigation request to supprier OEM detects the CVE in a daily scan 2 Sends VEX (Under Investigation) to Tier-1 3 Tier-1 re-checks and attributes it to Tier-2 2 Tier-2 assesses as Affected → initial report 1 Tier-2 assesses it as affected Sends VEX (Affected) to Tier-1 2 3 OEM reports to customers and authorities CVE CVE VEX OEM 3 Under Investigation Under Investigation Tier-1 Tier-2 Investigating how to fix the vulnerability Tier-2 4 ↑ OSS package upgrade Affected Tier-1 Affected 1 upstream SBOM ✓ 2 OEM re-reports and releases the fix Authorities SBOM Re-report APK Tier-2 Re-scan: no longer detect OEM Updated SBOM / VEX → re-report and release Updated SBOM / VEX passed 2 Re-scan confirms the fix OSS Authorities VEX Initial report Remediation at Tier-2 1 Tier-2 updates the affected package Tier-2 VEX VEX IVI App VEX Fixed Tier-1 IVI System VEX Fixed OEM IVI release Fixed software
16. Verification Environment Spec • • • • • • • Build Target ◦ ◦ Tier-1 : AOSP Android 16 QPR1 (aosp_cf_x86_64_auto / userdebug) Tier-2 : IVI app Tier2App (Gradle-built APK) ◦ ◦ Tier-1 : AOSP build system (m sbom) Tier-2 : spdx-gradle-plugin (./gradlew spdxSbom) SBOM Format : SPDX 2.3 VEX Format : OpenVEX 0.2.0 Vulnerability Scanners : grype, cve-bin-tool (results merged) SBOM Generator VEX Generation : auto-generated in CI from scan results, merged with vexctl Pipeline : GitHub Actions (SBOM → Vulnerability scan → VEX generation)
17. Key Insight - 1: Linking VEX Assessments to Tier Components • Finding ◦ When Tier 1 and Tier 2 components contain the same version of an OSS package, the package’s PURL alone does not identify which tier component the assessment applies to. • Operational Implication ◦ Explicitly link each tier component to the OSS packages it contains, and preserve these relationships when sharing or aggregating VEX documents. NG The assessed product cannot be identified. "statements": [{ "vulnerability": { "name": "CVE-2022-37434" }, "products": [{ "@id": "pkg:generic/zlib@1.2.13" }], "status": "not_affected", "justification": "vulnerable_code_not_present" }] OK "statements": [{ "vulnerability": { "name": "CVE-2022-37434" }, "products": [{ "@id": " pkg:generic/IVI-App@1.1.0" }, "subcomponents": [{ { "@id": "pkg:generic/zlib@1.2.13" } }] }], "status": "not_affected", "justification": "vulnerable_code_not_present" }]
18. Key Insight - 2: Preserving Assessment History • Finding ◦ ◦ • VEX generated only from the latest scan results omits CVEs no longer detected after updates. SBOM comparisons show version changes, but do not by themselves confirm fixes. App ver1.0 Component Version Curl 8.15 OpenSSL 3.14 Record confirmed fixes as fixed for the updated version, enabling OEMs to track reported remediation by CVE across the supply chain. CVE-2025-yyy Vuln Scan & gen VEX VEX software update Operational Implication ◦ CVE-2025-xxx App ver1.1 Component Version Curl 8.17 OpenSSL 3.14 Not detected in the latest scan CVE-2025-xxx CVE-2025-yyy Vuln Scan & gen VEX VEX
19. Additional Key Insight • • • Scalability of VEX updates ◦ Manual VEX updates become difficult as vulnerability volumes increase. ◦ Reliable package identifiers are essential for linking vulnerability scan results to VEX statements. ▪ CPE or PURL or … Importance of package identifiers VEX granularity across the supply chain ◦ ◦ • This study generated one VEX document per product. VEX granularity should be defined based on the assessment unit required at each supply-chain tier. Assessment traceability across suppliers and lifecycle stages ◦ ◦ Even when the assessment remains unchanged, OEMs may want to know which supplier confirmed it and at which lifecycle stage. OpenVEX has no dedicated standard fields for this confirmation history, so methods for recording and sharing it require further consideration.
20. Lessons Learned
21. Lessons Learned & Future Work • Summary ◦ VEX can represent product-specific vulnerability impact assessments at each tier. ◦ VEX assessments can be exchanged across tier boundaries, but product context and assessment history must be preserved explicitly. ◦ • Lifecycle continuity, identifier compatibility, and operational integration are important considerations for applying VEX across multi-tier supply chains. Future Work ◦ ◦ ◦ Validate in real supply-chain operations Define VEX lifecycle, assessment context, and granularity rules Integrate VEX with SBOM, scanning, and vulnerability management workflows
22. Thank you!
23. OpenSSFイベントと OSSEUの昼食
24. OpenSSF Community Day EU 2026 発表者特典
25. HON K OpenSSF Community Day EUROPE 2026