Vulnerability Analysis Report - Surround View System (SVS) and Parking Assist (ADAS)

Report ID: VA-SVS-PA-2026-014  |  Version: 1.0  |  Classification: Confidential - OEM/Tier-1 Internal Platform context: TDA4VM (TI J721E) ADAS domain-controller ECU, as covered by this repository’s TDA4VM_*_Requirements.md topic documents. Program: Tier-1-developed SVS + Parking Assist domain controller, OEM-integrated, target SOP (start of production) 2027MY. Analysis type: Point-in-time system-level and software-level vulnerability analysis with evidence artifacts, per ISO 21434 Clause 15 (Threat analysis and risk assessment), SAE J3061 lifecycle activities, and the UN R155 CSMS vulnerability-monitoring obligation (see Section 8). Engagement team (roles, not individuals): Lead Security Assessor (system-level), Embedded Software Security Engineer (static/dynamic analysis, fuzzing), Penetration Tester (bench + vehicle rig), Functional Safety Liaison (ASIL/HARA cross-check), Tier-1 Program Security Manager, OEM PSIRT Analyst (intake of final findings). Relationship to this repo: this report is a standalone deliverable, not a new CSG/FSC/FSR/SYSR/TSC/TSR/SWR/HWR/HSI section. Where a finding is already mitigated by an existing requirement, the specific ID is cited (e.g. CSG-SECOC-1, TSR-1). Where no existing requirement covers a finding, it is flagged as a gap to be routed through TDA4VM_Vulnerability_Analysis_Requirements.md’s risk-treatment process (CSG-VULN-4).

Evidence labeling. All log excerpts, tool-output tables, and crash artifacts referenced from evidence/ in this report are illustrative examples in a realistic format — they were not captured from a real test run, camera rig, fuzzer, or static analyzer. Each evidence file repeats this label. Real, publicly documented CVEs are cited only where explicitly marked “real-world precedent” (verified against NVD at the time of writing) to calibrate severity/feasibility — they are not claimed to exist in this specific codebase. Replace illustrative artifacts with actual tool/lab output before submitting this report as part of an audit package.

0. Scope, Assumptions, and Engagement Context

• Subsystem boundary: Surround View System (4-8 fisheye cameras, ISP, stitching, birds-eye-view rendering) and Parking Assist (ultrasonic sensor fusion, free-space/obstacle perception, trajectory planning, low-speed steering/brake actuation guidance), hosted on a TDA4VM ADAS domain controller, communicating with the rest of the vehicle over CAN and/or automotive Ethernet through a gateway ECU.
• Grounded facts (chip/platform-level: secure boot chain, SA2UL crypto engine, eFuse SWREV/KEYREV, TISCI messages, SecOC MAC/freshness, UDS SecurityAccess, JTAG debug unlock, secure storage KEK/DKEK) are drawn from this repo’s existing topic documents — see citations throughout Sections 4-6.
• Illustrative/generic content: SVS/Parking-specific software elements (camera drivers, ISP pipeline, stitching algorithm, perception model, trajectory planner, ROS2/DDS or AUTOSAR Adaptive middleware) are standard automotive-domain constructs, not TI-verified facts, and are analyzed as such.
• Real-world precedent used for calibration: three publicly disclosed, NVD-verified CVEs from the 2021 coordinated multi-vendor DDS discovery-protocol disclosure (CISA advisory ICSA-21-315-02) are used to justify that the DDS/middleware-layer findings in this report (SW-VC-08, SYS-TS-07) are realistic, not theoretical:
  • CVE-2021-38439 — GurumDDS, heap-based buffer overflow in discovery-protocol handling (CWE-122), CVSS 3.1 base score 9.8 (NVD)/8.6 (CNA), DoS or remote code execution.
  • CVE-2021-38445 — OCI OpenDDS < 3.18.1, length-parameter mismatch in message parsing (CWE-130), CVSS 3.1 base score 9.8 (NVD), remote code execution.
  • CVE-2021-38487 — RTI Connext Professional 4.2-6.1.0 / Connext Micro >=2.4, crafted-packet traffic amplification (CWE-406/CWE-923), CVSS 3.1 base score 9.1 (NVD)/8.2 (RTI), DoS + information exposure. This subsystem’s own middleware stack was not verified against these specific CVE IDs in this pass (vendor/version not in scope of this document) — they are cited solely as evidence that memory-safety and message-validation bugs in DDS implementations have shipped in production before.
