ThreatZ Automotive Protocol Coverage
The ThreatZ TestBench Agent ships protocol packs across six engine families: inventory & topology (INV), conformance & timing (CONF), policy validation (POL), robustness (ROB), fault-profile resilience (FAULT), and regression & replay (REG). This page is the canonical, code-backed coverage matrix — updated with every release.
| Protocol | Bench dependency | INV | CONF | POL | ROB | FAULT | REG |
|---|---|---|---|---|---|---|---|
| In-Vehicle Bus | |||||||
| CAN | Vector CANoe | YES | YES | ~ | YES | ~ | YES |
| CAN-FD | Vector CANoe | YES | YES | ~ | YES | ~ | YES |
| LIN | LIN HW | YES | YES | — | ~ | ~ | YES |
| FlexRay | FlexRay HW | YES | YES | — | ~ | ~ | YES |
| Automotive Ethernet | Raw socket, TSN NIC | YES | YES | ~ | YES | YES | YES |
| CAN-XL | Bench harness | · | · | · | · | · | · |
| Service-Oriented IPC | |||||||
| SOME/IP | Raw socket | YES | YES | YES | YES | YES | YES |
| DDS | pcap-only today | ~ | ~ | — | · | · | · |
| Diagnostics & Calibration | |||||||
| ISO-TP | ISO-TP stack | YES | YES | — | YES | ~ | YES |
| DoIP | DoIP stack + raw socket | YES | YES | ~ | YES | YES | YES |
| UDS | ISO-TP / DoIP stack | YES | YES | YES | YES | ~ | YES |
| XCP | XCP stack | YES | YES | YES | ~ | ~ | YES |
| OBD-II | ISO-TP stack | YES | YES | — | ~ | — | YES |
| J1939 | Vector CANoe | ~ | ~ | — | · | · | · |
| CANopen | Vector CANoe | · | · | · | · | · | · |
| Security & Time Sync | |||||||
| TLS | pcap-only (observe; handshake metadata) | YES | YES | YES | · | ~ | YES |
| SecOC / E2E | Vector tooling | YES | YES | YES | — | — | YES |
| PTP / gPTP | ptp4l / phc2sys | YES | YES | — | — | YES | YES |
| Logging | |||||||
| DLT | pcap / log | YES | YES | — | — | — | YES |
| Charging & V2X | |||||||
| ISO 15118 | Charging bench | · | · | · | · | · | · |
| V2X | V2X HW | · | · | · | · | · | · |
Charging & V2X note: ISO 15118 (CCS / CHAdeMO / GB/T / NACS family) and V2X (DSRC / C-V2X) are supported in the ThreatZ architecture and TARA planes today — you can model these protocols in the system canvas, run threat scenarios, and assign damage scenarios against them. Active protocol fuzzing (ROB) and conformance (CONF) packs for these families are on the active roadmap, gated by bench availability for customer programmes.
How protocol packs work
Every ThreatZ protocol pack encodes the actual attack surface of its protocol: frame periodicity, service ID space, security-seed window, SecOC freshness counter range, ISO-TP segmentation boundaries, and so on. This protocol context drives three things in the platform automatically:
- TARA generation — signal carrier bindings in the system model produce protocol-specific damage scenarios, attack-step templates, and feasibility scores rather than generic STRIDE entries.
- Test campaign generation — conformance, robustness, and penetration campaigns inherit the protocol pack’s catalog of attack steps and edge cases.
- Findings traceability — bench results carry the protocol pack version they were exercised against, so a regression run against a future firmware revision uses exactly the same test surface.
Engine families explained
- INV — Inventory & Topology: discover endpoints, services, sessions visible on the protocol.
- CONF — Conformance & Timing: validate behavior against protocol spec, including timing windows.
- POL — Policy Validation: enforce customer-defined policies (DID allowlists, session restrictions, SecOC freshness).
- ROB — Robustness: catalog-driven negative testing — malformed frames, boundary conditions, oversized payloads.
- FAULT — Fault Profile Resilience: voltage stress, bus errors, frame loss recovery.
- REG — Regression & Replay: deterministic re-execution of prior campaigns for change-driven re-testing.
Updates & methodology
This matrix is the canonical view of the protocol-pack coverage-matrix.yaml shipped with every TestBench Agent release. We publish the matrix because we believe customers should be able to verify, line by line, that the protocols they need are supported at the engine families they need — and that we honestly mark roadmap items as roadmap.
If your programme needs a protocol pack at higher coverage than shown above, contact us — we prioritize roadmap delivery based on real customer programmes.