Pass R155 Buyer Audits Without a Cert: A Supplier Playbook

Updated: August 2025 Who this is for: Swedish Tier-1 and Tier-2 teams that ship software or firmware into vehicles. Goal: Win buyer reviews with clear, repeatable proof.

How buyers run the review

They follow a simple path. You can match it.

1. Scope check. What product, what variants, what change.

2. Evidence scan. Do you have the right files and owners.

3. Deep dive. They trace one risk to code and back.

4. Open findings. They look for known CVEs and past incidents.

5. Decision. Green light, conditional, or rework.

What do buyers check first? A clean evidence index. You will ship that in the next section.

The 12 artifacts that get a "yes"

Ship these in a single folder. Use short names. Keep owners and dates on page 1.

1. Evidence Index (index.md). One line per artifact, owner, link.

2. Product Scope (scope.pdf). HW, SW, networks, data flows, variants.

3. Threat Analysis (tara.pdf). Risks ranked with SFOP and notes.

4. Cybersecurity Goals (goals.xlsx). Linked to hazards and assets.

5. Security Requirements (sec-reqs.xlsx). Trace to goals and tests.

6. Cryptography Register (crypto.xlsx). Algorithms, modes, key sizes, use.

7. Key and Secret Handling (keys.pdf). Generation, storage, rotation, roles.

8. Static Analysis Report (sast.pdf). Ruleset, findings, waivers.

9. Fuzz and Fault-Injection Log (fuzz.xlsx). Targets, hours, crashes, fixes.

10. Third-Party Register (oss.xlsx). License, version, owner, approval.

11. SBOM set (sbom.cdx.json, sbom.spdx.json). Produced on each build.

12. Release Gate Record (gate.pdf). 24 checks, sign-off, rollback proof.

Map the evidence to ISO 21434 parts

• Part 4: Cybersecurity management. Owners, plan, reviews, training.

• Part 5: Project-level plan. Activities per milestone and roles.

• Part 6: Continuous risk management. Intake, triage, and fix loops.

• Part 7: Risk assessment. TARA, assets, impact, attack paths.

• Part 8: Concept. Cybersecurity goals linked to safety and functions.

• Part 9: Product development. Requirements, design, and code controls.

• Part 10: Production and operations. Keys, updates, incident flow.

• Part 11: Incident response. Contacts, SLAs, test of the runbook.

• Part 12: Work products. Index that ties the whole set together.

Mini-TARA example: DC-DC converter (low-voltage side)

Scope

24–96 V input, 12 V output rail, CAN and Ethernet, bootloader, OTA support.

Assets

Firmware image, boot keys, CAN gateway config, charging profile, logs.

Impact scale (SFOP)

• Safety: Loss of steering assist, loss of braking assist, thermal event.

• Financial: Warranty swap, recall risk, downtime.

• Operational: Fleet immobilized, service network load.

• Privacy: VIN and usage data exposed.

Attack paths

• A1: Malicious CAN frames reach converter MCU and switch mode.

• A2: OTA package replay installs an old image with a known bug.

• A3: Debug UART left open in harness enables flash read.

• A4: Ethernet update API takes unsigned images from a local tool.

• A5: Supplier test key leaks and signs a build that reaches staging.

Top risks and controls

• R1: Unsafe mode via CAN. Controls: IDPS on gateway, allowlist at converter, timing checks, HIL tests for abuse frames.

• R2: Image rollback. Controls: Anti-rollback counter, image monotonicity in secure storage, test for forced downgrade.

• R3: Debug readout. Controls: Production fuse set, no-debug build flag, acceptance test reads status and fails on "unlocked".

• R4: Unsigned update. Controls: Boot ROM signature check, public key pinned in immutable store, CI blocks unsigned artifacts.

• R5: Compromised test key. Controls: Separate key ladders for dev and prod, HSM for prod, weekly key usage report to owner.

Residual risk statement

All five risks tracked. R1 and R2 reduced to low. R3 medium on legacy units only. R4 low with measured boot. R5 medium until full HSM rollout in Q4.

Release gate: 24 checks that stop bad builds

Planning

1. Scope and variant list match the build tag.

2. Threat model updated for new code or new data flow.

3. Owners assigned for each control and test.

Code

1. Static analysis clean at target ruleset.

2. Memory-safety checks pass on changed files.