• ASIL context (functional safety cross-reference, per ISO 26262): Surround View display-only functions are typically classified QM/ASIL A (driver remains in the control loop). Automated/ remote Parking Assist that actuates steering and braking without a human in the loop is commonly decomposed per ISO 26262-9: perception/planning at QM/ASIL A, with the final actuation arbitration and emergency-stop monitor independently rated ASIL B (final OEM HARA governs the authoritative rating; the ratings here are typical industry convention, not this program’s actual HARA output). This cross-reference is why SYS-TS-02, SYS-TS-06, and SW-VC-05 are treated as safety-critical regardless of their computed CVSS score.
• Not covered: high-speed ADAS functions (highway lane-keep, adaptive cruise) and non-vehicle backend infrastructure are out of scope for this pass.

0.1 Engagement timeline

1. Executive Summary

This analysis examined the SVS/Parking Assist subsystem across nine system-level attack surfaces and eight software components over a 13-week engagement (Section 0.1). 17 threat scenarios were identified at the system level and 12 vulnerability classes at the software level, backed by 7 bench/rig pen-test cases, 8 static-analysis findings, 2 fuzz campaigns worth of crash triage, and one manual code review pass. Three findings are rated safety-critical (Section 5 gives each a full case-study narrative) because they can lead to an unintended or missed actuation command affecting low-speed steering or braking during a parking maneuver:

• SYS-TS-06 / PT-02 — forged/replayed CAN actuation command due to a missing or weak SecOC binding on the parking-command PDU. CVSS 3.1: 8.1 (High) — AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H. Ticket SEC-2412, closed-verified after retest (Section 5.1).
  • SYS-TS-10 / PT-04 — weak UDS SecurityAccess seed/key scheme allowing brute-forced diagnostic unlock, then a routine-control call directly to the actuator self-test service. CVSS 3.1: 8.8 (High) — AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Ticket SEC-2415, closed-verified (Section 5.2).
• SW-VC-05 / CR-01 — unauthenticated/unsigned perception-model update allowing a tampered model to be loaded (ML model integrity). No CVSS assigned (design gap, not an exploitable code defect in the classic sense) — ISO 21434 impact Safety: Major. Ticket SEC-2427, open pending Q3 architecture change (Section 5.3).

Existing chip-level controls in this repo (SecOC MAC+freshness, TDA4VM secure boot chain, UDS SecurityAccess, secure storage KEK/DKEK) already treat several of these risks when correctly applied to the SVS/Parking software stack — the root cause in both closed findings (SYS-TS-06, SYS-TS-10) was that the SVS/Parking application team had not yet integrated the platform controls that already exist and are required elsewhere in this repo, not a missing platform capability. Two concrete architectural gaps remain open and are proposed as candidates for future requirements work (Section 6): image/sensor plausibility checking for camera and ultrasonic spoofing, and signed perception-model artifacts with their own anti-rollback counter.

2. System-Level Vulnerability Analysis

2.1 Attack surfaces

2.2 Threat scenarios (system level)

2.3 Attack tree — “Inject a false parking-assist actuation command”

graph TD
  Goal[Attacker Goal - Inject False Parking Actuation Command]
  Goal --> A1[Path A - CAN Injection]
  Goal --> A2[Path B - Camera or Ultrasonic Spoofing]
  Goal --> A3[Path C - UDS SecurityAccess Abuse]
  Goal --> A4[Path D - Malicious OTA Update]
  Goal --> A5[Path E - Unauthenticated Middleware Message]

  A1 --> A1a[Physical OBD Access or Compromised Gateway]
  A1a --> A1b[Weak or Missing SecOC MAC and Freshness]
  A1b --> A1c[Forge Actuation PDU Accepted by Planner]

  A2 --> A2a[Project Adversarial Pattern or Replay Recorded Frame]
  A2a --> A2b[Perception Pipeline Misclassifies Free Space]
  A2b --> A2c[Planner Issues Unsafe Command From Bad Input]

  A3 --> A3a[Weak Seed Key Challenge Response]
  A3a --> A3b[Bypass Security Access Gate]
  A3b --> A3c[Invoke Routine Control Service Directly]

  A4 --> A4a[Compromise Update Package or Steal Signing Key]
  A4a --> A4b[Bypass Anti Rollback or Signature Check]
  A4b --> A4c[Malicious Planner Logic Activated After Reboot]

  A5 --> A5a[Access Internal DDS or SOME-IP Bus]
  A5a --> A5b[No Message Level Authentication]
  A5b --> A5c[Inject Fabricated Actuation Topic]

