Semiconductor Insiders - Podcast EP350: The Growing Threat of Hardware Security Breaches and What to do About it with Dr. Andreas Kuehlmann

Episode Date: June 12, 2026

Daniel is joined by Dr. Andreas Kuehlmann, General Manager of Security Solutions at Arteris. He has over 35 years of experience in semiconductor design, software, and cybersecurity, including roles at IBM Research, UC Berkeley, Cadence, and Synopsys. Previously, he was CEO of Cycuity, which was acquired by Arteris. Dan explores… Read More

Hello, my name is Daniel Nenny, founder of Semaywiki, the Open Forum for Semiconductor Professionals. Welcome to the Semiconductor Insiders podcast series. My guest today is Dr. Andreas Coleman, General Manager of Security Solutions at Arteris. He has over 35 years of experience in semiconductor design, software, and cybersecurity, including roles at IBM Research, UC Berkeley, Cadence, and Synopsis. Previously, he was CEO of Security, which was acquired by a cybersecurity, including. Arteris. Welcome back to the podcast, Andreas. Thank you, Dan, for having me. It's a pleasure. So what changed recently that made the cybersecurity industry take frontier AI seriously?

I think the big news is really that Cloud Mythos and GPD 5.5 cyber, they really shocked the world and there's a lot written about it. Mythos found hundreds of zero-day vulnerabilities across major software platforms. including things like the Firefox web browser, Linux kernel components, cryptographic libraries, and even some of the smartphone and firmware chains. And that you have to keep this in mind. I mean, that despite a pretty mature application security industry that over the last 20 years provided lots of products, you know, things like SaaS, DASD fuzzing that has been used to make sure that we minimize

the number of vulnerabilities that remain in software. And this has really caused Mythos and GPT 5.5 to delay the public release, and it's only provided access to selected entities to give them a chance to fix any issue sentence going forward. My gut feeling is every frontier AI model going forward will probably go through some similar, you know, responsible disclosure process. Wow. How scary is that? It's an opportunity and it's a challenge, right? I mean, think about it, just a couple of weeks ago. There was some news that mythos broke on Apple's memory defense of the M5 chips in just a few days. And this on the background where Apple is very proud of their system security and put a lot of effort into this particular feature over the last years.

Why hasn't AI had the same breakthrough impact on hardware security yet? See, that's what everybody was guessing. Why is it not happening on hardware yet? And I want to emphasize the yet. I see three reasons, right? Number one, software security had really decades to mature. I mean, you have established best practices. NBD, the national vulnerability database, CWE, common weakness enumeration, CVE and CVE and common vulnerabilities and exposure. These all databases. that have been developed over many years. Then the application security industry, as I mentioned earlier, is 20 years old. And it's really delivered tools for software development that has been adopted very broadly.

And hardware in comparison, hardware security is relatively young. I think the whole wake-up call came with a spectre on melton in 2018. And suddenly everybody woke up, right? And so my outfit's not as secure. thought. I think the second reason is availability, and that's probably very big reason, availability of open source training data that is dramatically smaller for hardware. And software, we have millions of projects in open source. For example, just on GitHub has 400 million public repositories from which any model can learn from.

Open source hardware is tiny in comparison. Open course. There's just under 900 designs. You know, we have a few risk-five open-source designs and a few more. So there's really not a lot to learn from the AI models, the same way as you can learn for open-source software. And the third one is the open-source hardware usage is very different. Open source software is deployed in millions of software products. Today, I mean, there's some analysis done. You know, any soft product today on average, you know, has more than 90% of open source components.

So pretty much today, when you develop a web application, you know, you just stitch together a bunch of open source components and put some glue logic in between. I mean, that's really it's. Open source hardware is very differently used. It's mostly applied in research only, whereas production ships are developed, you know, mostly really internally. They often use third-party IP components, but these are commercial IP components which are not open source. Can open source hardware become as dominant as open source software? Then people have been dreaming about this for as long as I can think about, right? I don't think so in practice. I think for two reasons. The economics are very different.

And secondly, the IP protection is also very different. So I think they're not giving up, but so far we haven't seen it. And what science suggests hardware security could become the next major AI battleground? As I said before, Dan, I think before Spectrum Melt-on, I think we all assumed that hardware was inherently safe. Safe than Safegov, right? That has really changed 2018. And the big news was Spectrum Melt-on, hitting Intel, you know, AMD, you know, Arm and any, you know, modern processor design. But since then, there were many vulnerabilities found. So if you look at the

history of the CVEs that show really voluntarily disclosure of security issues on the hardware world, these CVEs have dramatically grown since. Yet, on the other hand, there's a damper in that. The damper is that finding hardware vulnerabilities is and has been extremely labor intense. I mean, that's been done with researchers. Sometimes you get a bit of PhD, finding a vulnerability in the chip that is very common. You have to do reading lots of papers, you know, researching all the CVEs, CWs, you know, analyze their research from chip companies, so and so on. But if you think about it, AI is very good at all this. It can really study everything that's publicly available and make the discovery process much more efficient.

Anything else that AI can offer here? I think one thing I find, particularly interesting is that AI is not biased. So it can essentially combine views, approaches from various viewpoints that humans often, you know, do not think about. I wanna give an example, I mean, open AI just a few days ago, a week ago, disprove the common conjecture of one of Erich math problems,

