# What an ECU pentest report should contain

The sections an ECU pentest report needs so developers can fix and assessors can trace: scope, bench, reproducible findings, severity, evidence and re-test.

Source: https://auto-st.com/insights/what-an-ecu-pentest-report-should-contain · Updated: 2026-10-07

An ECU penetration test report is good when two people can act on it without calling the tester: the developer who has to fix a finding, and the assessor who has to trace it to a threat scenario in the TARA. That takes seven parts: the scope and item boundary, the bench setup down to firmware version and bitrate, the method with its coverage, findings with the exact bytes to reproduce them, a severity with a stated rationale, dated evidence, and the re-test with the residual risk. A line such as "weak SecurityAccess, high" without the seed values and the request trace is an opinion, not evidence.

## Scope and item boundary

Open with what was tested and, just as important, what was not. Name the ECU variant and hardware revision, the software version as the ECU itself reports it (for example `22 F1 89` for the application software version, `22 F1 95` for the supplier software version), the interfaces in scope and the sessions and security levels the tester had credentials for.

| Item | Why the reader needs it |
| --- | --- |
| ECU variant, hardware and software version | A finding on software 0x0142 may already be fixed in 0x0143 |
| Interfaces in scope (CAN 500 kbit/s, DoIP, ADB) | An interface not listed is assumed untested, not clean |
| Sessions and security levels available | Explains why programming session findings may be missing |
| Explicit exclusions (hardware attacks, firmware extraction, key material) | Prevents the assessor from assuming coverage |

## Bench setup

A reader must be able to rebuild the bench. Record the CAN interface and adapter, the ISO-TP address pair (`0x7E0` request, `0x7E8` response) and addressing mode, the timing parameters used (P2, P2\*, S3), the DBC or ODX revision, the tool versions, the date and the tester. For a DoIP target add the logical addresses and the routing activation type; for an IVI unit the Android build fingerprint and the ADB transport.

## Method and coverage

List what was done per attack surface and how far it went. Coverage figures are what let an assessor judge sufficiency under ISO/SAE 21434 Clause 10.4.2 ([RQ-10-09], [RC-10-12]):

- Enumeration: all service identifiers 0x00 to 0xFE in sessions 0x01, 0x02 and 0x03, plus the manufacturer-specific sessions that answered.
- Data identifiers: the range read (0xF180 to 0xF19F, or the full 0x0000 to 0xFFFF space) per session.
- SecurityAccess: levels tested, number of seeds collected, lockout behaviour observed.
- Fuzzing: campaigns with seed, iteration count, service identifiers in scope and the monitors used.
- Network: DoIP vehicle discovery and routing activation results, SOME/IP services found.

## Findings that can be reproduced

Every finding gets the same structure: an identifier, a title, the affected interface and session, the preconditions, the exact request and response, the expected behaviour, the impact, a severity, a remediation and the reference to the TARA threat scenario and the cybersecurity requirement it violates. One example in the format we use:

```
F-07  WriteDataByIdentifier accepted without SecurityAccess
Interface: CAN 0x7E0/0x7E8, session: extended (10 03), security: locked
Request:   2E F1 8C 41 42 43 44 45 46 47 48
Response:  6E F1 8C
Expected:  7F 2E 33 (securityAccessDenied)
Impact:    ECU serial number (DID F18C) writable by any tester on the bus
Ref:       TS-14 (manipulation of identification data), CSR-022
```

The expected response is the line most reports leave out, and it is the one that settles arguments. ISO 14229-1 says what the ECU should have answered; the specification says which DIDs are writable in which session.

## Severity with a stated rationale

Pick one rating scheme, name it in the report and apply it to every finding the same way. For a TARA-driven programme the impact and attack feasibility ratings from ISO/SAE 21434 Clause 15 fit best, because the finding then lands directly in the risk picture; CVSS 3.1 is fine for software-style findings on an IVI. Either way, write the rationale: "attack feasibility high because the key is derived from the seed with a constant XOR and the bus is reachable from the OBD connector". A severity without a rationale is the first thing an auditor challenges.

List what was found clean too. "SecurityAccess level 1: lockout after three invalid keys, 10 s delay, seeds passed the randomness checks" is a result, and it is the result that proves the mitigation works.

## Evidence

Evidence is raw, dated and attributable: bus logs or captures for every finding, screenshots and logcat excerpts for IVI findings, the fuzzing seed that triggers a crash, hashes of the firmware under test. Put it in appendices or deliver it machine-readable. SARIF 2.1.0 is the practical format for the findings themselves, because it imports into the code-scanning views developers already use.

## Re-test and residual risk

The report is not finished when the findings are delivered. After the fixes, every finding gets a status: fixed and verified on which software version, mitigated by what, accepted as residual risk by whom and when, or still open. The closing section states the residual risk in plain words. That page is what the assessor reads first.

## What AutoST contributes

AutoST writes the repeatable part of this report automatically: the scope with ECU, interface and sessions, the coverage figures, every finding with its request and response bytes, the risk score with the weights behind it, a PDF with a non-repudiation footer and a SARIF export. The Fix Plan carries status, assignee and an ALM/PLM reference per finding across re-tests, so the re-test section writes itself. The narrative, the mapping to your threat scenarios and the findings that need a human stay with the penetration tester.

## FAQ

**How detailed does a finding have to be?**

Detailed enough that a developer reproduces it without calling the tester: session, security state, the exact request bytes, the response the ECU gave and the response the standard or the specification expected.

**Should the report list what was not found?**

Yes. Negative results prove coverage. An assessor who reads that all 255 service identifiers were probed in three sessions and that SecurityAccess locked out after three wrong keys can judge whether the testing was sufficient.

**Which severity scheme should an ECU report use?**

One scheme, named and applied consistently. CVSS 3.1 works for software style findings, the impact and attack feasibility ratings of ISO/SAE 21434 Clause 15 fit a TARA better. The rationale behind each rating matters more than the scheme.

**Can a tool write the report?**

A tool writes the repeatable part: scope, coverage figures, findings with bytes and a dated evidence file. The narrative, the mapping to threat scenarios and the manual findings come from the penetration tester.

## Sources

- [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering, Clauses 10 and 11](https://www.iso.org/standard/70918.html)
- [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1](https://www.iso.org/standard/72439.html)
- [OASIS SARIF 2.1.0 (Static Analysis Results Interchange Format)](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html)

## Related

- [Traceability in an ISO 21434 audit: making fuzzing count](https://auto-st.com/insights/traceability-iso-21434-audit)
- [ISO/SAE 21434 verification evidence from security testing](https://auto-st.com/insights/iso-21434-verification-evidence)
- [How to write an ECU security test plan](https://auto-st.com/insights/ecu-security-test-plan)
- [SARIF (Static Analysis Results Interchange Format)](https://auto-st.com/glossary/sarif)
- [A number you can defend, evidence you can file.](https://auto-st.com/risk-scoring-reports)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/insights/what-an-ecu-pentest-report-should-contain