2.4 System-level evidence artifacts

Full evidence content is reproduced in the Appendices at the end of this report (this is the consolidated, hand-over form of this deliverable). The same raw files are also kept under evidence/ as attachments for tooling/diff purposes.

2.5 Attack-surface / trust-boundary diagram

graph LR
  subgraph Ext[External or Untrusted]
    CAM[Camera Modules x4-8]
    US[Ultrasonic Sensors]
    OBD[OBD-II Diagnostic Tool]
    TCU[Telematics Unit - OTA Source]
  end

  subgraph ECU[SVS and Parking ECU - TDA4VM]
    ISP[ISP and Stitching Pipeline]
    FUS[Sensor Fusion]
    PER[Perception Model]
    PLN[Trajectory Planner]
    ACT[Actuator Command Interface]
    UDSS[UDS Diagnostic Server]
    OTAC[OTA Client and Secure Reprogramming]
    BOOT[Secure Boot Chain]
  end

  subgraph VehNet[Vehicle Network]
    CANBUS[CAN Bus]
    GW[Gateway ECU]
  end

  subgraph Actu[Actuation Domain]
    EPS[EPS Steering Assist]
    BRK[Brake Actuation]
  end

  CAM -->|video link| ISP
  US -->|range data| CANBUS
  ISP --> FUS
  FUS --> PER
  PER --> PLN
  PLN --> ACT
  ACT -->|CAN command| CANBUS
  CANBUS --> GW
  GW --> EPS
  GW --> BRK
  OBD -->|UDS over CAN| UDSS
  TCU -->|OTA package| OTAC
  OTAC --> BOOT
  BOOT --> ISP

2.6 Data-flow diagram (DFD)

flowchart LR
  Camera[Camera Sensor Data] --> ISP2[ISP Pipeline]
  ISP2 --> Stitch[Stitching Algorithm]
  Stitch --> FusionIn[Sensor Fusion Input]
  Ultrasonic[Ultrasonic Range Data] --> FusionIn
  FusionIn --> Percep[Perception - Free Space and Obstacle Detection]
  Percep --> Plan[Trajectory Planner]
  Plan --> CmdGen[Actuation Command Generator]
  CmdGen -->|SecOC protected PDU| Bus[CAN or Automotive Ethernet]
  Bus --> Actuators[Steering and Brake Actuators]
  Diag[UDS Diagnostic Session] -.->|SecurityAccess gated| Plan
  OTAPkg[OTA Update Package] -.->|Secure Reprogramming path| Percep

3. Software-Level Vulnerability Analysis

3.1 Software component breakdown

3.2 Vulnerability classes (CWE-mapped)

3.3 Software-level evidence artifacts

4. Risk Evaluation (CVSS + ISO 21434 Impact x Feasibility, ASIL-aware)

Each finding is dual-scored, matching how this program’s PSIRT actually triages: CVSS v3.1 gives a vendor-comparable technical severity number; the ISO 21434 impact/feasibility rating (Safety/ Financial/Operational/Privacy x attack-feasibility parameters per Annex G - elapsed time, expertise, knowledge of the item, window of opportunity, equipment) is what actually drives the item’s own risk-treatment decision, because a 9.8 CVSS bug with no safety path is not automatically more urgent than a 6.5 CVSS bug that reaches an actuator. The ASIL column flags whether the finding’s attack path reaches a function inside the ASIL-B-decomposed actuation-arbitration boundary (Section 0).

Top 3 safety-critical risks driving mitigation priority: SYS-TS-06 (Critical, closed-verified), SYS-TS-10 (Critical, closed-verified), SW-VC-05 (High, open). Each has a full case-study narrative in Section 5.

5. Case-Study Narratives (Discovery, Response, Lesson)

Written as short, interview-ready storylines for the three safety-critical findings.

5.1 SYS-TS-06 / PT-02 - the replayed parking-command frame

