Automotive Software Supply Chain Security: Rules, Incidents, 90-Day Plan

Automotive software supply chain security means knowing every software component in every vehicle, plant and dealer system you build or buy, proving where it came from, and acting fast when one of those components turns out to be vulnerable. For automakers and their suppliers the work is set by UN Regulations 155 and 156, ISO/SAE 21434 and, in the United States, the Commerce Department's connected vehicle rule. The fastest way in is a 90-day plan: inventory first, then supplier evidence, then gates and monitoring.

This guide is for the vehicle cybersecurity lead, product security, engineering, homologation and GRC, purchasing, and dealer and plant IT. The first two thirds work with whatever tools you have; Safeguard enters at "How Safeguard does this".

This is not legal, regulatory or type-approval advice. Where the post describes a rule, it describes the primary text as published; your approval authority, technical service and counsel decide how it applies to you.

Key takeaways

• A vehicle program carries software from many suppliers, most of it delivered as binaries with little component detail.
• UN R155 asks for a certified cybersecurity management system (CSMS) that covers supplier risk and ongoing monitoring. UN R156 asks for a software update management system (SUMS) that knows exactly which software versions sit in each vehicle type. In the EU they applied to new vehicle type approvals from 6 July 2022 and to existing type approvals from 7 July 2024, with later dates for small series and some multi-stage vehicles.
• In the US, the Commerce Department's connected vehicle rule (published 16 January 2025, effective 17 March 2025) prohibits certain connectivity and automated driving software with a nexus to China or Russia from Model Year 2027, and requires annual Declarations of Conformity. You cannot declare what you cannot inventory.
• Recent incidents span a dealer software outage (June 2024), connected service web flaws (2024 and 2025), a third-party Bluetooth stack CVE (2025) and a UK production shutdown (September 2025).
• The 90-day plan: days 1 to 30 build the inventory and the supplier map, days 31 to 60 collect supplier SBOMs and VEX and set triage rules, days 61 to 90 turn on gates, monitoring and a repeatable evidence pack.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, software composition analysis with deep transitive dependency scanning, vulnerability management with EPSS and KEV, reachability analysis, CSAF and VEX upload, policies and gates, TPRM (Third-Party Risk Manager), Portal (the SBOM publish and share product), Trust Center, license compliance, attestation and signing, autonomous remediation (GA, ships switched off), the compliance and GRC suite, the CLI and local runner, and on-prem, air-gapped and Zero AI deployment.

The situation

The trigger in automotive is usually a calendar, not a single event: a CSMS audit or certificate review, the monitoring report the approval authority expects, a new vehicle type heading for approval, a supplier contract renewal, a US Declaration of Conformity for the coming model year. Then a CVE lands in a component that might sit in three ECUs from two suppliers, and nobody can say within a day which vehicles carry it.

A bad week looks like this. A Bluetooth stack advisory arrives on Monday. Two Tier 1 suppliers answer quickly, one asks for a week, one says its software is proprietary. Homologation asks whether anything already approved is affected. Engineering asks whether an over-the-air update is needed, and for which software identification numbers. By Friday you have spreadsheets, not answers. The fix is a standing inventory, a supplier evidence process, and rules decided in advance.

What software this industry runs

Automotive is several software industries in one. Each layer has different owners, different suppliers and a different way of receiving software.

In the vehicle

• ECU firmware. Engine, brake, steering, body and battery management controllers, often built on AUTOSAR Classic and real-time operating systems, in C and C++, delivered by Tier 1 suppliers as compiled images.
• High-performance computers and zonal controllers. The software-defined vehicle moves functions onto fewer, larger computers running Linux, hypervisors and AUTOSAR Adaptive. These carry large open source footprints.
• Infotainment and cockpit. Linux and Android-based head units with media, navigation, voice, app stores and Bluetooth and Wi-Fi stacks, frequently licensed from software vendors and integrated by a Tier 1.
• Telematics control units (TCUs). The cellular modem, GNSS and the software that talks to the automaker's backend. This is the vehicle's front door.
• ADAS and automated driving software. Perception, planning and sensor fusion stacks, with machine learning models and heavy use of open source libraries.
• Gateways. The controllers that filter traffic between in-vehicle networks and external interfaces.
• EV-specific software. Battery management, onboard chargers and the charging communication stack.