the 80-year-old planar unit distance problem. The success of disproving was really attributed to, you know, looking at the problem differently, looking at this out of the box. Most mathematicians were trying to prove the conjecture. It was, you know, opening, I essentially said, no, let's try it, you know, let's try it differently, right? I think the same can potentially apply in defeating cyber defenses, right? Just thinking out of the box. So that makes it, I think, particularly interesting, dangerous, or, you know, whatever we call this. How could AI actually discover or exploit hardware vulnerabilities in practice? I think, Dan, this will likely be very different than software.

And here are three possible components that I can see. Number one, I mean, as I mentioned, AI models can absorb an enormous amount of public knowledge. I mean, think about academic papers on hardware security patents, hardware vulnerability databases, open source chip designs, firmware documentation, and prior attack research. That's a tremendous amount of knowledge that is in the world out there. But in particular, I believe, on the hardware side, AI could generalize design patterns from the open source

and then extend the two possible security weaknesses as candidates for trying attacks. The second component, AI can drastically accelerate the tedious work on that I mentioned earlier, right? So we're stitching things together, you know, which paper fits on what architecture, you know, can I stitch it together with some software attacks and all of this, right? And the third one is, and that's particularly interesting, is, AI can automate the synthesis and execution of life attacks on connected systems. can do this massively parallel and think about also, you know, whenever it makes a little bit progress,

it got a little bit further into the system from every partial success it can learn and use this partial success pattern to a next step get a little bit further. There's a good comparison. You may remember AlphaGo from deep mind. It trained itself on go by a massively. utilizing reinforcement learning from a zillion games. And as a result, it defeated the world champion in 2015. That was a tremendous wake-up call for the world to take AI seriously. And I think cyber attacks are just very similar.

They're really just a game against the system that has vulnerabilities and that, you know, you try to protect. I think what's particularly concerning, or particularly we need to pay attention to the possibility of blended attacks, where you know, you combine software vulnerabilities with hardware vulnerabilities and chain them together into complex, you know, attack scenario. Think about, you know, you use some software vulnerability to get into the system, then you use some hardware vulnerability to dig into the hardware, you get into some, for example, data or some memory regions that are supposed to be protected, And you use, again, a software vulnerability to get this out of the system.

So the possibilities here are huge. And my expectation is we need to really prepare for that as soon as possible. So why are hardware vulnerabilities fundamentally harder to respond to than software vulnerabilities? So they're fundamentally harder to respond to because software can easily be patched and software vulnerabilities can be, or patches for software vulnerabilities can be distributed fairly quickly. Hardware is very different. You cannot easily patch it. Sometimes you can fix it through firmware, microcode, or compiler updates,

but very often you have to actually replace the entire chip. So that makes it very different. All right. So what are possible consequences? So the economics, right? I mean, think about it, you know, if there's a vulnerability in a chip, discovered in a system that's very broadly distributed, the cost can be tremendous. And particularly now you have things like the European Cyber Resilions Act that has a lot of

cost involved just in terms of compliance, but then also when it comes to incident responses. So that world is not just quickly shipping an update on the software as potentially very expensive replacing hardware. So what should semiconductor companies do to prepare? I think the very first thing, what we see in the industry, you have to make cybersecurity pro-chips a first-class business objective. The same level as your features, performance, innovation, schedule, and cost. It cannot be an afterthought.

There are three things, I would suggest. Number one is similar of what we have done in the software world, move chip security verification earlier in the chip design lif cycles. You know, start essentially when you start with design, when you start with the architecture and make verification part of the design cycles. Ultimately, really getting to security sign off, similar to what we have done in other areas for chip design. You know, we had a design rule checking sign off, we have timing sign off, you have developed power sign off and so on. I think security sign-off will be a very important component before the chips go to manufacturing. The second thing, I think, that is really becoming equally important, is establishing supply chain visibility.

What I mean with that is if you have components on your chip that are sourced from third-party providers, like an IP provider, make sure you understand what these components are, what its security posture is, and track this going. forward even in post-development into manufacturing and deployment. There's a term that was very successful in the software world, software build of material. I think we need something similar in the hardware world, the hardware build of material. And the last one I want to mention is really prepare for the increasingly strict regulatory frameworks. Compliance is very often seen as a pain and costly. Why do I need to do this?

But compliance gets a development organization really on the paths early on to learn about cybersecurity and take appropriate steps to address those. I think the companies that adopt early will likely gain a major trust advantage here. Yeah, I agree. Do you have other suggestions? Yeah, I think what we always talk about is security is not an on-off switch. It's not something you just buy some products, some tools, and off you go, you're suddenly secure. It is a journey, and the journey takes time. So we always suggest get going on that journey as soon as possible.

We step back for a moment. We have been talking about AI disrupting the software development in the software industry for a long time. But there may be really much bigger wave coming, that AI disrupting, you know, the foundation itself, the trust in the hardware itself combined with software. So the message is very clear. I think we still have time to prepare, but we got to get going down. Thank you very much for your time, Andreas. A great conversation.

You know, we spent years talking about AI disrupting software development, but, you know, the next wave may be much bigger, AI disrupting trust in the hardware itself. So, you know, to me, the message is clear. The semiconductor industry still has time to prepare, but maybe not as much time as it then. Thanks. That concludes our podcast. Thank you all for listening and have a great day.