Discovery. During CAN fuzzing (Ticket SEC-2411), the penetration tester noticed that byte-identical replays of a previously captured, perfectly valid parking-actuation frame (CAN ID 0x2A1) were accepted by the ECU every time, even minutes after capture - the fuzzer’s out-of-range payload mutations were correctly rejected, but a replay of a legitimate frame was not a mutation the fuzzer was designed to flag on its own; it was a manual pen-test observation layered on top of the fuzz corpus (see Appendix C PT-02 and Appendix A).

Investigation. Root cause: the SVS/Parking application team had implemented their own lightweight rolling counter for the 0x2A1 PDU instead of integrating the platform’s existing SecOC stack (CSG-SECOC-1/CSG-SECOC-2), and the counter reset to zero on every ECU reset - so a frame captured before any reset stayed valid indefinitely after one.

Impact. Because 0x2A1 drives the low-speed steering/brake actuation arbitration (ASIL B path, Section 0), a replayed “steer left, proceed” frame injected while the vehicle is stationary in a tight parking bay could command unintended motion toward an object outside the driver’s immediate attention.

Response. Filed as SEC-2412 (Critical), triaged in the Mar 23-27 remediation meeting: decision was to retire the bespoke counter and integrate the existing CSG-SECOC-1 through CSG-SECOC-3 MAC and Data-ID-bound freshness mechanism already mandated platform-wide. Retested Apr 22 against the fix build - replay attempts were rejected with a logged FRESHNESS_FAIL event (CSG-SECOC-4, CSG-LOG-1). Closed-verified.

Lesson (for interviews): the platform already had the right control; the defect was an application team re-implementing a weaker version of it instead of reusing the qualified stack - a recurring finding across ADAS subsystems, and a good example of why a security review has to check integration, not just existence, of a control.

5.2 SYS-TS-10 / PT-04 - the un-rate-limited SecurityAccess seed

Discovery. During UDS diagnostic testing (Ticket SEC-2413), the tester observed the ECU return an identical seed on every requestSeed retry and never impose a lockout/backoff delay, even after 10 consecutive failed sendKey attempts (see Appendix B). A scripted brute force over the (deliberately narrow, in this synthetic example) key space succeeded on the 11th attempt in under ten seconds.

Investigation. The routine-control service unlocked by SecurityAccess level 1 in this subsystem included an actuator self-test routine originally intended only for end-of-line manufacturing test, left reachable from the same session used for normal field diagnostics.

Impact. An attacker with OBD-II access (a widely available, low-cost entry point) could brute force SecurityAccess and directly invoke the actuator self-test routine outside of any planner supervision - bypassing the perception/planning logic entirely.

Response. Filed as SEC-2415 (Critical). Remediation: seed re-randomized per attempt, exponential lockout/backoff after 3 failed attempts per CSG-SA-3, and end-of-line-only routines moved behind a manufacturing-only SecurityAccess level not reachable in the field session, per CSG-SA-4. Retested Apr 23 - 50 scripted brute-force attempts over 10 minutes were all rejected after the 3rd attempt with a logged lockout event. Closed-verified.

Lesson (for interviews): manufacturing/EOL test hooks left reachable in production field sessions are a recurring real-world UDS finding - always ask which SecurityAccess level gates a given routine, and whether that level’s exposure was re-reviewed after the routine’s original manufacturing-only purpose was forgotten.

5.3 SW-VC-05 / CR-01 - the unsigned perception-model file (open finding)

Discovery. During manual code review (Ticket SEC-2426) of perception_loader.c, the reviewer noted the model file is read from a path built by concatenating an OTA-delivered filename with no signature or hash check before the weights are loaded into the inference runtime (see Appendix H CR-01 and Appendix I). The base firmware image is correctly signature-checked through the existing secure boot/reprogramming chain (TSR-1, CSG-SRP-1) - the model file simply was never brought into that same trust boundary because it ships as a separate content-only OTA payload, not a firmware partition.

Investigation. No CVSS score applies cleanly because this is an architectural gap rather than a single exploitable code path - the finding is “absence of a control,” scored purely on ISO 21434 impact/feasibility (Safety: Major, Medium feasibility given OTA-channel or supply-chain compromise is required first).