Around the vehicle

• Over-the-air (OTA) update backends that package, sign and deliver software to vehicles.
• Connected services and mobile apps. Owner apps, remote commands (lock, unlock, start, locate), subscription management and the web APIs behind them.
• Charging infrastructure. Wallboxes and public chargers (EVSE), their firmware and the charge point management systems behind them.
• Diagnostics and service tools used in dealer workshops and independent garages.

Around the business

• Dealer management systems (DMS) that run sales, finance, parts and service at dealerships, usually as hosted software.
• Plant software. MES, SCADA, PLC programs, robot controllers, end-of-line flashing stations that write the software into each ECU, and test benches.
• Engineering toolchains. Compilers, code generators, simulation tools, CI systems, artifact repositories and the build machines that produce every ECU image.
• Enterprise systems shared with the rest of the company: ERP, PLM, supplier portals and logistics.

The question is the same in every layer: what is in it, who made it, and what happens when one piece turns out to be vulnerable. The answers come from different places: industrial vendors, Tier 1 and Tier 2 suppliers who treat component lists as intellectual property, in-house teams building on open source, and hosted service providers.

The regulations and frameworks that apply

US rules lead here because many readers sell into the US market, but any automaker selling globally lives under the UNECE regulations as well. Dates below were checked against published sources on 25 October 2026 where a primary source could be reached; gaps are noted.

United States: the connected vehicle rule (15 CFR part 791)

The Bureau of Industry and Security (BIS) published its final rule, "Securing the Information and Communications Technology and Services Supply Chain: Connected Vehicles", in the Federal Register on 16 January 2025 (90 FR 5360). It took effect on 17 March 2025 and sits in 15 CFR part 791.

According to the BIS announcement of 14 January 2025, the rule covers two system types. The Vehicle Connectivity System (VCS) is the set of systems that let the vehicle communicate externally, including telematics control units, Bluetooth, cellular, satellite and Wi-Fi modules. The Automated Driving System (ADS) covers the software behind automated driving. The rule treats VCS hardware and software, and ADS software, as an undue risk when designed, developed, manufactured or supplied by persons with a sufficient nexus to the People's Republic of China or Russia.

The dates that matter for planning:

BIS says the rule applies for now only to passenger vehicles under 10,001 pounds and that a separate rulemaking for commercial vehicles is intended. Certain importers and manufacturers must submit annual Declarations of Conformity. BIS can issue General Authorizations for lower-risk transactions, and regulated parties can seek Specific Authorizations.

The practical point: a Declaration of Conformity about software origin requires knowing which software is in the VCS and ADS and who developed it, down to the supplier and often below. That is an inventory problem before it is a legal one.

United States: NHTSA guidance and federal SBOM baselines

NHTSA publishes voluntary cybersecurity best practices for modern vehicles, last updated in 2022. It is guidance, not regulation, but it is what US regulators will read when they ask what a reasonable program looks like. We could not retrieve the document on 25 October 2026, so this post does not quote it.

For the SBOM itself, use CISA's 2026 Minimum Elements for a Software Bill of Materials, joint guidance with the NSA, the FBI and international partners that replaces the NTIA's 2021 minimum elements. CISA notes some software types may need additional elements; for vehicle software you will want hardware and software version identifiers too.

UN Regulation No. 155: cybersecurity management systems

UN R155 was adopted under the UNECE World Forum for Harmonization of Vehicle Regulations (WP.29) in 2020 and entered into force in January 2021. It has two layers:

1. The CSMS certificate, issued to the manufacturer for its organizational processes. The CSMS must cover risk identification and assessment, testing, monitoring for and responding to cyber attacks, and the management of risks that come from contracted suppliers, service providers and the manufacturer's own sub-organizations.
2. Vehicle type approval, where the manufacturer shows that a specific vehicle type was assessed against the threats and mitigations listed in the regulation's annex, that supplier-related risks for that type were identified and managed, and that monitoring is in place after approval.

