SBOM-driven vulnerability monitoring from CVE intake to TARA update

Problem context

Vulnerability monitoring breaks down whenever the join between deployed components and external feeds is implicit. Without SBOMs, every new high-profile CVE triggers a manual hunt across ECU codebases. The structured fix is an SBOM-anchored pipeline that ingests CVE feeds, EPSS scores, CISA KEV, and supplier advisories — and routes confirmed exposures back into TARA updates and incident response.

Engineering approach

1. Generate SPDX or CycloneDX SBOMs at build time for every ECU artefact and store them alongside the binary in the configuration-management system.
2. Stand up CVE / EPSS / CISA KEV / vendor-advisory ingestion with normalised component identifiers (CPE, package URL).
3. Match feed entries against SBOM components automatically; queue ambiguous matches for analyst triage.
4. Score incoming exposures by impact (mapped from existing TARA outputs) and exploit likelihood (EPSS, KEV presence).
5. Open cybersecurity tickets for exposures above the threshold, link them to affected ECUs and vehicle programmes, and feed them into incident response.
6. Route confirmed material findings into TARA-update workflows and the cybersecurity-case revision history.

Outputs / evidence

• Per-ECU SBOM at every release
• Normalised feed-ingestion pipeline (CVE, EPSS, KEV, vendor advisories)
• Triage queue with auto-match + analyst workflow
• Risk-prioritised vulnerability ticket stream linked to TARA
• Updated TARA artefacts and cybersecurity-case revisions per material finding

Standards touched

• ISO/SAE 21434 Clause 8 (Continual cybersecurity activities)
• SPDX / CycloneDX
• UNECE R155 (post-development monitoring expectations)