Impact. A substituted or deliberately degraded perception model (e.g., one with a wider blind spot around a specific obstacle class) would load and run with no detectable difference from a genuine update, directly undermining the free-space/obstacle judgment feeding the ASIL-A/B planner path.

Response. Filed as SEC-2427 (High). Because fixing this properly requires extending the OTA manifest/signing scheme to a new content type (not just a config change), the Mar 23-27 remediation meeting accepted it as an open architecture-change item targeted for a Q3 2026 OTA-manifest revision, with a compensating control in the interim: the model file’s SHA-256 is logged at every boot (CSG-LOG-1) so a substitution would at least be forensically detectable after the fact, even though it would not be prevented.

Lesson (for interviews): ML/AI model artifacts are frequently left outside an otherwise mature secure-boot/OTA trust chain because they are treated as “data,” not “code” - a good talking point for any question about ML supply-chain integrity in ADAS.

6. Mitigation Strategy

7. Compliance Mapping

ISO 21434

• Clause 8 (Continuous cybersecurity activities): findings SW-VC-05, SYS-TS-09 feed into the existing monitoring/vulnerability-management process (TDA4VM_Vulnerability_Analysis_Requirements.md, CSG-VULN-1 through CSG-VULN-5).
• Clause 9/10 (Concept and product development): the two identified gaps (cross-sensor plausibility checking, signed perception-model artifacts) are candidates for new/extended requirements in the concept phase, not immediate patches.
• Clause 15 (Threat analysis and risk assessment methods): Sections 2-4 of this report constitute the TARA pass for this subsystem, using the asset/damage-scenario/threat-scenario/ attack-feasibility vocabulary from this repo’s iso21434-tara-grounding skill.

SAE J3061

• Threat analysis activity: satisfied by Section 2 (attack surfaces, STRIDE, attack tree).
• Secure design review activity: satisfied by Section 6 mapping mitigations to existing requirement IDs and flagging design gaps.
• Vulnerability testing activity: represented by the (illustrative) static/dynamic/fuzz evidence in Section 3.3 — must be replaced with real test-campaign output before this report is used as an audit artifact.

UN R155 (Cyber Security Management System) / UN R156 (Software Update Management System)

These are real, currently-in-force UNECE WP.29 regulations that OEMs selling into the EU/UK/Japan/ Korea markets must hold type-approval certification against (mandatory for all new vehicle types since July 2022, and all new vehicles produced since July 2024 in those markets) — this is the regulatory reason a Tier-1 delivering an SVS/Parking Assist ECU is required to produce evidence like this report at all, not just an ISO 21434 best-practice exercise:

• R155 Annex 5 Part A threat catalogue: this report’s system-level threat scenarios (Section 2.2) are directly traceable to R155 threat categories — e.g. SYS-TS-06 maps to R155’s “spoofing of messages… by impersonation” category, SYS-TS-09/SW-VC-05 map to R155’s update-process threat category.
• R155 monitoring/response obligation: satisfied by routing this report’s findings through the existing CSG-VULN-1 through CSG-VULN-5 continuous-monitoring process.
• R156 (SUMS): SW-VC-05/SW-VC-09 (unsigned/under-scoped rollback protection for OTA artifacts) are a direct R156 compliance gap — R156 requires the update process to protect the integrity of all delivered software content, not only the base firmware image.

ISO 26262 (functional safety cross-reference)

Per the ASIL context in Section 0, findings SYS-TS-06, SYS-TS-10, and SW-VC-05 reach a function inside the (typical-convention) ASIL B actuation-arbitration boundary. This is why they were reviewed jointly with the Functional Safety Liaison rather than triaged by the security team alone — a cybersecurity finding that reaches a safety-rated function must be assessed for whether it also constitutes a new hazardous-event contributor requiring a HARA update, per ISO 21434 Clause 15’s interface with ISO 26262.

8. Next Steps

1. Replace all illustrative evidence files under evidence/ with real tool/lab output.
2. Track SEC-2427/SEC-2429 (open architecture-change items) to the Q3 2026 OTA-manifest revision and the perception-integrity plausibility-check design, respectively.
3. Route the two identified requirement gaps (camera/sensor plausibility checking; signed perception-model artifacts) through requirements-doc-scaffolding/requirements-review if the decision is to formalize them as new CSG/TSR entries.
4. Re-run this analysis after any change to the SVS/Parking software architecture or attack surface (new sensor, new middleware, new OTA content type), and before the next R155/R156 type-approval submission milestone.