3. Cryptography register updated and reviewed.

Third-party

1. SBOM built.

2. No CVE with score ≥ 7.0 remains open without an approved waiver.

3. License allowlist holds for all packages.

Build

1. Reproducible build proof: checksum match on a clean runner.

2. Signing step runs on an isolated runner with short-lived keys.

3. Build artifact contains version, commit, and build time.

Test

1. Unit tests pass with coverage trend stable or rising.

2. Fuzz target runs for N hours with zero new crashes.

3. Fault-injection test on power and comms passes.

4. Abuse-case HIL tests pass on CAN and Ethernet.

Security review

1. High-risk changes reviewed by a named security owner.

2. Pen test delta assessed or waived with reason.

Operations

1. Rollback path tested from this exact image.

2. Update package monotonicity verified on device.

3. Key-use log reviewed by a second person.

Release record

1. Gate checklist signed with date and name.

2. Known issues listed with owner and due date.

3. Deployment plan with canary steps and stop-loss rule.

SBOM pipeline you can ship

Goal: Produce CycloneDX and SPDX on each build. Keep them with the artifact.

GitHub Actions (CycloneDX with cdxgen)

name: sbom on: push: tags: ["v*"] workflow_dispatch: jobs: cyclonedx: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: "20" - run: npm i -g @cyclonedx/cdxgen - run: cdxgen -r -o sbom.cdx.json - uses: actions/upload-artifact@v4 with: name: sbom-cyclonedx path: sbom.cdx.json

GitHub Actions (SPDX with Syft)

name: spdx on: push: tags: ["v*"] jobs: spdx: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: | curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin syft . -o spdx-json > sbom.spdx.json - uses: actions/upload-artifact@v4 with: name: sbom-spdx path: sbom.spdx.json

Policy: Block a release if either SBOM shows a CVE ≥ 7.0 without an approved waiver.

Copy-ready answers for buyer forms

Q: Do you run a cybersecurity risk process for this product? A: Yes. We run a live TARA linked to requirements and tests. We update it at each change request and at each release gate.

Q: How do you protect cryptographic keys? A: We split dev and prod keys. We store prod keys in an HSM. We log each use and review the log weekly.

Q: Can you roll back an unsafe update? A: Yes. Each update has a tested rollback. We keep the previous image and a recovery path on device.

Q: How do you manage third-party code? A: We build a CycloneDX and an SPDX SBOM on each tag. We run a CVE policy with a 7.0 cut line. We keep license approvals in a register.

Q: Who signs off the release? A: Product, security, and test leads sign the 24-point gate. Names and dates sit in the release record.

Templates to copy

Evidence index (index.md)

# Evidence Index – Project X | Artifact | File | Owner | Date | Link | |----------|------|-------|------|------| | TARA | tara.pdf | A. Svensson | 2025-08-01 | /docs/tara.pdf | | Goals | goals.xlsx | L. Karlsson | 2025-08-01 | /docs/goals.xlsx | | Sec-Reqs | sec-reqs.xlsx | M. Nordin | 2025-08-02 | /docs/sec-reqs.xlsx | | Crypto Register | crypto.xlsx | P. Ahmed | 2025-08-02 | /docs/crypto.xlsx | | SBOM | sbom.cdx.json | Build Bot | 2025-08-03 | /artifacts/sbom.cdx.json | | Release Gate | gate.pdf | B. Nyström | 2025-08-03 | /docs/gate.pdf |

Key and secret handling highlights

• Hardware root for prod keys.

• Short-lived signing certs.

• No long-lived tokens on runners.

• Two-person review on key use.

• Quarterly restore test.

License allowlist sample

MIT, BSD-2, BSD-3, Apache-2.0, MPL-2.0, ISC, Zlib

Buyer trace walk-through

Pick one feature. Show the trace.

• Feature: Thermal limit tweak.

• Risk: Over-current on 12 V rail.

• Goal: Keep current within safe range.

• Requirement: Enforce limit at X A with Y ms response.

• Design: Parameter range, fail-safe path, alarm.

• Code link: Commit hash and file path.

• Test: HIL test case with pass data.

• Result: Pass, no drift from baseline.

This one page often wins the room.

Need help implementing this playbook for your automotive products? Book a consultation to discuss your R155 and ISO 21434 compliance strategy.