The regulation also expects the manufacturer to report to the approval authority, at least once a year, on its monitoring activity, including new attacks and how they were handled.

In the EU the UN regulations apply through EU type approval; commentators commonly cite the General Safety Regulation, (EU) 2019/2144, as the legal basis, which we could not confirm on EUR-Lex text. The UK Vehicle Certification Agency, a national approval authority, publishes the EU application dates for cybersecurity: from 6 July 2022 for new whole-vehicle type approvals and from 7 July 2024 for existing type approvals in the unlimited series (categories M1, M2, M3, N1, N2, N3), with small series and special purpose vehicles later, from 6 July 2024 for small series approvals and 7 July 2026 for existing approvals. R156 has its own schedule, with 2026 and 2029 dates for some multi-stage vehicles. Other contracting parties to the 1958 Agreement apply the regulations on their own timelines.

UNECE's own pages gave the entry-into-force date of 22 January 2021 in its published notices, but the regulation texts themselves blocked our automated fetches on 25 October 2026, so this post describes R155's structure from the VCA and INCIBE summaries and uses no paragraph numbers. INCIBE's guide says the manufacturer must report, at least annually, on the results of cybersecurity management, including new threats and attacks.

UN Regulation No. 156: software update management systems

UN R156 entered into force alongside R155. It requires a software update management system (SUMS) and, for each vehicle type, control over what software is installed and how it changes. Two ideas from R156 matter most to supply chain work:

• Software identification. R156 introduces the RX Software Identification Number (RXSWIN), an identifier for the type-approval-relevant software of a vehicle system. INCIBE's guide describes it as an identifier selected by the manufacturer, and says the manufacturer records and stores each RXSWIN's composition before and after an update.
• Update records and integrity. R156 expects a documented update process, records of the composition and identifiers of approved systems before and after an update, and a way to check that installed software matches its identifier. Check the exact requirements on impact assessment and package integrity in the regulation text.

Neither works without a map from software versions to their components: R156 records say which versions are in which vehicles, and SBOMs say which versions contain the vulnerable library.

ISO/SAE 21434:2021 and ISO 24089:2023

ISO/SAE 21434, "Road vehicles: Cybersecurity engineering", published in 2021, is the engineering standard most closely mapped to R155; the VCA says R155's requirements can be closely mapped to it. ISO lists it as a first edition dated August 2021. It is a process standard, not a product certificate. Its scope is cybersecurity risk management across concept, development, production, operation, maintenance and decommissioning of vehicle electrical and electronic systems. The VCA points to its clause on distributed cybersecurity activities, which covers manufacturer to supplier agreements and the alignment of responsibilities.

ISO 24089:2023, "Road vehicles: Software update engineering", is a first edition published in February 2023. It covers software update engineering at organization and project level, and the VCA names it the closest applicable standard to R156.

For supply chain work, the supplier agreements, vulnerability monitoring and maintenance activities matter most. ISO's own catalogue pages blocked our fetches, so edition details come from standards bodies that list the ISO record; we cite no clause numbers beyond the one the VCA names. Check wording against your licensed copy before citing it in an audit response.

Real public incidents from the last three years

Dealer software outage, June 2024

On 24 June 2024, Group 1 Automotive, a publicly listed dealer group, filed a statement with the SEC saying that a cybersecurity incident at its third-party software provider, CDK Global, had disrupted its business applications and processes in its US operations that rely on CDK's dealer systems. The company said it activated its incident response procedures, isolated its systems from CDK's platform and kept its US dealerships trading through alternative processes. Its UK dealerships did not use the affected systems. The filing quoted CDK as expecting restoration of the dealer management system to take "several days and not weeks".

One hosted provider sat underneath many dealerships at once, and customers cut connections and fell back to manual work.