Appendices

These appendices are the consolidated evidence body of this report, reproduced in full here so the report is a single self-contained deliverable, matching how a completed vulnerability assessment is typically handed to an OEM or auditor: one document, numbered appendices at the back, rather than a folder of separate files the reader has to open individually. The identical content is also kept as standalone files under evidence/ for tooling and diff convenience; the appendices below are the authoritative copy for this report version.

Appendix A: CAN log excerpt

Illustrative example, not captured from a real bus/vehicle. Source: evidence/system/can_log_excerpt.log.

# CAN log excerpt - abnormal traffic on the parking-assist actuation ID
# Format: timestamp  interface  CAN-ID  DLC  data-bytes

# --- Baseline (normal) traffic: parking actuation command 0x2A1 at ~50 ms cadence ---
1699999900.001200  can0  2A1   8  01 00 32 00 00 00 4F 9C
1699999900.051300  can0  2A1   8  01 00 32 00 00 01 5A 3B
1699999900.101250  can0  2A1   8  01 00 33 00 00 02 61 07

# --- Anomaly window: duplicate/replayed frame with stale counter (byte 5) ---
1699999900.101900  can0  2A1   8  01 00 32 00 00 00 4F 9C   # duplicate, counter rolled back
1699999900.102010  can0  2A1   8  01 00 32 00 00 00 4F 9C   # replayed again 110 us later
1699999900.102125  can0  2A1   8  01 00 32 00 00 00 4F 9C

# --- Bus-load anomaly: high-priority ID flood observed concurrently with the above ---
1699999900.102200  can0  080   8  FF FF FF FF FF FF FF FF
1699999900.102260  can0  080   8  FF FF FF FF FF FF FF FF
1699999900.102320  can0  080   8  FF FF FF FF FF FF FF FF
# ... (2400 additional 0x080 frames omitted, bus load reached 98% for ~1.2s) ...

# --- SecOC verification outcome (logged by the receiving ECU per CSG-SECOC-4) ---
# [SECURITY EVENT] 1699999900.102015  PDU=2A1  result=FRESHNESS_FAIL  reason=counter_replay  action=frame_dropped
# [SECURITY EVENT] 1699999900.102130  PDU=2A1  result=FRESHNESS_FAIL  reason=counter_replay  action=frame_dropped

Related: SYS-TS-06, Section 5.1, ticket SEC-2412.

Appendix B: ECU/UDS access log excerpt

Illustrative example, not captured from a real ECU. Source: evidence/system/ecu_access_log_excerpt.log.

2026-08-10T14:02:11Z  UDS  RX  0x10 0x03                  # DiagnosticSessionControl - extended session
2026-08-10T14:02:11Z  UDS  TX  0x50 0x03 0x00 0x32 0x01 0xF4
2026-08-10T14:02:12Z  UDS  RX  0x27 0x01                  # SecurityAccess - requestSeed (level 1)
2026-08-10T14:02:12Z  UDS  TX  0x67 0x01 0x3F 0x8A 0x11 0x02
2026-08-10T14:02:12Z  UDS  RX  0x27 0x02 0xDE 0xAD 0xBE 0xEF   # sendKey attempt 1 - INCORRECT
2026-08-10T14:02:12Z  UDS  TX  0x7F 0x27 0x35              # NRC 0x35 invalidKey
2026-08-10T14:02:13Z  UDS  RX  0x27 0x01                  # requestSeed retry, no attempt-counter delay
2026-08-10T14:02:13Z  UDS  TX  0x67 0x01 0x3F 0x8A 0x11 0x02   # SAME seed returned - no re-randomization
2026-08-10T14:02:13Z  UDS  RX  0x27 0x02 0xCA 0xFE 0xBA 0xBE   # sendKey attempt 2 - INCORRECT
2026-08-10T14:02:13Z  UDS  TX  0x7F 0x27 0x35
# ... 8 additional rapid attempts omitted, no lockout/backoff timer observed between attempts 1-10 ...
2026-08-10T14:02:19Z  UDS  RX  0x27 0x02 0x12 0x34 0x56 0x78   # sendKey attempt 11 - ACCEPTED
2026-08-10T14:02:19Z  UDS  TX  0x67 0x02
2026-08-10T14:02:20Z  UDS  RX  0x31 0x01 0xF0 0x0D          # RoutineControl - start routine 0xF00D
2026-08-10T14:02:20Z  UDS  TX  0x71 0x01 0xF0 0x0D 0x00

