Latest / Cybersecurity Under Pressure. Real Attacks, Real Lessons / Automotive Supplier Cybersecurity: When Compliance Drains R&D

Transcript

Automotive Supplier Cybersecurity: When Compliance Drains R&D · Cybersecurity Under Pressure. Real Attacks, Real Lessons

0:47
Welcome to cybersecurity under pressure, real attacks, real
0:50
lessons. Today is Friday, June 26th, 2026
0:54
and I don't know about you, but I am.
0:56
I am very much feeling that Friday exhaustion right now.
0:59
Oh yeah, it has been one of those weeks.
1:01
I can hear it in your voice. Man, I spent literally Monday
1:04
through Thursday trying to implement a relatively standard,
1:07
you know, modern encryption patch on a legacy industrial
1:11
controller system and it just gave up the ghost.
1:14
It completely died. I mean, yes, you triggered a
1:16
hard fault on a legacy chip, didn't you?
1:18
Yes, it didn't even try to process it.
1:19
Like the handshake latency alone from the modern cryptographer.
1:23
It timed out the hardware watchdog and the entire system
1:26
threw its hands up and power cycled.
1:28
It's It is so infuriating you're trying to force contemporary
1:32
computational math onto silicon that was designed back when you
1:35
know flipping a basic logic gate was considered heavy lifting.
1:38
Which, I mean, that perfectly encapsulates the structural
1:42
nightmare of modern engineering right there.
1:45
You're basically trying to bolt a biometric retina scanner onto
1:48
a canvas tent. The the structural integrity of
1:51
the foundation just it just can't support the security
1:54
apparatus you're legally required to install.
1:57
The wire transfer Acaba de publica Al Gore lecionado El
2:02
mismo vector de frente industria.
2:05
They were looking at OT security, remote access, and
2:08
honestly the pain points they highlighted are identical to
2:11
what I just dealt. With Oh, absolutely, the
2:13
underlying physics of the problem don't change just
2:15
because the industry does. Right.
2:17
But that frustration, that physical friction between
2:19
ancient hardware constraints and modern aggressive cyber threats,
2:23
that is exactly what we are unpacking in this deep dive.
2:26
And there is no sector, I mean absolutely nowhere feeling that
2:30
friction more violently right now than the automotive supply
2:33
chain. Exactly.
2:34
So for this deep dive, we're taking a massive stack of source
2:38
material. We've got the Vicone 2026
2:40
Automotive Cybersecurity Report, some really fascinating
2:45
interview studies from the DEVA portal on actual compliance
2:48
implementation, and of course the unvarnished legislative
2:51
texts of Unes R155 and the EU Cyber Resilience Act.
2:56
Light reading for a Friday. Oh yeah, Total Beach reads.
3:00
But our mission today is to synthesize all of this and
3:02
figure out how the automotive supply chain is supposed to
3:05
survive this regulatory avalanche, right without
3:08
grinding innovation to a halt or honestly just faking their
3:11
compliance. Because right now, the modern
3:13
connected vehicle is essentially a massive data center.
3:16
A data center hurtling down a highway at 80 miles an hour,
3:19
which is a terrifying thought. We're talking about platforms
3:21
housing upwards of 100 million lines of code. 100 million.
3:25
I always try to visualize that it's it's more code than a
3:27
commercial airliner. It's more than a modern fighter
3:29
jet, way more. And the chaos multiplier here is
3:33
that this code base isn't compiled by, you know, a single
3:35
cohesive team sitting in a room in Munich or Detroit.
3:38
No, not even close. You're looking at a deeply
3:41
fragmented ecosystem of over 150 distinct suppliers for a single
3:45
vehicle platform. 150, yeah. You've got your tier ones
3:49
providing these massive domain controllers, your tier twos
3:51
providing the RTOS, the real time operating systems, and then
3:55
the tier 3 is supplying these microscopic black box binaries
3:58
that everyone just, well, assumes they're safe.
4:02
It's an amalgamation of proprietary code, commercial off
4:05
the shelf software, and deeply embedded open source libraries.
4:10
Which makes it a spectacularly target rich environment.
4:13
And because we've insisted on connecting every single one of
4:16
these mobile data centers to the cloud, the regulatory bodies
4:19
have finally panicked. I mean, they're dropping this
4:21
absolute alphabet soup of frameworks on engineering
4:24
directors. Alphabet soup is putting it
4:26
mildly. It's a regulatory tsunami.
4:28
Right, and I want to start by tearing apart two of the biggest
4:31
frameworks that are currently just suffocating security teams.
4:34
Tysacs are nice to say 2434 because I hear people conflating
4:38
these constantly. They throw them into the same
4:39
generic compliance bucket, but mechanically they are solving
4:43
entirely different vectors. Confusing them is a phenomenally
4:46
expensive mistake, too. The easiest way to conceptualize
4:49
the difference is that TYSACS is an enterprise risk framework,
4:52
whereas ISO 21434 is an engineering life cycle
4:56
framework. So TYSACS Trusted Information
4:59
Security Assessment Exchange is fundamentally about walling off
5:02
the corporate organization. Right.
5:03
It's basically ISO 27 sour one on steroids, custom tailored for
5:08
the European automotive supply chain.
5:10
Pretty much, yeah. It's managed by the ENX
5:12
Association. Think about the intellectual
5:14
property at stake here. If an OEM shares the unreleased
5:18
CAD drawings for a 2028 EV platform, or raw telemetry data
5:24
from customer fleets with a Tier 1 supplier, the OEM needs an
5:28
ironclad guarantee that the Tier one's corporate network isn't
5:30
going to be completely compromised by some ransomware
5:33
syndicate. So they need AL 3 assessment
5:35
Level 3 for that high protection data.
5:37
Exactly. Tizacs mandates secure corporate
5:39
networks, stringent identity access management, even physical
5:42
security. Like making sure someone can't
5:44
just walk into the R&D facility with a USB drive and walk out
5:47
with the breaking algorithms. OK, so Ty Sax is guarding the
5:50
perimeter of the factory and the IT servers, putting a giant
5:54
padlock on the corporate doors, but ISO 21434 is guarding the
5:58
actual metal and code rolling off the assembly line, making
6:01
sure the product doesn't explode in the customer's face.
6:04
Precise what? It goes far deeper than just
6:07
guarding it. ISO 21434 dictates that
6:10
cybersecurity must be fundamentally woven into the DNA
6:13
of the vehicle from the concept phase all the way through
6:16
decommissioning. The whole V model of
6:17
engineering. Right.
6:18
It introduces the Terra process threat analysis and risk
6:21
assessment. It mandates secure coding
6:23
guidelines, vulnerability management, continuous
6:25
monitoring. If TYSAX prevents a threat actor
6:28
from stealing the blueprints for a braking controller off an IT
6:30
server, ISO 21434 prevents a threat actor from injecting
6:34
malicious CAN bus frames to disable those physical brakes
6:37
while the vehicle's actually in motion.
6:39
OK, I understand the theoretical boundary there.
6:41
IT protects the blueprints. Engineering protects the brakes.
6:45
But I'm going to push back on how this is actually implemented
6:47
in the real world. Shouldn't these be completely
6:50
siloed? I mean, the skill set required
6:52
to configure a firewall for a corporate HR server is wildly
6:56
different from the skill set required to analyze the attack
6:58
surface of a deterministic real time operating system running on
7:02
a microcontroller. You'd think so, and
7:04
traditionally, yes, that's exactly how companies are
7:06
treated them. IT sits in one building sweating
7:08
over TI sex, and the embedded engineers sit in a basement
7:11
somewhere sweating over 2 once 4324.
7:15
But siloing them is exactly what's causing the current
7:17
operational breakdown. We are seeing massive audit
7:21
fatigue because of duplicated efforts.
7:23
Duplicated how? Like paying for the same thing
7:25
twice. Basically, look at the overlap
7:28
and foundational governance. Both frameworks require a
7:31
baseline of identity and access management.
7:34
Both require incident response capabilities.
7:37
If you silo them, your supplier ends up paying two different
7:41
audit firms to review essentially the same core
7:44
organizational competencies, just framed slightly
7:47
differently. That sounds like a great deal.
7:49
For the auditors, oh, it's incredibly lucrative for the
7:51
consultants. But more importantly, from a
7:53
security standpoint, the technical barrier between IT and
7:56
OT, between the enterprise network and the vehicle is
7:59
disintegrating. The SolarWinds attack taught us
8:01
that. Supply chain poisoning.
8:04
Exactly, if your cororate IT network is weak, meaning you
8:07
failed Tyfax, an attacker can pivot laterally from an hour
8:11
server, comromised an engineer's workstation and inject the back
8:15
door into the firmware build pipeline.
8:17
The firmware gets cryptographically signed because
8:19
the build server trust the engineer's workstation and boom,
8:22
you just pushed a compromised OTA update to a million
8:24
vehicles. That is a 21434 engineering
8:28
failure that was directly caused by a tizaks IT vulnerability.
8:33
You cannot silo these domains anymore because the attackers
8:35
certainly aren't siloing their attack paths.
8:37
That makes a terrifying amount of sense.
8:39
The corporate network is really just the staging ground for the
8:42
vehicular payload. And this complete blurring of
8:45
lines brings us to the massive regulatory hammer that just
8:48
dropped. Because prior to 2024, ISO 21434
8:52
was just, you know, a really good idea.
8:54
It was a standard, but UNES R155 turned it into the law.
8:58
It did, and the industry is still reeling from that July
9:01
2024 enforcement deadline. R 155 is a mandatory type
9:05
approval requirement across 64 countries, the EU, Japan, South
9:09
Korea, the UK. If you want to sell a vehicle in
9:11
these markets, compliance is a hard non negotiable free
9:14
condition. You literally cannot sell the
9:15
car and R155 operates on 2 distinct pillars.
9:18
The CSMS and the type approval, right?
9:20
Right. Pillar one is the Cybersecurity
9:22
Management System, or CSMS. This is the overarching
9:26
organizational certification. It proves the manufacturer has
9:30
the actual governance, risk management frameworks and
9:32
incident response structures in place across their entire
9:35
operation. And that certificate is valid
9:38
for a maximum of three years. And you can't even touch pillar
9:41
2 without passing pillar one. You absolutely can't.
9:44
Pillar 2 is the vehicle type approval.
9:47
This is the highly specific product level assessment where
9:50
you prove that for this exact vehicle architecture, say the
9:53
2027 model year of a specific EV platform, you have meticulously
9:59
identified the risks, implemented the mitigations and
10:01
validated the security controls. And this is where the dynamic
10:04
between the OEM's and the lower tier suppliers gets incredibly.
10:07
Toxic. Oh, it's brutal.
10:09
The OEM's, the big brands whose badges are actually on the
10:12
steering wheel, they hold the ultimate legal liability for
10:15
that type of approval. If the car gets hacked, it's
10:18
their brand on the front page of the Wall Street Journal.
10:21
But they don't write all 100 million lines of code, so their
10:24
reaction is to just contractually outsource their
10:26
compliance anxiety down the chain.
10:28
Outsourcing compliance anxiety is a brilliant way to phrase it
10:32
because that's exactly what it is.
10:33
The OEM's need a mountain of evidence to hand to the type of
10:37
approval authorities, so they turn to their tier ones and
10:40
demand full terror documentation and a compliance CSMS. The tier
10:45
ones panic, spin around and demand the exact same thing from
10:49
the tier twos and tier threes. I was reading through the Diva
10:51
portal interviews from the source material and there was
10:53
this one anecdote that genuinely raised my blood pressure.
10:57
A Tier 2 supplier, A relatively small company making basic
11:00
electronic subcomponents, was forced by an OEM to prove
11:03
compliance. They ended up spending €80,000
11:06
on external consultants just to generate the necessary
11:09
documentation. It's just for the paperwork.
11:11
It's for the paperwork, and the interviewee explicitly noted
11:14
that their actual technical cyber security posture didn't
11:17
improve by a single cent. They bought an €80,000 PDF.
11:21
The €80,000 PDF It's the darkest reality of these regulatory
11:25
frameworks. When you apply massive pressure
11:28
to a supply chain without providing the necessary tooling
11:31
or standardized methodologies, you don't get better
11:33
engineering, You get a cottage industry of consultants
11:36
generating paper compliance. But breakdown the mechanics of
11:39
why that happens. If I'm a Tier 2 right and I'm
11:42
legally forced to conduct a threat analysis and risk
11:44
assessment under ISO 21434, shouldn't that inherently force
11:48
me to look at my code and fix the bugs?
11:51
How do you spend 80 grand and not fix anything?
11:53
Because of how risk assessment frameworks are mathematically
11:56
manipulated. So NX5 of the R155 regulation
12:00
lists 69 specific attack vectors, everything from
12:03
spoofing messages on the internal communication channels
12:06
to manipulating over the air update packages.
12:08
OK, tracking so far 69 vectors. The Tier 2 supplier hires a
12:12
consultant. The consultant build a massive
12:15
excel spreadsheet mapping the suppliers tiny component against
12:19
those 69 vectors. Now to determine if a
12:22
vulnerability requires actual engineering mitigation, you have
12:25
to calculate its risk value, which is usually a combination
12:28
of attack feasibility. How hard is to pull off an
12:31
impact? Risk matrix.
12:33
Exactly. But if the Tier 2 lacks the
12:36
budget or the hardware capability to actually implement
12:39
strong encryption on their ancient microcontroller, the
12:42
consultant will simply argue in the documentation that the
12:45
attack feasibility is incredibly low because quote UN quote the
12:49
component is deeply embedded and theoretically inaccessible from
12:52
the outside world. So they just mathematically
12:55
massage the risk score down to an acceptable level.
12:58
They just say, well it's fine that this component uses
12:59
plaintext communication because a hacker would need physical
13:02
access to the wiring harness under the passenger seat.
13:05
Exactly. They document the accepted risk,
13:07
generate a 400 page terror report, hand it to the tier one,
13:11
who hands it to the OEM, who hands it to the regulator.
13:14
Everyone's legal liability is covered.
13:16
The €80,000 was spent entirely on legal friction, while the
13:20
underlying hardware remains fundamentally insecure.
13:22
Which completely ignores how modern threat actors actually
13:25
operate. I mean, they don't need physical
13:28
access to the wiring harness. They pivot remotely.
13:31
And the data we have from the Vicone 2026 report shows that
13:34
this paper compliance illusion is shattering in real time.
13:38
The Vicode data is genuinely sobering.
13:40
It proves that the era of isolated domain specific attacks
13:44
is over. Hackers aren't just trying to,
13:46
you know, clone a key fob anymore to steal a car from a
13:48
driveway. They are executing complex multi
13:50
stage kill chains that span enterprise IT, off board cloud
13:54
infrastructure and the in vehicle network simultaneously.
13:57
Let's unpack the mechanics of that because the Vacone report
14:00
highlighted A statistic that I just couldn't stop thinking
14:03
about. 33% of cyber risk now directly impacts the driver
14:07
experience. The attackers are moving out of
14:09
the deep invisible back end systems and explicitly targeting
14:13
the user facing integration layers.
14:15
How are they physically pivoting from an external connection to
14:19
something that affects the driver in the cabin?
14:21
It comes down to the architecture of the modern
14:24
software defined vehicle. To save money and wait, OEMs are
14:27
consolidating dozens of distinct electronic control units into
14:31
single massive domain controllers.
14:34
So you might have the Android Automotive OS which handles your
14:37
Spotify, your navigation, your Bluetooth running on the exact
14:40
same physical silicon as the real time operating system that
14:44
monitors the vehicles telemetry. But they are isolated right by a
14:47
hypervisor, like a virtual machine setup.
14:49
Theoretically, yes. A hypervisor is supposed to
14:52
create an impenetrable virtual wall between the infotainment OS
14:57
and the critical deterministic systems.
14:59
But hypervisors are just software.
15:02
They have vulnerabilities. A sophisticated attacker will
15:05
compromise a third party companion app on your phone, use
15:08
that to exploit a Bluetooth stack vulnerability to gain root
15:11
access to the infotainment system, and then execute a
15:14
hypervisor escape. Meaning they punch a hole
15:17
through the virtual wall. They find a shared memory buffer
15:19
or a misconfigured virtual switch, and suddenly they're
15:22
dropping malicious payloads directly onto the CAN bus, which
15:26
controls the physical steering and braking.
15:28
That's where the driver experience is being impacted.
15:31
The infotainment system is the most accessible attack surface,
15:34
and the hypervisor boundaries are proving porous.
15:36
And the sheer volume of these vulnerabilities is staggering.
15:39
The report cited 174 zero day vulnerabilities uncovered at
15:44
Ping to own Automotive just since 20241. 174.
15:48
And a zero day means there is no patch.
15:50
The manufacturer doesn't even know it exists until the
15:52
researchers exploit it live on stage.
15:55
Which completely invalidates those €80,000 static Taurus
15:59
spreadsheets. We were just talking about a
16:01
static risk assessment assumes a static threat landscape.
16:04
But when you have almost 200 zero days dropping in a two year
16:07
window, your threat landscape is highly dynamic.
16:10
If your security Proctor is based on the assumption that a
16:13
specific hypervisor wall is impenetrable, and a zero day
16:17
renders that wall useless, your entire risk calculus collapses
16:21
overnight. And this ties directly back to
16:23
my hardware failure earlier this week.
16:24
It's the problem of structural risk and legacy silicon.
16:28
Car life cycles are incredibly long.
16:30
If you buy a vehicle today, it's going to be on the road for 10,
16:33
maybe 15 years easily. If an OEM discovers a critical
16:37
cryptographic flaw in a powertrain controller three
16:40
years from now, how do they fix it if the silicon physically
16:43
cannot process a heavier encryption algorithm?
16:45
They often can't. That was a major theme in those
16:48
Diva Portal interviews. Engineers explicitly admitted
16:51
they face brutal performance versus security trade-offs every
16:54
single day. Older components simply were
16:57
designed with cybersecurity overhead in mind.
16:59
If you try to force an RSA 2048 encryption key exchange on a
17:03
chip designed to manage windshield wipers, the processor
17:07
loads, spikes to 100%, the timing requirements fail, and
17:11
the wipers stop working. This system crashes just like my
17:14
legacy controller. It timed out the watchdog.
17:16
So what do they do? They can't just sell a car
17:18
without windshield wipers. They degrade the security.
17:20
They use shorter, weaker encryption keys, or they
17:23
abandoned encryption altogether and just rely on a basic
17:25
checksum for message integrity. They accept the structural risk
17:29
because the alternative is a nonfunctional vehicle.
17:32
Because automotive architectures carry forward across multiple
17:34
vehicle generations to save R&D costs, that compromised legacy
17:39
component might end up in the 2028 model year simply because
17:42
reengineering it from scratch is too expensive.
17:45
Wow, so you have a supply chain drowning in R155 compliance
17:49
faking Teras for legacy hardware that can't actually handle
17:53
modern cryptography while attackers are chaining 0 days
17:56
through infotainment hypervisors.
17:58
It really is. And just when you think the
18:00
regulatory environment couldn't get any more complex, the
18:03
European Union decides to flip the table entirely.
18:06
Let's talk about the CRA, the Cyber Resilience Act, because I
18:09
know engineering directors are losing sleep over this.
18:11
One, the CRA is the ultimate wild card.
18:14
If R155 was a targeted strike on the automotive sector, the CRA
18:19
is a carpet bombing of the entire digital ecosystem.
18:23
It is a horizontal piece of legislation that applies to,
18:25
fundamentally, any product with digital elements placed on the
18:29
EU market. But here is the massive point of
18:31
confusion I see everywhere. I don't want to clear this up
18:34
for you, the listener right now. Aren't cars exempt?
18:37
I keep seeing executives breathing a sigh of relief on
18:39
LinkedIn because they think type approved vehicles get a free
18:42
pass under the general safety regulation.
18:45
That is a highly dangerous misinterpretation of the text.
18:48
Yes, the fully assembled type approved vehicle itself is
18:52
technically exempt from the CRA because it's already governed by
18:55
R155, but the CRA applies to almost everything surrounding
18:59
it. We're talking about aftermarket
19:00
components, retrofit modules, standalone ECU's sold directly
19:04
to consumers, connected mobile companion apps, and critically,
19:08
EV charging infrastructure. Hold on, let me trace that
19:10
logic. So if I am a Tier 1 supplier,
19:12
right, and I manufacture A telematics gateway, if I sell
19:15
that exact gateway directly to BMW to install in the assembly
19:18
line in Munich, that gateway is covered under BMW's R155
19:22
umbrella, correct? But if I take that exact same
19:25
telematics gateway, put it in a cardboard box and sell it on the
19:27
aftermarket as a replacement part.
19:29
So actually I'm fully bound by the CRA for the exact same
19:32
hardware. That is exactly how it works.
19:34
You have dual compliance scenarios for the exact same
19:37
piece of silicon, and the CRA has real teeth.
19:41
It requires a formal CE marking, elevating cybersecurity to a
19:44
fundamental safety requirement for market access.
19:47
If you fail to comply, market surveillance authorities can
19:50
force a total product recall across the entire EU and they
19:53
can levy fines up to €15 million, or 2.5% of your global
19:57
turnover, whichever is higher. That is existential threat
20:00
territory. You could go bankrupt and full
20:02
compliance is mandatory by December 2027.
20:05
So what is the CRA actually demanding that makes it so much
20:08
more terrifying than R155? The mandate that is keeping the
20:11
entire industry awake at night is the mandatory machine
20:14
readable software bill materials.
20:16
Yes, beyond. OK, let's dissect the ESPA mom,
20:20
because the concept sounds deceptively simple to an
20:22
outsider. It's an ingredient list, right?
20:25
The government is finally demanding that software vendors
20:27
print the nutritional label on the back of the box.
20:29
This product contains 10% proprietary code, 40% open
20:33
source Linux kernel, and 50% mysterious third party
20:37
libraries. Why is an ingredient list
20:40
causing such a panic? Because to continue your
20:43
analogy, you were trying to reverse engineer a fully baked
20:46
wedding cake back into its original flour, sugar, and eggs.
20:50
But the flour was milled in a factory that went bankrupt five
20:53
years ago, and the eggs came from an open source farm that no
20:56
one monitors. That is brilliant and
20:59
horrifying. The CRA explicitly requires
21:02
manufacturers to identify and document every single software
21:05
component, including transient dependencies, meaning the
21:08
libraries that your libraries rely on.
21:10
In a standardized machine readable format like SPDX or
21:13
Cyclone DX, the philosophy is that you cannot secure what you
21:16
cannot see. Which makes total sense from a
21:18
security standpoint. I mean if another log 4 J
21:21
vulnerability drops on a Friday afternoon, a company needs to
21:24
query a database and know instantly if their fleet is
21:27
exposed. They can't spend 3 weeks
21:29
emailing tier 3 suppliers asking hey did you use this logging
21:32
library in 2021? But the market research shows a
21:35
massive automotive S bomb gap, doesn't it?
21:39
The gap is structural. By some estimates, fewer than
21:42
30% of Tier 2 and Tier 3 suppliers have implemented
21:44
automated SPM generation workflows.
21:47
When an OEM asks a small supplier for an S bomb today,
21:50
they don't get a machine readable SPDX file.
21:53
They get a manually tugged PDF that was updated six months ago
21:56
by an intern. And it gets even worse when you
21:58
deal with legacy binaries, right?
21:59
What happens when an OEM has, say, an AUTOSAR component that
22:03
was compiled by a supplier in 2020?
22:05
The supplier went out of business during the pandemic,
22:07
and all the OEM has is the compiled stripped binary file.
22:10
There is no source code to look at.
22:12
That scenario requires what the the industry deeply dreads.
22:15
They call it component archaeology.
22:18
Component archaeology. That sounds like a tremendously
22:21
expensive use of compute power. How do you extract an ingredient
22:26
list from a strict binary? You have to utilize Advanced
22:28
Software Composition Analysis or SCA specifically designed for
22:33
binary analysis and it is highly complex.
22:36
Since the human readable source code is gone, the SCA tool has
22:40
to disassemble the machine code, generate control flow graphs and
22:43
look for specific bytecode signatures or structural
22:46
patterns. It then compares those patterns
22:48
against massive databases of known open source libraries.
22:51
So it's basically pattern matching the compiled
22:53
architecture to guess what the original library was.
22:56
Essentially, yes. And it's incredibly difficult on
22:59
embedded automotive architectures like ARM Cortex M
23:02
because the the compilers aggressively optimized the code
23:05
to save space on those tiny chips.
23:06
They strip out all the metadata at the inline, the functions,
23:09
and they completely mutate the structure.
23:10
So the SCA tool might flag a cluster of code and say, well
23:13
we're 85% confident this is a vulnerable version of Open S.
23:16
SSL 85% confident, which means a human engineer still have to go
23:20
in, look at the disassembly and manually verify it.
23:24
And you have to do this for 100 million lines of code.
23:26
Exactly, and the CRA makes this transparency non negotiable.
23:30
If a market surveillance authority sends you a recent
23:32
request, you must produce that ESPIMO.
23:35
The burden of proof has entirely shifted from the regulator
23:38
finding a flaw to you proving you know every line of code in
23:42
your product. So let's pull all of these
23:44
threads together for you listening right now because
23:46
we've mapped out a genuinely brutal landscape.
23:48
We have Tysacs and 21434 operating these massive
23:52
inefficient silos. We have OEMs crushing Tier 2
23:55
suppliers with R155 paperwork that doesn't actually secure the
23:58
legacy hardware. We have multi stage attacks
24:01
pivoting through infotainment hypervisors.
24:03
And now the CRA is demanding machine readable component
24:06
archaeology by 2027. How does a supplier survive this
24:10
without their margins completely collapsing under the weight of
24:12
compliance? Survival requires A fundamental
24:15
shift in strategy. You have to harmonize the chaos
24:17
through automation. You have to stop treating
24:19
TYSACS, R155 and the CRA as separate, isolated regulatory
24:24
hurdles. OK, but how does that actually
24:27
manifest in a company's workflow?
24:29
It's easy to say harmonize, but what does the engineering team
24:31
actually do? It starts at the governance
24:33
level. If you properly implement the
24:35
CSMS required by ISO 21434, you shouldn't just be doing it for
24:39
the vehicle. You use that exact same
24:42
governance structure to capture the risk assessments needed for
24:45
R155 and to establish the secure by design evidence mandated by
24:49
the CRA. You map the controls, the access
24:52
management policies you implement for Tysex to secure
24:55
your HR servers. Those should be extended to
24:57
secure your firmware build pipelines.
24:59
You build the evidence once and you route it to the specific
25:02
regulatory audits. Merging the silos.
25:04
That solves the organizational overlap, but what about the
25:07
technical burden? How does a Tier 2 supplier solve
25:10
the SBM gap without hiring an army of reverse engineers?
25:13
You have to shift left and automate the generation.
25:17
The days of treating an S BOM as an audit artifact you generate
25:20
at the end of a project are over.
25:22
It has to become an engineering artifact.
25:24
You integrate automated software composition analysis directly
25:27
into your CICD pipeline. Every single time a developer
25:30
commits a new line of code or updates a third party library,
25:34
the pipeline automatically compiles the code, runs the
25:36
analysis, and dynamically updates the Cyclone DX file.
25:40
So the ingredient list is always perfectly synchronized with the
25:43
current. Build exactly, and then you plug
25:45
that dynamic S BOM into an automated thread, the
25:47
intelligence feed. Instead of a security analyst
25:49
manually reading CDE reports on Twitter, the system continuously
25:53
cross references new vulnerability disclosures
25:56
against your Live S bomb. If a new zero day drops that
25:59
affects the specific Bluetooth library, the system instantly
26:03
flags exactly which vehicle platforms and which specific
26:05
firmware versions are utilizing that library.
26:08
That moves you away from static paper compliance, the €80,000
26:11
PDF and into continuous monitoring, which realistically
26:15
is the only way to manage a 15 year vehicle life cycle.
26:18
The continuous monitoring is useless if you can't actually
26:22
deploy the fix. Which brings us to the critical
26:25
dependency over the air updates OTA.
26:28
OTA is the absolute lifeline of modern vehicle security.
26:32
R155 and the CRA both implicitly demand it because they require
26:36
vulnerability remediation throughout the product life
26:39
cycle if you detect a flaw. You cannot ask 2 million
26:42
customers to drive to a dealership to flash a module via
26:45
the OBD 2 port. The logistics are impossible.
26:48
You need secure OTA. But OTA is an incredible attack
26:51
vector in itself. I mean, if I'm an attacker, I
26:53
don't want to hack one car, I want to hack the update server
26:55
and push a malicious firmware payload to the entire global
26:57
fleet. Which is why the OTA
27:00
infrastructure must be fortified with multiple layers of
27:03
cryptographic trust. You need hardware trust anchors
27:06
in the vehicle verifying the cryptographic signature of the
27:09
update package before it even unpacks it.
27:11
You need AB partition updates so if the new firmware fails or is
27:14
corrupted, the vehicle seamlessly rolls back to the
27:16
known good state without breaking the car.
27:19
And yet, as sophisticated as that sounds, I can't shake this
27:22
feeling that we are entirely missing the broader physical
27:25
risk. We spend all this time worrying
27:27
about data privacy and individual vehicle safety, but
27:30
there's a macro level threat here that I want you to think
27:32
about. We touched on EV charging
27:35
infrastructure being pulled into the CRA earlier.
27:38
Yes, the charging ecosystem is highly vulnerable.
27:41
It's a massive blind spot. Think about the ISO 15118
27:45
protocol, the plug and charge communication standard between
27:49
the bar in the grid. If an attacker leverages one of
27:52
these hypervisor 0 days we talked about to build a botnet
27:56
of let's say 250,000 compromised electric vehicles, they don't
28:01
mess with the brakes, they don't steal user data.
28:04
They just wait until a peak load event, say a massive heat wave
28:07
in California, and they trigger all 250,000 vehicles to
28:11
negotiate maximum rapid charging draw from the grid
28:14
simultaneously. Oh wow, a coordinated high
28:17
wattage demand spike. Exactly.
28:19
The local Transformers physically melt.
28:21
You destabilize the regional power grid not by hacking the
28:24
utility company, but by weaponizing the automotive
28:27
supply chain. The vehicle isn't just a data
28:29
center anymore, it's a grid attached high voltage appliance.
28:31
If our compliance regimes are just generating €80,000 PDFs
28:35
instead of actually hardening the code, we are leaving
28:38
critical national infrastructure entirely exposed.
28:41
That is the ultimate consequence of the overlap era.
28:44
The attack surface isn't just the car anymore, it's the entire
28:47
ecosystem, and an illusion of security built on static
28:52
paperwork and siloed audits is far more dangerous than knowing
28:55
you are vulnerable. It really is a staggering amount
28:58
of responsibility sitting on the shoulders of embedded engineers
29:01
right now. They aren't just protecting
29:02
blueprints or stopping cars from crashing, they are literally
29:05
defending the stability of the grid.
29:08
It's monumental, but by dismantling those silos,
29:12
embracing automated S bombs, and moving toward continuous
29:15
hardware backed resilience is a fight the industry can win.
29:18
We just have to evolve past the paperwork.
29:20
Well, on that note, I think we both need another coffee before
29:23
dealing with any more legacy silicon today.
29:25
That's all for this episode of cybersecurity under pressure,
29:27
real attacks, real lessons. Check your PLCS, check your
29:30
logs, and maybe, just maybe question whether that air gap is
29:33
really an air gap when your car is downloading an OTA update on
29:36
the highway. Stay secure out there.