Compliance
ISO/SAE 21434 and UN R155 ask you to verify that security controls work, and to keep the evidence. AutoST produces that evidence, repeatably, on every ECU.
In short
AutoST supports an ISO/SAE 21434 and UN R155 programme on the testing side. ISO/SAE 21434:2021 asks for security testing in three places: Clause 10.4.2 Integration and verification ([RQ-10-09], and [RC-10-12] which recommends component testing with fuzzing and vulnerability scanning to minimise unidentified weaknesses), Clause 11 Cybersecurity validation ([RQ-11-01], which names penetration testing), and Clause 8.5 Vulnerability analysis as a continuous activity. AutoST performs that testing (enumeration, SecurityAccess probing, fuzzing, DoIP/SOME/IP and IVI) and produces the evidence (PDF and SARIF reports, scan history, risk acceptance) behind it. It does not run your CSMS or write your TARA: for those, Zyberum offers ISO/SAE 21434 consulting.
The clauses
References are to ISO/SAE 21434:2021. This is practical guidance, not a certification, but it is where fuzzing, vulnerability analysis and penetration testing live in the standard.
[RQ-10-09] requires you to verify that the implementation meets the cybersecurity specification. [RC-10-12] recommends component testing, with fuzz testing and vulnerability scanning, to minimise unidentified weaknesses. That is exactly what AutoST enumeration, SecurityAccess checks and fuzzing do, repeatably.
[RQ-11-01] names penetration testing as a way to confirm the cybersecurity goals are met. AutoST gives that validation a repeatable, evidenced baseline across the diagnostic and bus attack surface, which specialists can then build on.
Clause 8 treats finding and analysing weaknesses as a continuous activity over the ECU lifetime. Re-running AutoST on every build, via the API and CI, turns that into a standing process rather than a one-off audit.
The attack paths in your TARA are what AutoST tests against: diagnostic services reachable without authentication, weak SecurityAccess, exposed XCP/CCP. Findings feed straight back into the risk picture. Zyberum writes the TARA itself.
Traceability
An auditor does not just want to hear that you tested. They want to see what was tested, when, what was found, and what happened to each finding. AutoST keeps that chain intact.
Each finding carries a severity and a concrete fix. The Fix Plan gives every task a status and an ALM/PLM reference field, so it links back to your requirement or ticket. Scan history and risk acceptance carry across re-tests, so an accepted residual risk stays documented and a fixed issue shows as resolved. Export is PDF for the audit file and SARIF for your tooling.
An honest boundary
AutoST will not write your TARA or run your cybersecurity management system. It is a testing tool, and overselling that would not help you pass an audit.
The strategy, the TARA, the work-product traceability and the audit preparation are consulting work. Zyberum does that too: the same team that builds AutoST holds the SAE and TÜV SÜD Automotive Cybersecurity certification for ISO/SAE 21434.
FAQ
Fuzzing and vulnerability scanning sit under Clause 10.4.2 (Integration and verification), where [RC-10-12] recommends component testing to minimise unidentified weaknesses. Penetration testing is named in Clause 11 (Cybersecurity validation), [RQ-11-01]. Clause 8.5 (Vulnerability analysis) makes finding weaknesses a continuous activity. In practice, fuzz testing of communication interfaces is expected from CAL 2 upward.
No tool does that on its own. AutoST covers the testing and evidence: repeatable security scans and fuzzing for [RC-10-12], a penetration-test baseline for [RQ-11-01], risk scoring, history and PDF/SARIF reports. The TARA, CSMS and audit are process work, which Zyberum can support separately.
Every finding carries a severity and a fix, and each Fix Plan task has an ALM/PLM reference field that links it to your requirement or ticket. Scan history and risk acceptance carry across re-tests, so the audit trail shows what was tested, what was found and what was done about it.
UN R155 requires a certified CSMS and that the mitigations in its Annex 5 are shown to be effective, which means tested. AutoST provides repeatable test evidence for the ECU-level mitigations; Zyberum supports the CSMS and type-approval side.
See it on your ECU
In one hour we scope a pilot: your bench, your protocols, the targets and what success looks like.
Your demo is withTom ZaubermannFounder of Zyberum, ex-lead of the VW InCar Security Testing Lab
Already trusted by Tier 1, Tier 2 suppliers and OEMs. References on request.
We reply within one business day.
Your privacy
We use cookies and similar technologies to measure our website and the success of our ads. You decide which ones we may use. You can change your choice at any time via "Cookie settings" in the footer. Privacy policy