Remote commands through connected vehicle web services, 2024 and 2025

On 20 September 2024, independent researchers published findings in Kia's web services, discovered on 11 June 2024, that let them remotely control key vehicle functions on equipped vehicles using only a license plate, and obtain owner personal information. The researchers say the issues were fixed, their demonstration tool was never released, and Kia validated that the flaws were never exploited maliciously.

On 23 January 2025, researchers published a separate finding, discovered on 20 November 2024, in Subaru's STARLINK connected vehicle service. They report that an administrative panel flaw gave targeted access to vehicles and customer accounts in the United States, Canada and Japan, including remote commands and location history. They say the system was patched within 24 hours of the report and was never exploited maliciously.

Both sit in the web layer around the vehicle, not in an ECU.

A vulnerable Bluetooth stack inside vehicles, 2025

CVE-2024-45434, published in the CVE record on 12 September 2025, describes a use-after-free flaw in OpenSynergy BlueSDK through version 6.x. According to the record, an attacker can use it to run code remotely in the context of the user account that runs the Bluetooth process. The record's references point to the vendor and to the researchers' advisory, which reported a set of related flaws in the same stack.

One vendor's stack, integrated by a supplier and shipped by an automaker: each tier needs to know whether it has the affected versions.

Production shutdown at a UK automaker, September 2025

On 2 September 2025, Jaguar Land Rover said it had been affected by a cyber incident, had proactively shut down its systems, and that its retail and production activities had been severely disrupted. It said there was no evidence at that stage that customer data had been stolen. The UK's National Cyber Security Centre said it was working with the company. On 28 September 2025, the UK government announced a loan guarantee expected to unlock up to £1.5 billion, stating the aim was to give certainty to JLR's supply chain.

One manufacturer's incident became a supply chain event for its suppliers, serious enough for government intervention.

See also the Kia license plate takeover.

The personas who own the problem

Automotive spreads supply chain security across more roles than most industries. The table gives the short version; the sections after it give each role's needs and clock.

CISO or Chief Product Security Officer

The CISO in an automaker increasingly owns enterprise security and vehicle product security at once. R155 turns the CSMS into an assessed management system with a certificate, and it covers supplier risk. The board question is how quickly the company can say which vehicles carry an affected component. Before the CSMS audit they need records showing supplier management and monitoring actually ran; each quarter, a few metrics that hold up (SBOM coverage, time to answer exposure questions, open exploited vulnerabilities by program).

Head of Product Security or PSIRT lead

This role triages reports from researchers, suppliers and public advisories. The bottleneck is mapping a component to ECUs, software versions, RXSWINs and vehicles. They need that lookup for every new advisory, VEX statements from suppliers so "not affected" arrives as a document, and a triage rule set that weighs CISA KEV, EPSS, reachability and the TARA impact rating.

VP Engineering or software-defined vehicle platform lead

Engineering leaders want one process instead of four: a rule in a spreadsheet becomes a meeting, a rule in the pipeline becomes a check. At each release train they need a CI gate on known exploited vulnerabilities and disallowed licenses with a written exception path, and for OTA they need confidence that each package is built from known components with provenance they can show.

Homologation and GRC lead

Homologation teams need evidence organized by requirement and kept current. Before type approval, that means the record that supplier-related risks for the vehicle type were identified and managed. Each year, it means inputs for the monitoring report to the approval authority. For ISO/SAE 21434, it means vulnerability analyses and supplier interface agreements.

Purchasing, supplier quality or vendor risk owner

The contract is where supplier obligations live: SBOM delivery, notification timelines, support periods and, now, provenance information for US connected vehicle compliance. Purchasing needs a standard request pack at sourcing, each supplier's track record at renewal, and supplier attestations before each Declaration of Conformity.

Dealer, plant and enterprise IT

The 2024 and 2025 incidents show business systems can stop sales and production as surely as a vehicle flaw. These teams need a list of critical software providers with the sites that depend on each, a tested way to isolate a provider, and an inventory of the software on ECU flashing stations and test benches, which handle every vehicle's software.

