Traceability in an ISO 21434 audit: making fuzzing count

ISO/SAE 21434 does not just ask you to be secure. It asks you to show it, to an assessor, with evidence. That difference is where a lot of good security work falls down in an audit, and security testing is the sharpest example.

The standard asks for the tests. It also asks for the paper trail

The testing requirements are clear enough. Clause 10.4.2 (integration and verification) requires you to verify that the implementation meets the cybersecurity specification ([RQ-10-09]), and [RC-10-12] recommends component testing, with fuzz testing and vulnerability scanning, to minimise unidentified weaknesses. Clause 11 (cybersecurity validation) names penetration testing ([RQ-11-01]). From CAL 2 upward, fuzzing of the communication interfaces is effectively expected.

But a 21434 assessment is not graded on whether you ran a fuzzer. It is graded on your work products: the verification report, the validation report, and ultimately the cybersecurity case that argues your item is adequately secure, judged in the cybersecurity assessment (Clause 6.4.9). The assessor reads the argument and the evidence behind it. A fuzzing campaign that is not written into that argument may as well not have happened.

Bidirectional traceability, in one sentence

The thing assessors keep asking for is bidirectional traceability: a documented link from every cybersecurity requirement to the test that verifies it, and from every test back to a requirement.

For security testing that means an assessor can start at a cybersecurity goal (“the ECU must not accept diagnostic writes without authentication”), follow it to a cybersecurity requirement, follow that to the test that checks it, and see the result, its date, and what happened to any finding. And they can go the other way: pick a finding and trace it back to the requirement it threatens.

Most teams can produce the tests. Far fewer can produce that chain on the day of the assessment.

Where fuzzing specifically gets hard

Fuzzing is uniquely awkward to make traceable, for three reasons:

• It is non-deterministic by nature. If a crash cannot be reproduced, it is an anecdote, not evidence. An assessor cannot accept “it crashed once in March”.
• It produces volume, not structure. Millions of iterations and a pile of logs do not map cleanly onto a short list of cybersecurity requirements.
• It is run late and rarely. A one-off campaign before an audit tells you about the software you had that week, not the software you ship, and it carries no history.

So the question an assessor really asks about your fuzzing is not “did you fuzz?” It is: can you reproduce this finding, when did you first see it, which requirement does it relate to, and what did you do about it?

What audit-ready security-test evidence looks like

Whatever tool you use, the evidence has to carry five things:

1. Reproducibility. A stored seed or configuration so any finding can be replayed on demand, by you and by the assessor.
2. A dated history. Not a snapshot, but a record of what was tested and when, across the life of the ECU, so you can show the trend, not just the final state.
3. Linkage to requirements. Each finding tied to the cybersecurity requirement or ticket it affects, so the bidirectional trace holds.
4. Documented risk acceptance. When a residual risk is accepted, the decision and its rationale are recorded and survive into the next test cycle.
5. A readable export. The evidence has to leave the tool in a form the assessor and your own tracker can consume, PDF for the file and SARIF for the tooling.

Get those five right and a fuzzing campaign stops being a log file and becomes a work product.

How AutoST is built for this

This is the part of a 21434 programme AutoST is designed to carry.

Every run is reproducible: the fuzzing seed is stored and shown, so a crash can be replayed exactly. Every scan is dated and kept, so the history over an ECU’s life is there, not reconstructed. Every finding carries a severity and a concrete fix, and the Fix Plan gives each task a status and an ALM/PLM reference field, which is where the link back to your requirement or ticket lives. Risk acceptance and comments carry across re-tests, so an accepted residual risk stays documented and a fixed issue shows as resolved. And the output is PDF for the audit file and SARIF for your tooling.

Because AutoST runs from the API and in CI, the testing becomes a continuous activity in the sense Clause 8.5 intends, rather than a scramble before the assessment. The assessor sees a trend and a trail, not a single heroic campaign.

The honest boundary

AutoST produces the test evidence and keeps it traceable. It does not write your TARA, run your cybersecurity management system or author your cybersecurity case. Those are process and engineering-judgement work. Zyberum does that side too, as consulting, with a team that holds the SAE and TÜV SÜD Automotive Cybersecurity certification for ISO/SAE 21434 and has taken Tier 1, Tier 2 and OEM programmes through exactly this. References are available on request.

If you want to see what audit-ready test evidence looks like on your own ECU, book a demo and we will run it against a real target.