BTS #57 - Brian Mullen - AMI
In this episode of Below the Surface, host Paul Asadoorian is joined by Brian Mullen, head of SSDLC at AMI, to discuss the complexities of supply chain and firmware security. They explore the challenges of maintaining security in a complicated supply chain, the importance of proactive and reactive security measures, and the implications of end-of-life software. The conversation also touches on the gaming industry’s push for secure boot, recent vulnerabilities discovered in firmware, and the role of BMCs in security. Brian shares insights into AMI’s approach to vulnerability management and the future of firmware security, including the significance of Software Bill of Materials (SBOMs).
Whitepaper: https://eclypsium.com/wp-content/uploads/OpenBMC-Security-in-Practice.pdf
Subscribe
Below the Surface – Episode 57: Supply Chain and Firmware Security with AMI
Recording Date: August 13, 2025
Host: Paul Asadoorian
Guests: Brian Mullen (Head of SSDLC at AMI), Vlad Babkin (Eclipseum)
Introduction and AMI Overview
Paul: Welcome to Below the Surface, it’s episode number 57 being recorded on Wednesday, August 13th, 2025. I’m of course your host, Paul Asadorian. Joined by my coworker, Mr. Vlad Babkin, is here with us. And before we introduce our fabulous guest for today, just want to remind everyone that below the surface listeners can learn more about Eclipseum by visiting Eclipseum.com forward slash go.
Paul: I am very excited to have our guest with us today, Brian Mullen, who is the head of SSDLC at AMI. Now you probably know the AMI brand. If you’ve ever paid attention when you’re building your computer and you’ve seen the classic American Megatrends logo come up, or you may have noticed what I call accidental digital signage in some public location, not meant to be seen, but you look at a monitor and you’re seeing a bio screen in a retail shop amusement park arcade or what have you brian is with us today shed some light on what am i does in the amazing things are doing to protect supply chain and firmware security integrity brian welcome to the show
Brian: Hello, Paul. Thanks for the intro. Yeah, so I run the SSDLC organization at AMI. And if you’re wondering, if you’re one of the many people wondering what AMI is, we are an independent firmware vendor. And we sit in the firmware supply chain somewhere situated in the middle.
Brian: We have a couple business models. We license our code to downstream partners, or we can kind of partner with downstream vendors such as ODMs and OEMs to create their derived product.
Understanding the Supply Chain Players
Paul: Yeah, Brian, just, I want to stop you right there. So what’s the difference between ODM, OEM, and AMI? Like what’s the relationship there?
Brian: Well, we sometimes mesh them together and call them OXMs. But ODM, original device manufacturer, and original equipment manufacturer, when you think of like an ODM, think more like a factory in Taiwan that’s actually building the printed circuit board, building the platforms. OEMs are like larger organizations that may perform some of the same functions, but they usually contract with the ODMs. So they’re like your DELs or your Lenovo’s or your HPs. And AMI is an upstream vendor in that whole firmware supply chain. the OEM, let’s just say OXMs will come to an AMI or an IFV when they want to build a firmware component
Brian: So we have a lot of stable trusted firmware for BIOS or UEFI products or BMC or hardware root of trust. And they come to us to get access to that code, at which point it can be customized to fit their particular platforms. So with a little effort, they can tweak it and customize it to run on their platforms.
Paul: Yeah, I find it interesting. It kind of feels like the old saying that we have, like, don’t write your own encryption algorithm or software. It kind of feels the same way for UEFI and BMCs. You don’t necessarily want to take on all of that on your own. You want to leave it to experts such as AMI.
Brian: No, AMI gives it to you, it’s 99 % done. You just have to add your, enable the security, add your own keys and your own customization. So you may want to put your own logos in there and everything. Then you’re off and running. You can flash that onto your platforms and ship that product.
AMI’s SSDLC Organization and Security Approach
Proactive vs Reactive Security
Paul: Yeah, so I guess let’s start Brian with what are some of the things that you do and we gained some insights into this. We have a report, I’ll link it in the show notes. We helped AMI analyze the BMC software landscape. But what kinds of things are you doing, Brian, at AMI to preserve that software security supply chain?
Brian: Yeah, daunting task sometimes. But so this organization that I lead, SSDLC organization, it’s responsible for proactive and reactive security. You can think of it that way. So proactive security is preventing security issues and vulnerabilities from getting into release products. The reactive side is, okay, you have a release product. vulnerabilities or issues have been found, how do you react to those? How do you remediate them? How quickly do you move on remediating those products? Which is a major KPI for reactive security. It’s how fast do you move?
Brian: So I’ve been working with AMI since 2021, kind of maturing our security organization. Most of my focus has been on the reactive side. We have to get that stood up first and matured first. But we’re also looking at proactive security too. lots of work have gone into the reactive side. when I first came in, I mean, 2021, Firmware security in general, mean, a lot of focus has been put on that recently, So 2021 was it not too long ago, but when I came in in 2021, you know, we were kind of at one of those lower maturity levels. There was a lot of spreadsheets and emails being used to communicate and remediate security issues. So I have a development background. So when I came in, the first thing I saw was like, okay. How can we modernize this? How can we automate this? And we need to create it in a way that our operations can scale with the company’s
Automated Vulnerability Management System
Brian: So first thing we wanted to do is, you know, create a vulnerability management system where I could track all the vulnerability cited across the organization, all the products. Then I kind of, had to create processes that integrate that into the business units workflows so I could get that remediation information from them, process it, and then pass it on to the customers as fast as possible. So we’ve been, we’ve been cranking out different, been picking off little pieces of that ecosystem and optimizing it for the past couple years.
Brian: Yeah, we got it nailed. It is complex, but I think we got it nailed pretty good. one of the things, one of the greatest advancements, I think, right when I came in is that we had a… we created a tool that programmatically identified which of our products were affected by an issue. kind of, we were relying on a lot of individual team leads to do the investigation and determine if they were affected. But we created this programmatic tool. We have like 98 active, around 100 active. We call them CRBs, these UEFI projects. Each one of them have many customers, right? So this tool could go through and find, even the EOL project actually could identify which ones had the issue. But it would just run, it would go through the repos, find which projects are affected. So that was awesome. We’ve got that tied into our ticketing system now. So tickets are created for all the projects automatically.
Brian: So yeah, that’s, yeah, and then one link down to customers. So once the AMI projects are identified, we know which customers license each products, so we know which ones get the advisories to inform them of the remediations. And we don’t tell, it’s a need to know basis, right? We don’t tell all customers about everything customers just know about what they need to know about.
Supply Chain Complexity and Code Sharing
Shared Code Base Challenges
Paul: Sure. I don’t know if this is necessarily a dirty secret, I don’t think people, normal people don’t look into UEFI security or ecosystems as much as the people on this call, right? But a lot of the code base is shared, right? Like you’ve got the reference code and then when that ends up on systems, a lot of that code is shared in common. Is that true?
Brian: Okay, well there’s a lot lots of ingredients that go into the context of UEFI firmware. I mean it’s consistent across the FDACSA firmware. But typically you’ve got a silicon vendor component. So we get that from the upstream silicon vendor supplier. And then for UEFI specifically, you’ve got this kind of like open source reference implementation called Tiana Core 80k2. It’s technically open source code. There’s some history there. It’s like it’s, It’s custodian, I guess you could call it, it’s custodian is mostly Intel. So a lot of the contributors are Intel employees. So, and then other ingredients are just, you know, just. open source in general that we pull in. So you’ve got EDK2, you’ve got Silicon Vendor, and then you’ve got other open source plus the AMI component, right? And then that goes downstream to the OXMs and then they add in their special sauce.
Stability vs Security Tension
Paul: Yeah, so yeah, you’re right. There’s a lot of ingredients there and a lot of customizations. And it’s interesting from like an OEM standpoint, when a new vulnerability is discovered, for example, and we have to get a patch out that highlights the complexity of both the supply chain and all the ingredients in UEFI. I think it was you, Brian, that said that OEMs want like a stable branch. They don’t want to be experimental. Because if something goes wrong in this particular software, means systems aren’t going to boot, correct? Potentially.
Brian: Yes, that’s a nightmare scenario when your firmware doesn’t boot. Yeah, they look for stability. And that sometimes, the way to get stability sometimes conflicts with security best practices because manufacturers are nervous, right? They don’t want to change much. They want to kind of freeze that code base and keep it stable. They don’t want to breaking anything. But in order to provide good security and keep that firmware secure, you have to patch it. You have to perform updates. You have to generate that churn. So they’re stuck between a rock and a hard place, I guess.
Cherry Picking vs Continuous Integration
Vlad: And it gets even better when you think about libraries like OpenSSL. Imagine that that gets a security fix in some later version. Now, do you take the wall of OpenSSL? Do you take just the security fix? If you want to take just the security fix, then how do you do it? It becomes very complex very quickly.
Brian: It’s a very good point. It’s a very good point. And I actually sent emails directly related to that today. And I’m advising a practice of continuous integration. Everybody’s at their own maturity level, right? You can’t get everything at once, but start somewhere. Maybe you can cherry pick some packages, but if anything involves OpenSSL, Let’s stay with the latest and greatest because you’re guaranteed to get all of the patches. It’ll be supported by OpenSSL organization. You you don’t want, you don’t want to be using an EOL version of OpenSSL in your firmware. And then a major vulnerability is discovered in that. And then you’re in the only way to remediate it is to, you know, upgrade to a new version of OpenSSL. That’s rather disruptive. So. And you don’t want to be forced to do that because, you know, there’s a lot of eyeballs on a celebrity CV that has just been discovered in your product. So you want to develop those good practices. Keep that open SSL updated to the latest and greatest.
End of Life and Extended Support Challenges
Brian: Well, offer, AMI offers extended support for various products. So customers have that option. I just want to put this out there that the supply chain should be aware of, When we do, this is realities, right? When you’re supporting a product through the life cycle of the product. you have different ingredients in that product. You go from release to release to release to release. You’re updating ingredients from that complex supply chain, right? It’s unrealistic to expect every single one of those versions of ingredients to be supported. So it’s very taxing for an organization to try to generate patches for every single different… I’m talking about ingredients in each release, right? So think about your different versions of OpenSSL. It’s like, you didn’t upgrade, so you’re using that version of AMI code from four years ago. well, that’s using an EOL version of OpenSSL. So I’m sorry, there’s no patches available for that. We’re going to have to help you upgrade all of OpenSSL. So good practices. Keep your firmware up to date with your upstream providers. makes security much easier and much faster.
Gaming Industry and Secure Boot
Anti-Cheat and Security Enforcement
Paul: Right. There’s a few things that put pressure on that in the market. know, one is this switch from Windows 10 to Windows 11, right? In October, know, the Windows 10 is going to go end of life. There’s going to be a lot of people stuck with older hardware, looking to upgrade to newer hardware. And then you’ve got the whole gaming. I don’t know if you’ve been following. I know, Vlad, you’re a gamer. Battlefield 6 has been in the headlines because they’re enforcing secure boot in order to implement and enforce anti-cheat in their gaming platform.
Paul: And this is like a massive industry. I don’t remember what the number is, right? But gaming is a multi-billion dollar industry that hinges upon the integrity of the game that can be compromised if they don’t do something about preventing people from cheating. And one of the solutions to that is secure boot. And now that they’ve enforced that, they claim, I actually just read an article that they prevented say 300,000 users or something like that from cheating just by enforcing. Secure Boot and some other anti-cheat mechanisms in their games. But this all hinges on I’ve got a working, supported copy of Yue Hivai on my system in order to make sure it’s all up to date and working. I the latest keys. I mean, all of the ingredients, right, have to be in place for this.
Vlad: So it’s not even just that. To be honest, all of this anti-cheat stuff is, in my opinion, very controversial. So first of all, those kernel anti-cheats are not going to realistically do anything about DMA attacks. Somebody just inserted something like a PCI leech, but imagine one that’s adapted for cheating. I believe I saw a review of a device when YouTuber just grabbed one of the cheating devices. and it was a literal PCI card to which you connect your mouse and it just shoots automatically. I believe that was Counter-Strike, but it doesn’t really matter, you can do this for Battlefield. And you cannot really counter that.
Brian: Right, we have dealt with the gaming issues actually, the pre-boot DMA attack vector, that has come up recently. So yeah, we had to work through those issues. actually, was due, the issue affected multiple manufacturers and it was a configuration issue. wasn’t… vulnerability that it ended up being a vulnerability but it was due to configuration issues. So that’s another that’s a whole other topic is you know how do we ensure that that our manufacturers are configuring the security features properly.
Secure by Default Implementation
Default Keys and Configuration Challenges
Vlad: I can maybe have a suggestion. I’m not sure how possible it is for the whole firmware supply chain because it’s quite a bit more complex. But if you come from normal development, there is a concept called secure by default. And that includes a lot of things. For example, just to give a very layman example that’s very easy to understand. What we have at Eclipse is we deploy a platform for our customer. Now, how do we ensure that they have some default logins that they can actually start using the platform with?