Developers at the OEM and the Tier 1

Developers need to know what to do on today's pull request: a clear failure message and a suggested upgrade, not policy prose.

A practical 30/60/90-day plan

This plan works with any toolset, including spreadsheets and open source tools, for an automaker or Tier 1 starting from partial inventories.

Days 1 to 30: inventory and ownership

Goal: know what software you have, who supplies it, and who owns each answer.

1. Name owners for vehicle software inventory, supplier evidence, vulnerability triage and business system vendors.
2. List software by layer. Use the layers in this post: in-vehicle, around the vehicle, around the business. For each vehicle program, list ECUs and computers, the supplier for each, and the current software version and RXSWIN where applicable.
3. Generate SBOMs for everything you build. Cloud backends, mobile apps, OTA services, internal tools and any vehicle software built in house. Use SPDX or CycloneDX.
4. Collect what suppliers already send first.
5. Map critical business software. Dealer management, MES, flashing stations, OTA signing infrastructure, identity, ERP. For each, record the vendor, hosting model, the sites that depend on it, and how you would cut it off.
6. Pick your SBOM baseline. Use CISA's 2026 Minimum Elements as the floor, and add vehicle specific fields: ECU part number, hardware version, software version and RXSWIN.

Days 31 to 60: supplier evidence and triage rules

Goal: get component data from suppliers and decide in advance how you will triage.

1. Send a standard supplier request. Use one template (see below). Ask for SBOMs per software version, a vulnerability notification commitment, a contact for security issues, VEX statements when they say a CVE does not affect them, and provenance information for VCS and ADS software if you sell connected vehicles in the US.
2. Track it like a project. Status per supplier and per program: sent, acknowledged, received, validated, rejected. Escalate at the deadline.
3. Validate what arrives: SBOMs must parse and match the version they claim.
4. Write triage rules from the decision table below, agreed across product security, engineering and homologation.
5. Run one tabletop. Time how long a real recent advisory takes to answer "which vehicles?" That is your baseline.

Days 61 to 90: gates, monitoring and the evidence pack

Goal: make the program run on its own and produce evidence as a by-product.

1. Gate in-house builds. Add a check in CI that fails on known exploited vulnerabilities and on licenses you do not allow in vehicle software, with an exception process that records who approved what and until when.
2. Monitor continuously. Match every SBOM against new advisories daily, with alerts for KEV additions and critical CVEs in vehicle-facing components.
3. Close the loop: when an alert hits a supplier component, request a VEX statement or fix plan and track it.
4. Assemble the evidence pack per program: SBOMs, supplier status, findings with decisions, exceptions with expiry dates, and the monitoring log. It feeds the annual R155 report and ISO/SAE 21434 work products.
5. Report SBOM coverage, time to answer, and open exploited vulnerabilities by program.

Template: the supplier software evidence request

Use this as a starting point for purchasing and supplier quality. Adapt it with counsel before putting it in a contract.

Decision table: triaging a vulnerability in vehicle software

Illustrative scenario: one advisory, three tiers

This is an illustrative scenario with invented round numbers.

A program has 40 ECUs from 12 suppliers. A Bluetooth stack advisory lands. Product security searches SBOMs and finds the stack in two infotainment software versions from one supplier, about 100,000 vehicles. The supplier's VEX says one version is affected. Engineering schedules an OTA update for that RXSWIN, homologation logs the event for the annual report, and purchasing logs the response time. Without the plan, the week goes on emailing 12 suppliers.

How Safeguard does this

Everything below is described from Safeguard's offering documentation and docs.safeguard.sh as of 25 October 2026. Every capability named is GA. Commands are shown as the docs show them; we did not run them for this post.

Step 1: Build the inventory with SBOM generation (GA)

