AutoST for OEM Security Teams: Supplier ECUs, Gateways and Vehicle Networks

The job

An OEM security team owns the cybersecurity of the vehicle but writes almost none of the ECU firmware. Dozens of ECUs come from a dozen suppliers, each with its own diagnostic stack, its own SecurityAccess algorithm and its own idea of what “tested” means. The team sets the requirements, accepts the work products and has to show at type approval that the mitigations from UN R155 Annex 5 hold on the vehicle that ships.

In a complete-vehicle penetration test for an OEM, most of the critical findings were not clever. A gateway routed DoIP requests to ECUs that should have been blocked. A body ECU offered ECUReset and RoutineControl in the default session. Two suppliers had SecurityAccess keys that could be computed from the seed with a short constant. Each of these would have been found by a repeatable check on the supplier’s bench, months earlier and for a fraction of the cost.

What the role needs from a test run

The team needs the same test applied to every ECU, with results it can compare across suppliers.

• One test set across suppliers. UDS enumeration of sessions, services and DIDs, SecurityAccess (0x27) checks and fuzzing run identically on a power-electronics ECU and on an infotainment unit, so the results line up in one table instead of thirty differently formatted supplier reports.
• The gateway and network view. DoIP vehicle discovery and routing activation, UDS over DoIP to the ECUs behind the gateway, and SOME/IP service discovery show what is reachable from the diagnostic port and the vehicle network, not only what each supplier tested in isolation.
• A score to prioritise with. The weighted risk score from 0 to 10 per ECU, configured to the OEM’s own risk model, tells the programme which ECU to escalate first.
• Evidence that survives an audit. PDF reports with a dated history per component, SARIF for the tooling, and a Fix Plan whose tasks carry an ALM/PLM reference to the requirement they belong to.
• Separation between suppliers. Groups and role-based access, so supplier A never sees supplier B’s findings.

What the team does not get from AutoST is a replacement for the penetration test. AutoST covers the repeatable part of the diagnostic and bus attack surface; the full-vehicle pentest and the hard targets (secure boot, HSM, key storage) stay with specialists.

Typical setup

AutoST runs hosted by Zyberum in the EU or as a container on the OEM’s own servers. OEMs almost always choose on-premises, with the dashboard inside the corporate network and the test agents in the labs. The Carbyne agent sits on each bench, on Windows with Vector hardware through the XL driver library or on Linux with any SocketCAN interface such as PEAK or Kvaser, plus Ethernet for DoIP and SOME/IP. The agent polls the backend over HTTPS, so no inbound ports are opened on lab networks.

Who runs what: the central security team defines the test profiles and the risk weighting and owns the dashboard. Component teams or the suppliers’ resident engineers run the scans on their benches. Several OEMs also give key suppliers access so the supplier runs the same profile before delivery; the OEM team compares that result with its own run. Licensing is per tested component and quoted after a demo.

A sensible first project

Start with one gateway and the two or three ECUs behind it that already have a TARA.

1. Week 1: scope and wiring. Pick the gateway and ECUs, collect ODX or CDD files, DBC files and the SecurityAccess levels you expect to be locked. Install the agent on an existing bench and pair it with an API token.
2. Week 2: baseline. Enumeration across sessions, DID and routine scan from the ODX, SecurityAccess checks and DoIP routing tests. Agree the risk weighting with your TARA team.
3. Weeks 3 and 4: fuzzing and review. Seeded UDS fuzzing on the ECUs behind the gateway with crash detection, then a review where each finding is accepted, assigned in the Fix Plan or sent to the supplier with the reproducible request.
4. Weeks 5 and 6: supplier loop and retest. The supplier fixes and re-runs the same profile on its bench; your team re-scans. Risk acceptance and comments carry over, so the report shows what changed.
5. Decision. Compare effort and findings with the last supplier report for the same ECU and decide which vehicle line gets the profile next.

How results feed ISO/SAE 21434 and UN R155

ISO/SAE 21434:2021 asks for verification in Clause 10.4.2: [RQ-10-09] requires that the implementation is verified against the cybersecurity specification, and [RC-10-12] recommends component testing with fuzz testing and vulnerability scanning. AutoST reports are the evidence for that work product at component level. Clause 11 ([RQ-11-01]) names penetration testing for validation at vehicle level; the AutoST baseline tells the pentest team where the diagnostic surface is already clean, so their days go to the hard targets.

UN R155 requires a certified CSMS and, in Annex 5, that the mitigations against the listed threats are implemented and shown to be effective. For threats such as unauthorised diagnostic access or manipulation over the vehicle network, a dated scan history per ECU is the kind of evidence a technical service can follow. UN R156 adds that every software update must keep that security, which means re-testing after each update rather than once per project. Supporting an R155 audit at a Tier-1, the question that came up most was traceability: which test covers which requirement, and when did it last run. The Fix Plan’s ALM/PLM reference and the per-component history answer it. AutoST is not a certification and does not make a vehicle type-approved; it gives the team the evidence the approval needs.