Not part of a guided workflow —
Next best move:Open the platform atlas Atlas
Synthetic Red Team demonstration · Northstar Motor Works

This vehicle is green. Its inherited supply-chain cyber history is not.

This vehicle is green. Vehicle appears complete and released.

  • ✓ Production complete
    Plant SC-01 · Line 2 — Final Assembly
  • ✓ Quality released
    Component and vehicle release recorded
  • ✓ Software current
    Gateway firmware CVG-FW-24.8.17
  • ✓ No active vehicle alert
    No vehicle-side detection, no behaviour change
Gateway ECUTelematicsInfotainmentADAS and sensorsV2XOBDIn-vehicle networkFirmwareEmbedded softwareOTA serviceMobile applicationCloud backendAPIsCertificatesOpen-source dependenciesTier 1 manufacturerTier 2 software developerManaged service providerCloud providerBuild environmentCode-signing serviceLogistics providerEngineering support identityPreviously exploited technologySupplier-reported incidentPublic breach or disruptionCredential exposureHistorical vulnerabilityKnown exploited vulnerabilityTrusted-relationship attack patternSoftware-supply-chain precedentUnresolved evidence gapWNMDEMO0000000001
Historical eventHistorical techniqueKnown exploited weaknessCurrent signalSelect a supplier or a marker. Nothing here asserts compromise.
The reveal

This VIN inherited 6 supplier trust relationships. 3 have historically demonstrated attack exposure. 1 intersects a current unresolved condition.

You did not know this

Your systems know this supplier provides the gateway. They do not show that the same trusted support identity can reach the environment that builds its firmware.

  1. 01Northline Embedded SystemsSupplier of record for the gateway release
  2. 02Meridian Technical ServicesSupport provider with approved access
  3. 03Remote identity ID-101Privileged, authorised, active
  4. 04Build environmentProduces the gateway firmware
  5. 05Signed firmware CVG-FW-24.8.17Signature valid
  6. 06ECU lot ECU-LOT-0412Installed on the line
  7. 07WNMDEMO0000000001The selected vehicle

A signature proves who signed the artifact. It does not prove the signing authority or build environment was uncompromised.

NHTSA notes that digital-signature assurance depends on the signing key not being compromised, and recommends tracking software components so affected ECUs and specific vehicles can be identified when vulnerabilities emerge.

Where operational trust is not independently proven.

  • Unproven
    Supplier assertion without corroboration
  • Unproven
    Identity with unclear ownership
  • Unproven
    Release without reproducible build evidence
  • Unproven
    Signature without verified signing-path health
  • Partial
    Software component without VIN-level traceability
  • Unproven
    Sub-tier relationship absent from procurement
  • Unproven
    Known vulnerability without installed-version confirmation
  • Unproven
    Recovery promise without tested capacity
  • Now connected
    Incident history not connected to current operational reach

This supplier was acceptable yesterday. What changed today?

  1. 08:10Supplier posture accepted
  2. 11:42New exploited-vulnerability record ingested
  3. 13:17Product/version match identified
  4. 14:02Exposed service confirmed
  5. 15:26Service linked to privileged supplier identity
  6. 16:04Identity linked to gateway build environment
  7. 16:064,760 VIN reach calculated

The vehicle did not change. Our knowledge of the trust supporting it did.

Scenario A · Attack signalTrusted identity and build path

A Meridian Technical Services identity has a current credential-exposure association and access to the firmware build environment.

Potential reach
4,760 VINs
Decision
Suspend the identity and release path; reproduce the artifact.
Scenario B · Exploitable conditionKnown exploited supplier service

The sample supplier inventory contains a synthetic remote-access product and version modelled as present in a known-exploitation catalogue (fictional identifier NMW-2026-0001).

Potential reach
Supplier operations, build access and quality availability
Decision
Isolate the service, apply mitigation and verify access history.
Scenario C · Trust-evidence failureUnprovable software provenance

Firmware is validly signed, but the supplier submission lacks reproducible-build evidence connecting source, build environment and delivered binary.

Potential reach
2 releases, 3 lots and 4,080 VINs
Decision
Verify artifacts while continuing independently supported production.

Three different problems — an attack signal, an exploitable condition and a trust-evidence failure. They are never combined into one cyber score.

What makes this real for your footprint
  • · Complete supplier hierarchy
  • · Supplier technology inventory
  • · Third-party service providers
  • · Authorized identities
  • · Remote-access services
  • · Privileged-access scope
  • · Build and release environments
  • · Software artifacts and dependencies
  • · SBOM / VEX
  • · Hashes and signing records
  • · Components and lots
  • · VIN genealogy
  • · Current vulnerabilities
  • · Historical incidents
  • · Supplier security notifications
  • · SIEM / XDR / VSOC signals
  • · Known-exploited-vulnerability matches
  • · Recovery and alternate-source evidence

Supplier build provenance unavailable — 4,080 VINs cannot be independently cleared.

What this does and does not claim
  • · Synthetic demonstration. Suppliers, identities, lots, releases and vehicle counts are fictional.
  • · Historical precedent establishes relevance and plausibility — never a detected attack.
  • · No compromise, cause or attribution is asserted; confirmed compromise stays at zero.
  • · Unverified statements remain unverified; absence of evidence is recorded as a finding, not filled in.
  • · Nothing here suspends an identity, holds a release or stops a line — a named human executes every action.

Your existing systems tell you whether the supplier is approved, the component arrived and the vehicle passed inspection. AutoResilience reveals the supplier cyber history, technologies, identities and trust pathways inherited by that vehicle — then determines which historical attacks are relevant now, what they can reach and how to interrupt them without shutting down the operation.

Vehicle under examination: WNMDEMO0000000001 · Plant SC-01 · Line 2 — Final Assembly · opening sequence · 680 vehicles in the next inheritance window.