1. In the Safeguard web app, open Integrations from the sidebar. The docs list source code connections (GitHub, GitLab, Bitbucket and generic Git), container image sources (including Amazon ECR, Docker Hub and OCI-compatible registries), AI model sources, and file uploads (manifest files, APK files, and CSAF or VEX documents).
2. Connect repositories and registries for software you build (OTA backends, connected service APIs, mobile apps, tooling). Safeguard generates SBOMs (GA) in SPDX and CycloneDX and runs software composition analysis with deep transitive dependency scanning (GA).
3. For suppliers who will not grant repository access, or for your own teams who want to scan locally, the Safeguard CLI and local runner (GA) scan on your own machine. The CLI docs show:

# Sign in (OAuth device-code flow)
safeguard login

# Scan a local directory
safeguard scan --dir .

# Scan a container image
safeguard scan --image myregistry.azurecr.io/myapp:v1 \
  --registry-username "$REGISTRY_USER" \
  --registry-password "$REGISTRY_PASSWORD"

# Scan an SBOM you already have (SPDX or CycloneDX)
safeguard scan --sbom sbom.json

The docs say that when you scan from the interactive terminal while signed in, the runner uploads the SBOM and findings, never your source.

4. For ECU firmware written in C or C++ without package manifests, bring the SBOM your build system or supplier produces and analyze it with safeguard scan --sbom. The docs do not describe extracting components from a compiled ECU image, so plan on SBOMs from the build.

Step 2: Request and track supplier SBOMs with TPRM (GA)

1. In TPRM (Third-Party Risk Manager), add the supplier and use Request SBOM. The docs describe single requests (pick the vendor, select products, choose a template, set a deadline, send) and bulk requests from the Vendors list.
2. The standard request template covers SBOM format requirements (SPDX, CycloneDX), required fields and submission instructions. You can build custom templates under Settings → Request Templates, for example with your vehicle-specific fields from the template above.
3. Track each request through the statuses the docs list: Sent, Viewed, In Progress, Submitted, Validated, Rejected. Automated follow-ups are documented at 7 days before the deadline, at the deadline, and an escalation 7 days after.
4. Suppliers can submit by email attachment or a secure upload portal.
5. Before accepting a supplier SBOM, validate it. The CLI docs show:

safeguard validate sbom.json --strict -o report.json

The docs say validate checks CycloneDX, SPDX and VEX (CSAF and OpenVEX) documents against their specifications, and --strict treats warnings as errors.

Step 3: Bring in supplier advisories and VEX with CSAF and VEX upload (GA)

1. In Integrations, filter by Upload and choose Upload CSAF/VEX.
2. The docs list support for CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile, as JSON.
3. Name the upload, attach the file, set the project name and version, and upload. VEX documents can mark vulnerabilities as not affected for your products and record mitigation status, which reduces noise in vulnerability reports and leaves a record of why.

Step 4: Prioritize with vulnerability management and reachability analysis (GA)

1. Findings are enriched with EPSS and CISA KEV status through vulnerability management (GA).
2. Reachability analysis (GA) ranks findings by whether the vulnerable code path is actually called, alongside exploit signals, so the first work goes to what is reachable and exploited.
3. Use these signals to implement your triage decision table. The TARA impact rating of the affected vehicle function stays your input; Safeguard does not perform TARA.

Step 5: Enforce rules with policies and gates (GA)

1. Go to Settings → Policies and click Create Policy. The docs describe a visual builder or YAML, with conditions such as severity, CVSS, EPSS, license, component age and maintenance status.
2. Set each policy's action. The docs define three: Block (the gate fails), Warn (the gate passes with a warning naming the policy) and Notify (the gate passes and a notification is sent).
3. Approvals run through exceptions: a developer requests one with a business justification and an expiration date, approvers decide, and the audit trail is recorded.
4. In CI, the docs show:

safeguard ci scan --wait --fail-on-gate <gate>

The docs say this fails the CI job when the gate fails, with policy outcomes turned on for your workspace. They also note that a plain safeguard scan does not fail on findings; gating is done by policy gates in the platform.

5. License compliance (GA) applies to the same pipeline, which matters for copyleft components in shipped vehicle software.

Step 6: Monitor suppliers continuously with TPRM monitoring (GA)

