AutoST for Engineering Service Providers: Security Testing Across Projects

The job

An engineering service provider builds what OEMs and Tier-1s do not build themselves: diagnostic stacks, application software, whole ECUs, test benches and test campaigns. A typical team works for two or three clients at the same time, under NDAs that forbid any data from one project reaching another, and with staff that rotate between projects every few months. Cybersecurity testing increasingly sits in the statement of work, because the client passes its own ISO/SAE 21434 obligations down the chain.

What we regularly see on such projects is not a lack of skill but a lack of continuity. One engineer wrote a seed collection script for the last client, another has a fuzzing setup on a laptop, and when both move to a new project the method leaves with them. The next client gets a different test, a different report format and a different idea of what “tested” means. On the bench, the results look familiar: services reachable in the default session that should need extended session, TesterPresent keeping the programming session alive indefinitely, identification DIDs writable without SecurityAccess.

What the role needs from a test run

A service provider needs a test method it can reuse across clients and hand over in a format each client accepts.

• One method across projects. The same UDS enumeration of sessions, services, sub-functions and DIDs, the same SecurityAccess (0x27) checks and the same seeded UDS and CAN fuzzing, saved as a profile that a new engineer can run on day one.
• The client’s diagnostic description. ODX, ODX-D, PDX or Vector CDD import per ECU, so DIDs carry the client’s names and routine (RID) scans call what is defined. Write probing is off by default and confirmed before anything is written.
• Strict separation. Groups per client project, role-based access per engineer, and the choice of hosting so each client’s confidentiality terms can be met.
• A clean hand-over. A PDF report per component with a dated history, SARIF 2.1.0, CSV or JSON for the client’s tooling, and a Fix Plan with what, risk and fix per finding that the client’s developers or your own can work through.
• Ethernet and IVI where projects need it. UDS over DoIP, DoIP gateway routing and SOME/IP service tests for Ethernet ECUs, and Android IVI checks over ADB for infotainment work.

Typical setup

The provider runs one AutoST instance, either on its own servers or hosted by Zyberum in the EU, with a group per client project. Each project bench gets a Carbyne agent, on Windows with Vector hardware through the XL driver library or on Linux with PEAK, Kvaser or any SocketCAN interface, plus Ethernet for DoIP, SOME/IP and ADB. The agent polls the backend over HTTPS, so benches inside a client-specific lab network need no inbound ports. When a client demands that nothing leaves its premises, a separate installation on the client’s servers is possible.

The security lead owns the profiles and keeps them consistent across projects; project engineers run scans at each integration milestone. Licensing is per tested component and quoted after a demo.

A sensible first project

Use a running client project where security testing is already in the statement of work.

1. Week 1: setup. Create a group for the project, install and pair the agent on its bench, import the client’s ODX or CDD file and agree with the client which SecurityAccess levels and sessions must be locked.
2. Week 2: baseline. Enumeration across sessions, DID and routine scan, SecurityAccess checks. Review the findings with the project lead and decide what goes to the client.
3. Weeks 3 and 4: fuzzing. Seeded UDS fuzzing with TesterPresent liveness and DTC monitoring on the services the ECU exposes; reproduce every crash once.
4. Week 5: hand-over. Deliver the PDF and SARIF export with your own report, and walk the client through the Fix Plan.
5. Week 6: reuse. Save the profile as your standard and run it on a second project, by a different engineer, to check that the method travels.

How results feed ISO/SAE 21434 and UN R155

A service provider is a supplier in the sense of ISO/SAE 21434 Clause 7, and the cybersecurity interface agreement with the client states which verification work it delivers. Clause 10.4.2 requires verification of the implementation against the cybersecurity specification ([RQ-10-09]) and recommends component testing with fuzz testing and vulnerability scanning ([RC-10-12]); the AutoST reports are evidence for that work product, delivered in the same form on every project. Clause 11 ([RQ-11-01]) names penetration testing for validation; that usually stays with the client or its pentest supplier, and AutoST gives them a baseline.

UN R155 is addressed to the vehicle manufacturer, but paragraph 7.2.2.5 requires it to manage supplier dependencies, which is why test evidence against the Annex 5 threats flows up the chain from you to the Tier-1 and the OEM. A dated, reproducible scan per component is the kind of evidence that survives that path. AutoST issues no certificates and does not make a project compliant.