Related: SYS-TS-10, Section 5.2, ticket SEC-2415.

Appendix C: Pen-test findings

Illustrative example synthesized to match Section 2.2’s threat scenarios. Source: evidence/system/pentest_findings.md.

Appendix D: Static analysis (MISRA-C/CWE mapping)

Illustrative example formatted to resemble typical static-analyzer output. Source: evidence/software/static_analysis_misra_cwe.md.

Appendix E: Dynamic analysis log (sanitizer instrumentation)

Illustrative example, not captured from a real instrumented run. Source: evidence/software/dynamic_analysis_log.log.

==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000014dd0 at pc 0x00000045a3f2 bp 0x7ffd9a1b2340 sp 0x7ffd9a1b2338
WRITE of size 4 at 0x602000014dd0 thread T3 (fusion_worker)
    #0 0x45a3f1 in stitch_compose_row stitch_compose.c:206
    #1 0x459d10 in stitch_compose_frame stitch_compose.c:112
    #2 0x458aa2 in isp_pipeline_process isp_frame_alloc.c:301
    #3 0x457b13 in camera_capture_thread_main camera_driver_init.c:88

0x602000014dd0 is located 16 bytes to the right of 3216-byte region [0x602000014100,0x602000014dc0)
allocated by thread T0 here:
    #0 0x4a1234 in malloc
    #1 0x458200 in isp_frame_alloc isp_frame_alloc.c:145

SUMMARY: AddressSanitizer: heap-buffer-overflow stitch_compose.c:206 in stitch_compose_row

==12345==ERROR: UndefinedBehaviorSanitizer: signed integer overflow: 46080 * 65536 cannot be
represented in type int
    #0 0x45a290 in stitch_compose_frame stitch_compose.c:88

Fuzzed input that triggered both findings: frame header reporting width=1440 height=32, oversized relative to the negotiated camera mode (1280x800). Maps to SW-VC-02, SW-VC-03, SW-VC-11.

Appendix F: Fuzz testing results

Illustrative example formatted to resemble typical coverage-guided fuzzer summaries. Source: evidence/software/fuzzing_results.md.

Appendix G: Crash dump excerpt

Illustrative example, not captured from a real crash/core dump. Source: evidence/software/crash_dump_excerpt.log.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000000045a3f1 in stitch_compose_row (row=32, buf=0x602000014dc0, len=3232)
    at stitch_compose.c:206
#1  0x0000000000459d10 in stitch_compose_frame (frame=0x7ffd9a1b2500)
    at stitch_compose.c:112
#2  0x0000000000458aa2 in isp_pipeline_process (ctx=0x7ffd9a1b2600)
    at isp_frame_alloc.c:301
#3  0x0000000000457b13 in camera_capture_thread_main (arg=0x0)
    at camera_driver_init.c:88

Root cause: heap-buffer-overflow write one row past the allocated stitched-frame buffer, consistent with Appendix E and Appendix D (stitch_compose.c:205/206). Maps to SW-VC-02/SW-VC-11.

Appendix H: Manual code review findings

Illustrative example representative of a typical secure-code-review report. Source: evidence/software/code_review_findings.md.

Appendix I: ML model (perception) integrity verification

Illustrative example, not from a real verification run. Source: evidence/software/ml_model_integrity_check.md.

Illustrative check output for a compliant implementation:

$ model-verify --manifest model_manifest.json --model perception_v3.bin
[INFO] Computing SHA-256 of perception_v3.bin ... 9f2c1a...4de0
[INFO] Manifest expected digest ......... 9f2c1a...4de0   MATCH
[INFO] Verifying X.509 signature chain ... OK (anchored to SMPK/BMPK root)
[INFO] Model version field .............. 3   >=   minimum accepted version 3   OK
[RESULT] perception_v3.bin: PASS

Finding: the current build has no equivalent check in place, a substituted or downgraded model file would be accepted and loaded without detection. Evidentiary basis for SW-VC-05 and SYS-TS-09, and for the signed perception-model artifacts gap called out in Section 5.