1. TPRM monitoring watches supplier SBOMs for new vulnerabilities, severity changes, exploit availability updates, CISA KEV additions and component health changes.
2. Alerts are configured in Settings → Monitoring, with types the docs name: Critical Vuln, Exploited (CVE added to KEV), Risk Change and SBOM Expiry.
3. Re-scans can run daily, weekly, monthly or quarterly. Re-assessment triggers include new vulnerability disclosures, major version updates, contract renewals and security incidents, which lines up with the purchasing clock.
4. Scheduled reports (weekly to annual) feed the annual monitoring report, which stays yours to write and sign.

Step 7: Fix what you own with autonomous remediation (GA, ships off)

For repositories you connect, autonomous remediation opens fix pull requests; it ships switched off, with every category set to Manual. In a vehicle program, start with backends, apps and tooling, and keep vehicle software changes inside your normal validation and type-approval impact assessment.

Step 8: Share evidence with OEMs, customers and auditors with Portal and Trust Center (GA)

1. If you are a supplier, Portal (the SBOM publish and share product, GA) lets you share SBOMs with an OEM directly by email, through shareable links with expiration dates, download limits and password protection, or through a branded customer portal.
2. Permission levels are View, Download and Full; you can require NDA acceptance, revoke access immediately and see who accessed which SBOM.
3. Trust Center (GA) publishes your security posture on a page for customers.

Step 9: Provenance, compliance records and deployment choices (GA)

1. Attestation and signing (GA) records build provenance (SLSA provenance and in-toto) with SCAL and LCAL scores for the software you build.
2. The compliance and GRC suite (GA) holds controls, evidence, questionnaires and risks. Check the in-app framework list for R155 or ISO/SAE 21434 before planning around it; otherwise map evidence to your own controls.
3. Deployment runs as SaaS, private VPC, on-prem or fully air-gapped, with Zero AI mode (GA) for teams that cannot send code to any language model. Safeguard is designed for FedRAMP High; its SOC 2 Type II audit is in progress.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It is not an approval authority or technical service. Safeguard does not certify a CSMS or SUMS, issue type approvals, or tell you whether a vehicle type complies with R155 or R156.
• It does not perform TARA or safety analysis. Impact ratings, attack feasibility and the link to functional safety under ISO 26262 stay with your engineering teams.
• It does not deliver OTA updates or manage RXSWIN records. Your update management system does that. Safeguard can tell you which software versions contain a vulnerable component if you give it the SBOMs.
• It does not extract components from compiled ECU images on the evidence of its docs. The documented inputs are source repositories, container images, manifests, APKs, AI models and existing SBOMs. For embedded firmware, bring SBOMs from the build or the supplier.
• It does not make your BIS determinations. Whether a supplier has a sufficient nexus to a foreign adversary is a legal and factual question for you and your counsel. Safeguard helps collect and organize supplier information; it does not certify origin.
• It does not fix software you do not build. When the vulnerable code is inside a hosted dealer system, a supplier's binary or an industrial vendor's product, the fix comes from that vendor. Safeguard helps you track and chase it.
• It does not write your regulator reports. Scheduled reports and evidence exports are inputs; the annual monitoring report and any disclosures are yours to write and sign.

Common mistakes

• Treating the CSMS as a document set. R155 asks for processes that run. An audit will look for records that monitoring and supplier management actually happened.
• Asking suppliers for SBOMs without a format or a field list. You get PDFs and spreadsheets that cannot be searched. Name SPDX or CycloneDX and your required fields.
• One SBOM per supplier instead of per software version. Vehicles in the field run many versions. The SBOM must match the RXSWIN and software version.
• Ignoring the cloud and app layer. The 2024 and 2025 connected service findings were in web services, not ECUs.
• Waiting for a CVE to write triage rules. The decision table needs agreement across product security, engineering and homologation before the incident.
• Letting exceptions live forever. Every exception needs an owner, a reason and an expiry date.

FAQ

Does UN R155 require an SBOM?

