Industry Research

Appearance

On-Vehicle Supply Chain and Runtime Security Operations ​

Last updated: 2026-05-09

On-vehicle runtime security starts before the vehicle boots. Every deployed binary, container image, model, map, calibration file, configuration bundle, firmware package, and script is a supply-chain artifact. The operational goal is to prove what is running, where it came from, whether it is vulnerable, whether it was authorized for that vehicle and ODD, and whether it has changed at runtime.

Practical Evidence and Artifact Model ​

ArtifactContentsOperational use
Software bill of materialsPackages, libraries, containers, OS image, firmware, model runtime, licenses, hashesCVE triage, supplier review, incident scope
VEX or vulnerability dispositionCVE affected/not affected, exploitability, fix plan, compensating controls, owner, SLAAvoids blind patching and proves triage
Provenance attestationSource repo, commit, builder identity, build recipe, dependencies, timestamp, SLSA levelDetects tampering and unapproved builds
Signature recordArtifact digest, signer identity, signing key/certificate, transparency log or HSM recordEnforces deployment policy
Vehicle deployment manifestVehicle ID, active OS/app/model/map/config/calibration versions, compatible rollback setIncident reconstruction and rollback
Secure boot attestationBootloader, kernel, rootfs hash, dm-verity status, measured boot PCRs, TPM quote if availableProves boot chain integrity
Secrets inventoryCertificates, API tokens, device keys, rotation dates, storage location, revocation pathPrevents fleet lockout and credential sprawl
Runtime integrity reportFile integrity, container digest, process allowlist, kernel module list, debug port stateDetects unauthorized changes
Supplier security fileISO/SAE 21434 interface agreements, SBOM, patch SLA, vulnerability disclosure contactManages third-party risk

The vehicle should report a signed version manifest at startup, after update, and during incident evidence capture. The manifest should include software, firmware, model, map, calibration, and configuration identifiers, not only application version.

Deployment Operations ​

1. Build and release controls ​

  • Use reproducible or hermetic builds where practical.
  • Generate SBOMs for OS images, containers, firmware packages, and application bundles.
  • Sign all artifacts before they enter the release repository.
  • Attach provenance attestations to build outputs.
  • Enforce policy in CI: no unsigned artifacts, no unknown base images, no critical unfixed vulnerabilities without an accepted exception, no secrets in artifacts.
  • Keep source, build, and release duties separated for safety-critical components.

NIST SP 800-218 SSDF provides the secure development process vocabulary. SLSA, in-toto, Sigstore, TUF, and Uptane provide practical mechanisms for provenance, signing, secure update metadata, and automotive-style update resilience.

2. Vehicle install controls ​

On-vehicle update agents should:

  1. Verify transport security and server identity.
  2. Verify signed update metadata and artifact digest.
  3. Verify artifact compatibility with vehicle hardware, ECU, map schema, model runtime, calibration schema, and ODD.
  4. Check anti-rollback rules unless an approved emergency rollback exception is present.
  5. Install atomically to an inactive slot or staging area.
  6. Run first-boot health checks.
  7. Report a signed version manifest.

Uptane's model of primary and secondary ECUs, vehicle manifests, signed metadata, secure time, and rollback/replay resistance is directly relevant even when the fleet is not road-type-approved.

3. Runtime controls ​

ControlVehicle implementation
Secure bootHardware root of trust, locked bootloader, measured boot, dm-verity or equivalent rootfs integrity
Least privilegeNon-root containers, capability drops, read-only filesystems, no privileged debug shells in production
Network segmentationExternal links cannot route directly to CAN, safety PLC, sensor Ethernet, or ROS control topics
Certificate managementTPM/HSM-backed keys, rotation calendar, emergency revocation, overlap period before expiry
Runtime allowlistExpected processes, container digests, kernel modules, listening ports
Secret handlingNo secrets in bags/logs/core dumps; secret scanner in upload pipeline
Local forensic modePreserve logs, manifests, and volatile state before recovery actions

4. Vulnerability operations ​

Fleet CVE triage must be version-aware and vehicle-aware:

  • Ingest CVEs for OS packages, containers, ROS/DDS middleware, CUDA/TensorRT, ML frameworks, web services, OTA clients, and vendor firmware.
  • Join CVEs to SBOMs and active vehicle manifests.
  • Rank by exploitability, exposure, safety impact, compensating controls, and fleet blast radius.
  • Use VEX-style dispositions for "not affected" or "affected but mitigated" decisions.
  • Track patch SLA separately for internet-exposed cloud components, vehicle external interfaces, internal vehicle dependencies, and lab-only tools.

5. Key and certificate operations ​

Expired or compromised credentials can stop a fleet as effectively as a software bug. Maintain:

  • Device certificate inventory with expiry, issuer, vehicle ID, and revocation status.
  • Signing-key ceremony and backup process.
  • Emergency key compromise playbook.
  • Clock-source integrity checks because secure update frameworks depend on time freshness.
  • Rotation drills before certificates approach expiry.

Risks and Failure Modes ​

Failure modeConsequenceControl
Compromised build server signs malicious artifactFleet-wide malicious updateHardened builders, provenance, two-person release, signing key isolation
Unsigned local patch applied during field supportUnknown runtime state and invalid safety evidenceProduction vehicles reject unsigned artifacts; support actions logged
SBOM exists but is not linked to active vehiclesCVE scope cannot be determinedVehicle manifests feed SBOM/CVE join table
Model or map not treated as softwarePoisoned or wrong artifact bypasses signing and rollout controlsUnified artifact policy for code, model, map, config, calibration
Rollback attackVehicle runs known-vulnerable versionUptane/TUF metadata, secure time, anti-rollback counters
Certificate expiryFleet loses telemetry, OTA, or command channelExpiry dashboards, rotation windows, overlap certs
Secrets in logs or bagsCloud or vehicle compromiseSecret scanning and rotation; no secret-bearing env dumps
Container breakoutAttacker reaches host or CAN bridgeNon-privileged containers, AppArmor/SELinux, network segmentation
Debug interfaces left enabledPhysical access compromiseSecure service mode, sealed ports, maintenance authentication
  • 60-safety-validation/cybersecurity/cybersecurity-airside-av.md
  • 50-cloud-fleet/ota/software-update-management-system-ops.md
  • 50-cloud-fleet/ota/ota-fleet-management.md
  • 40-runtime-systems/ml-deployment/production-ml-deployment.md
  • 40-runtime-systems/ros-autoware/ros2-migration.md
  • 50-cloud-fleet/data-governance/fleet-data-privacy-governance.md
  • 60-safety-validation/runtime-assurance/fail-operational-architecture.md

Sources ​

Public research notes collected from public sources.

Copyright © 2026 kvynlim