The regulation does not use the term SBOM in the way US guidance does. It requires the manufacturer to manage supplier-related risks and to monitor for and respond to cyber attacks and vulnerabilities across the vehicle lifecycle. In practice, a component inventory per software version is the most direct way to show both, which is why many automakers now ask suppliers for SBOMs.

When did R155 and R156 become mandatory in the EU?

For new whole-vehicle type approvals in the EU, from 6 July 2022. For existing type approvals in the unlimited series, from 7 July 2024, with later dates for small series and some multi-stage vehicles, per the UK Vehicle Certification Agency. Confirm the dates that apply to your vehicle category and market with your approval authority.

What does the US connected vehicle rule mean for software teams?

It prohibits certain Vehicle Connectivity System and Automated Driving System software with a sufficient nexus to China or Russia from Model Year 2027 for passenger vehicles under 10,001 pounds, and requires annual Declarations of Conformity from certain importers and manufacturers. Software teams need to know which software is in those systems and who developed and supplied it.

What is an RXSWIN?

Under UN R156, it is a manufacturer-selected identifier for the type-approval-relevant software of a vehicle system, used to track which software belongs to a type approval.

Is ISO/SAE 21434 a certification?

No. It is an engineering process standard. Organizations use it to structure cybersecurity engineering and to show how they meet R155. Some assessors offer audits against it, but compliance with the standard is not a product certificate.

How do I get SBOMs from suppliers who say their software is proprietary?

Put the requirement in the sourcing pack and the contract, share SBOMs under NDA with access controls, and accept SBOMs that list components without revealing source.

What should go in a VEX statement from a supplier?

At minimum, the product and version, the vulnerability identifier, a status (affected, not affected, fixed or under investigation) and, for "not affected", a justification. CSAF 2.0 and CycloneDX VEX are common formats.

How fast should we be able to answer "are we affected"?

Set your own target and measure it. A tabletop in the first 60 days gives you a baseline; tighten the target as the inventory improves.

Safeguard's remediation tools cover the open source dependencies and containers you build, which in automotive means connected service backends, apps, OTA tooling and any in-house vehicle software. For supplier binaries, hosted dealer systems and plant vendor products, the fix still comes from the vendor, as the block below says plainly.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to "fix the lodash CVE in this repo". It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow applies to a connected service backend or an owner app repository in your vehicle program.

Click through it at your own pace, or open it full screen.

The second demo shows the local runner. You set up the runner on your own machine, approve it with its device code, then scan from the terminal. For a Tier 1 supplier that will not grant an automaker access to its repositories, this is how scanning can happen on the supplier's own systems.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit; it ends with the upgrade done and tests passing. Engineering leads who want every change approved by a person get the same control on a vehicle software repository.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Federal Register: Connected Vehicles final rule, 90 FR 5360
• BIS: connected vehicle final rule announcement
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• INCIBE: New 2024 cybersecurity regulations for vehicles (guide, June 2024)
• UK Vehicle Certification Agency: Cyber Security and Software Updating
• UNECE: Three landmark UN vehicle regulations enter into force
• EUR-Lex: UN Regulation No 155 consolidated text, Regulation (EU) 2025/5
• EUR-Lex: UN Regulation No 156, Regulation (EU) 2021/388
• ISO/SAE 21434:2021 catalogue record
• ISO 24089:2023 catalogue record
• SEC: Group 1 Automotive statement, 24 June 2024
• Hacking Kia write-up
• Hacking Subaru write-up
• CVE record: CVE-2024-45434
• JLR cyber incident statement
• NCSC statement on JLR
• GOV.UK: JLR loan guarantee
• Safeguard docs: Generate SBOM
• Safeguard docs: CLI usage
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Policies and Gates
• Safeguard docs: Portal Sharing

Related reading: UNECE WP.29 for automotive, R155, R156 and ISO 21434 in plain terms, the US connected vehicle rule explained, SBOMs for ECU firmware, scoping a software recall with an SBOM and what Uptane is.

Try it yourself: download Safeguard or read the Safeguard docs.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.