Name: How GE Vernova Secures Its Software Supply Chain to Protect Against AI Threats
Uploaded: 2026-05-21T18:07:50.595Z
Duration: 31 min 50 s
Description: How GE Vernova Secures Its Software Supply Chain to Protect Against AI Threats

Transcript for "How GE Vernova Secures Its Software Supply Chain to Protect Against AI Threats": Hello, everybody. Welcome to our webinar, how GE Vernova secures its software supply chain to protect against AI threats. Today, I'm joined by Brandon Bailey of GE Vernova and Quincy of Chainguard here, and we, are gonna have a great conversation today. It's a lot of content packed into thirty minutes. So, just a quick overview on how to, chat with us. In the right hand, side here, there's a chat box. We'd love for you to share where you're joining us from, and then there's also the q and a section. So if you have questions for Brandon or Quincy, go ahead and throw those in there. We'll get to as many as we can at the end. Again, a lot to get through here, so I'm gonna pass it to Quincy to kick things off. Awesome. Thank you, Mollie, so much for for teeing us up here. I'm Quincy Castro, CISO of Chainguard. Spent a few years in the industrial space and really, really excited to be here today with Brandon from GE Vernova. Brandon, tell us a little bit about yourself. Thanks for having me on this webinar. It's a really great topic, and I'm looking forward to discussing it and sharing information. But number one, I think, background is, we have similar backgrounds, right, starting in the Department of Defense area, you know, and there's a good, offense and defense side to that. And and my current role at GE Vernova is a we're a software business. That's where I support, and, ultimately, what we do is we control the grid. And so it's a really no fail mission, so it's kind of great for my background and, really looking forward to discussing the nuance of of where that's different. No. That's that's outstanding. So I'll say I mean, when I was in the industrial space, there was always this sort of frustration on the part of practitioners that, like, you know, people that do kinda IT cybersecurity sort of stuff just don't don't get this space. Right? They, like, don't understand the challenges. They don't understand how difficult this stuff is. And I'm curious, like, from your perspective, right, what does real operational failure look like in industrial tech? How would you explain, like, the challenges that you face around security to somebody who spent their life in kind of the IT infosec space? Like, what are the big the big differences and the big hurdles there that you feel like you have to overcome that they might not know about? Yeah. I think I think the biggest the biggest thing is, like, a traditional SaaS company. Right? A bad day is the website's down, the app's down. A bad day, depending on which product in our portfolio, anything from, you know, and again, so the lights are out, right? And these are broad swaths that we don't have agency over, Right? So our software is controlling the grid. It's controlling these interlocks, and more so today than ever in the past, controlling the data centers with the AI boom. Some of our software is really powering these data centers. Nobody wants us to be the problem, and so there's a there's a certain level of anxiety anytime there's a power outage that makes the news. You have to ask yourself, are we at fault? And beyond are we at fault, was it our fault? Like, was it our product and was it our problem? And so the stage at which we operate is, you know, it's highly stressful because when things go bad, they go really bad, and it's not as simple as this, you know, the website's down. It is, you know, the grid is down. And and, you know, again, we have a very broad portfolio of software products, but the the kind of high priority products are the things that ultimately could lead to loss of life. Yeah. No. I that's that's fantastic. And I I I mean, I think that's hard for some people to understand, you know, or they think you're being bombastic when you're like, hey. We make stuff that could kill people. And yet yeah. Yeah. Absolutely. Like, these are products that people you know, either they have some inherent risk themselves, you know, and I used to work in transportation. Right? We built locomotives. Right? I mean, these. are these are just huge, you know, kind of, like, risky assets, but also people depend upon the things that GE Vernova makes for life saving services. Right? Keeping the lights on in emergency rooms and things like that. Making sure EMS has power to be able to do stuff. Like, this is, you know, what underpins our civilization. Yeah. So it's interesting. You know, I think a lot of times we think, you know, security is not to say an afterthought, but even in organizations that take security seriously, generally, there's this sense that, like, hey. Look. Let's get the product working. Let's figure out how it delivers value to the customer. Let's get it in their hands, and then we can figure out the rest later on. Like, we can put some security bubble wrap around this that'll make it okay. We can ship the patches later. And that's been working, you know, not great for people, but it is sort of like the default at a lot of organizations. But, you know, certainly, you you know, you talked about the the kind of higher risk context of the products that you make. What breaks about that model when you look at that in the context of your products? Yeah. Well, I think before I answer that question, I'm gonna give a little bit of a backstory. You have to understand GE Vernova is a very legacy company. So number one, we have products that have been in the market and on the market for decades. Right? So we're talking long before containerized, you know, applications, long before Kubernetes existed. So very traditional applications, which guess what? They still run. They still work. Right? And we can't force customers to update them. So part of it is we have this legacy base that, you know, me as the, you know, senior director of product security feel, this this kind of responsibility to those customers to make them understand why they should get the latest and greatest. But really what it comes down to is in the traditional model, well, okay, in the traditional release of software, you have the touch point where you're able to quickly release a patch and the customer is open and and willing to ingest that patch. In our systems, we we have no agency over where and how it's deployed. You know, we we obviously, you know, deploy with secure deployment guides to make sure that they deploy it within the parameters we expect, but in many cases, it's it's an air gapped network. Right? And it's it's it's running a real time system that when you think about, you know, the cost of an outage for, you know, a server, right? It's like lost sales, lost whatever it is. In this case, to deploy software and update a system, you're taking the grid down. I mean, just by the very nature, you're taking the thing down, which is their actual direct revenue stream. So the more we can minimize the security need to release patches is really the key differentiator where we like we have to make a real business case to, Yeah. deploy secure software. Yeah. Yeah. Exactly. No. That that makes that makes perfect sense. I'm curious, you know, a lot of what you do is in very regulated markets, and, you know, that can be a blessing and a curse. Right? It's it's good to have somebody else, you know, helping set the bar for, like, what is minimally acceptable from a security perspective. At the same time, we all know, like, technology tends to move a lot faster than regulations do. And I'm curious, like, how do you see regulators fitting into this in in your mind? Are they a forcing function for security? Are they helping here? Or are you kinda out in front from a security perspective and sort of dragging some of these bodies along with you? Yeah. I think it it's both, and it depends on the product. Right? So in some cases, specifically, like, our gridOS platform, it is really like, we are trying to force the market into new secure zero trust products, which is ultimately what led to the relationship with Chainguard. But so we're very much on the leading edge, and the problem with that is because of the regulations and the misunderstanding between what the regulation says and and the deployment model. Right? So we have a very modern architecture, but it is not software as a service. It is still an appliance more or less. So if you were leading you know, reading through, like, Nurksep guidance, it's not it's kind of ambiguous on because how it's deployed is very much like a software as a service system, and it's very complex. And so we're trying to lead customers in the right direction, but also, we ourselves are not you know, we don't have to be compliant with these regulations. The customers do. So we have to it's this back and forth of how can we provide what they need, and what they're allowed to use and and balance that. But on the other side, where regulation does help us is, inevitably, security is a call center, and that's, I mean, that's a cultural in some cases, it's a cultural problem. In some cases, it's actually just a an actual volume problem of we can only do so much. So new regulations that aren't really impactful to our customers, but are to us that help everybody, right, high tide lifts all ships, is is the EU Cyber Resiliency Act, which is a legal forcing function of secure by design, secure by default, which means we sell our software across the globe. So, we're not going to caveat, if it's going to this customer, it meets this requirement. We are going to change the overall requirements, and that way the entire product and the entire portfolio is better for that. I think that's one case of leaning into regulation. As a security practitioner, you know, sometimes you have to use the ammo that you're given, to make the case to the board for investment, and that's one one area where you really can lean into regulation to support your your your cause. Yeah. No. That's that's fantastic. And I think that, you know, what gets lost in this sometimes is also from a practitioner's perspective, like, how do we do this in a way that is simple, that is, like, accretive to the value of the products and the services that we're selling? You know? And it's not just about, like, can we drag ourselves kicking and screaming across the finish line for these regulations, but can we do this in a way that is, like, elegant and, like, beneficial to our customers? You mentioned, you know, the work, obviously, that, GE Vernova and Chainguard have been doing together. I'd love to hear a little bit about how that. has gone and kind of where this came from, what prompted the initiative. How did you get started here? Yeah. So I think the the the backstory ultimately is, you know, GE Vernova is trying to produce this next generation of grid automation software. And what that you know, so grid OS, grid orchestration software is that suite. It's modern architecture, so containerized, you know, using Kubernetes for all the orchestration. The problem comes when you have customers who are used to, you know, kind of monolithic compiled software, which is, you know, again, like, yes, you're still using some Java libraries and things like that from a supply chain perspective, but it's compiled in. And so from their perspective, they don't actually have visibility into say, what is the CVE exposure of this product? Whereas now, in an open architecture, they can run their own scans, they can see every problem, and they are not equipped to understand the context of what's important, what's not important, and why is not important. So, again, we're we're very transparent with delivering s bombs for our products so they can see everything, and we do some VEX data so they can understand why it doesn't impact them, but they also have legacy policies that would not allow them to go into production. And so how do we combat that? And it you you touched on, like, how do you make this clean and simple? And on one hand, you know, you're building out the business value analysis of making an investment in a security tool, and one assumption you have to make is you're doing the right thing already and so you can measure the cost of change. And in the other case, you don't have the capacity to do what you need to be doing, so you can't even measure the cost advantage, right, because it's like if we were doing this right, this is what it would cost and this is what the value we would extract out of. But really what it came down to is customers really applying pressure to us to address these concerns of theirs and us coming to the understanding that, certainly, within any short period of time, we could not meaningfully change the kind of the volume of CVEs that are exposed to the container layer. And so it really came down to, you know, we could try to do the right thing, but it would take time and equal amounts of investment to change the entire, you know, container orchestration of of how we're building containers, maintaining our containers and actually trying to push them out, or we could partner with Chainguard and and secure our supply chain. Right? So we could get these zero these basically CVE free, you know, containers, as well as the supply chain element of that, and that is one of the biggest classes of vulnerabilities that any product will have, especially when you're using open source stuff is, you know, containers probably number one and then open source libraries, number two, as far as overall volume of CVEs. And at a certain point, that volume itself is really unmaintainable to continuously run VEX data, to continuously analyze and disprove the vulnerabilities. So so by purchasing Chainguard, you you're removing that entire layer of work, and you're you're, you know, you're outsourcing it to trusted partners to to really relieve that pressure. I'm curious, like, do you have some numbers you could put behind that, or what did your container image hygiene look like before you were doing this? And, maybe a follow on question there is just, from an engineering perspective, you know, how how much how much effort was going into doing that kind of work. Yeah. Well, I think it I I guess the best way to broadly interpolate the second part of that question is the scale at which we operate. Right? So, like, for me and my team, we're responsible for a portfolio of over 300 products. And now not all of them are containerized products, but we when we when we create processes and procedures, we have to try and to generalize them at a level that everybody follows. Then the problem comes down to measuring. Like, how do you measure the compliance of that? And so, again, the the the hardest part was, are they doing what we expect them to do? And as, you know, again, being in the product security space, you know, like, everything you wanna do is to shift left, to shift as far left as you can. But we're a legacy software business. Right? And so a lot of these processes, like, we can give the tools, but if they don't come to us and ask permission to release until it's time to release, no, you can't release, right? And so, that's the one thing is like what we were doing before was, it was really a heroic effort to try and do the right thing, but failing, you know, they just like, ultimately, at any any scale, it's really hard to to maintain that kind of posture. Could you remind me the first part? I forgot the first part of the question. Oh, no. I and I'll observe that I think GE is good at many things, but, like, measuring and, like, execution. is absolutely one of them. So. I I'm sure that those metrics are very much, like, in your favor as you thought through, like, how do we make this decision? Yeah. I remember the first part now. So the so as as our first releases were rolling out, right, so signing the deal with Chainguard, making the plan for the, you know, the sprint planning to actually introduce those images into production. In the first three releases, we did a phase release, right, because it was just it's it's a body of work to, you know I'm not saying like, the images are there, but we're very cautious. As we talked earlier about the sensitivity of the reliability of our software, we were just very, deliberate about rolling it out. By the third release, we had already just just literally the only thing, you know, no hygiene changes, anything. Just by swapping two Chainguard images, you know, thousands of CVEs resolved. And again, coming back to that pressure point of why we, you know, why we made the decision we did was we had customers contractually, like we owed them these releases, and I think it's part of part of the whole story is when you're doing this type of software, this is something that, you know, we you know, everybody knows, like, QA, staging, prod, but in industrial type software, it's like, yes. We have those internally to ensure that the software is ready to ship. Customers don't care about that. What they care about is actual functionality of the software doing consistently what it used to do and doing what it should you know, was doing plus whatever new features it is. And so, you know, we have what's what's considered, you know, satin fat, so site acceptance testing and factory acceptance testing. And that is where it is a laundry list of checks to go through and and and confirm that it still operates, it's still stable, etcetera, before it goes into production. And so prior to Chainguard, you know, we would release, go through that that process, and then by the time it was in production, guess what? Not like even if we shipped with zero CVEs on day zero, by the time it went into production, you had a backlog of CVEs just because of time that had gone by. So that customer, right, like, I to the point, and I won't name the customer, but they were so impressed with the output that they are now a customer Chainguard for their own internal development. So it it was it was truly, like, a real force enabler for for that. You know, it was the right thing to do, and I was very glad to have the pressure to make the business case to do the investment, but, ultimately, like, it not only won a customer, but you it won Chainguard customer as well. No. That's that's an amazing anecdote. I'm curious, you know, on the engineering side, you know, we're talking about eliminating toil. Was that enough to get engineering buy in, and, like, what did that conversation look like for you? Yeah. Well, luckily, part of the original conversation was with engineering because, again, from a product security standpoint, you know, I I come from startups, right, which is a very different cultural thing than working at GE. So, you know, from there, it's like everybody moves fast, everybody's ready to do things. And and, like, policy or or standards follow the right thing. Like, you're doing the right thing, then you document it. Whereas at GE, at the scale is like you you document what you should be doing and then you're you're enforcing. And it's just unfortunately, it's kind of like the way it has to go at scale. And so as the enforcement came down, ultimately they were like, well, how do we how? So, we got pretty fast buy in because they knew they had to do it. It wasn't necessarily us trying to be the bully in the room, it was this is the right thing to do, this is what our customers expect of us, Now let's guide you down the path of how you can do this with the constraints that you have. So it was actually a pretty easy conversation once the work was in front of them to understand that we should have been doing this all along. This is the expectation going forward, and here's and and we have a solution. So, like, we didn't just bring up a problem and say figure it out. Right? We we came to them with the problem and the solution, and then it went pretty smooth from there. No. That's out outstanding. I in the in the interest of time, I think let's talk about AI, which, you know, Yeah. one cannot have a conversation about these days without discussing, and particularly the frontier models like Mythos. Obviously, this has, like, been a really hot topic in the security space. I'm curious, like, from an industrial's perspective, are you starting to see concerns about, AI assisted offensive operations, AI assisted vulnerability discovery? Or is this larger, like, a theoretical kind of topic? Inside of GE Vernova, it is well past theory, and we have we we we are it is topic number one all the way up to the board of directors. Right? So great time to be in product security because all of a sudden you're, you know, the coolest person in the room, right? Like, and luckily, like we again, I think doing the fundamentals right is kind of the answer to any new frontier thing that could become a risk, Right? And so we had already been planning a lot of things that just so happened to line up to, you know, start in early April, and we're rolling them out before the frontier models were were announced. And so it was a really good time to be like, oh, yeah. Remember all that that money I asked you for? And, like, you decided finally I convinced you to spend it, and now we're we're doing we're in a good spot. But but it's absolutely the the concern is real, and the concern is gonna be real until we prove it otherwise. Right? And so as we work to get access to these models, we've already got the infrastructure laid out, we've already got our code staged and, you know, everything is ready. We're just waiting to get access to these models and we're already doing tests with, you know, Opus four seven cyber and and other, you know, you know, non mythos, but still frontier models to to prove out that the the, you know, kind of AI DLC is is gonna be operational. And then the biggest, I think, thing, and this if there's a takeaway for anybody in product security is, you know, my message to whether it's our board, our CISO, or, you know, anybody who asks really, chief product officer is, look, look, we don't have a vulnerability detection problem. We have a remediation problem, and that is the core of what it is. This is a new tool to find new problems. We already have tools that are best in their class at finding problems. The only problem is how fast can we remediate, and what this does is it creates this new, and the interesting part is people treat it as if it's a different type of finding. Right? Like, we have we have, like, every release gets pen test. You know, every we have we have an entire red team dedicated in GE Vernova to test all of our products, like in house as well as outsource. We prioritize those findings. We have SAST, we have DAS, we have SCA, and we these are all findings. And then all of a sudden, frontier models are announced, and it's like, well well, what does it look like when these are found? I'm like, they get prioritized, like, everything you know? Now the only difference is that that kind of the time to exploitation, right, which ultimately exists for any of the other vulnerabilities as well. I think the concern is that if these models find the problems, the models themselves can chain together and build their own exploits and therefore, as if, like, only the findings that they find are exploitable. Right? So it's a balancing act, but ultimately, it's like we we're doing the right things. We've really got a remediation path in place. And so I think, again, the the company is a top priority from a product and, you know, product security perspective. I mean and this goes across not just our pure software, but our gas turbines, our wind turbines. Like, they have their own embedded softwares as well, and so, like, it it's a top priority as I'm sure most companies are, and then you have to measure you know, you'll see things like the curl library, which is a very well tested library, but then, like, Meet those lines one low vulnerability. But then if you talk to somebody in the banking sector, they're panicked about what it's finding. And so it's it's, yeah, it's it's a new frontier. No. It it it absolutely it absolutely is. And I think all the more interesting because of the inherent challenges we were talking about at the beginning of of our discussion. here. Are there any and you talked a little bit about, you know, kinda how you're thinking about remediation. Are there any specific ways you see AI assisting on defense in the software supply chain space? Oh, I think I mean, in the supply chain space, I haven't seen so I think one of the risks that we see and and and our our core focus right now is really around what what we can control. Right? Supply chain is one of those things where we rely on it and we can do as much governance around the edge as we can, and we've talked, you know, obviously, the the where the the the business value analysis and the business, you know, impact of using Chainguard sits right there, where things that are out of your control, get a trusted partner that, like, they're they're the the main thing is the main thing. Right? Chainguard is worried about the supply chain security, and and we can do as much as we can to protect on the outside. What we're doing really internally is mostly on those actual our code base. Right? And we've already got really good, you know, pipelines through skills and other things to really expedite the remediation of vulnerabilities that we have agency over. Yeah. That's that's outstanding. So I know we're we're we're got about five minutes left here. I would love to ask you to address, you know, kind of the product security leaders out there in the audience, particularly folks that are working in similar spaces. And, you know, if you were to be able to talk to them directly, like, what's one thing you'd tell them to stop doing immediately, and what's one thing you'd tell them to start doing immediately? Yeah. That's a good let let me think on this for a minute. And and this part of this is, again, like, I've had such a broad spectrum of experience from software as a service companies, actual cybersecurity like MDR companies, and my you know, and it's different. Like, what you do and how you do it is different. I think the number one thing, and this is this may be low hanging fruit, but you'd be surprised at how much it happens. If you're relying overly on just your tools, right, so just your SaaS, just your SCA, right, just the open source findings, and you're prioritizing everything, then nothing gets prioritized. And every time you do that, whether it's a pen test finding that actually gets invalidated by the engineering teams, whether it's an open source package that, again, is you know, there's not even a fix available. Every time you do that, you lose a little bit of trust with the engineering and product teams. So if the more you can do to layer on, like, from a product security perspective to do as much background as you can, to say, look. We have this finding. And there's tools out there, and I don't wanna name drop them in this call, but ultimately, like, hey. You have a SaaS finding. Is it is it exploitable? Like, that's an important thing. Is it reachable in your code base? And and, you know, surprisingly, like, SAST and SCA, that is a relevant question. We've just recently gotten new tools where it literally allows you to flex for for software composition analysis, and hopefully will be on Chainguard libraries before too long, but ultimately, you're relying on the open source packages. If you have a package that has a public exploit available and a fix available, that's your priority. So, really just helping to focus on that, like, you can't fix everything, focus on what's the biggest impact so that you don't lose trust in in your engineering teams. Yeah. No. I think that's that's so important and really making sure there's just that tight partnership there where, you know, you have the trust, they see you as an enabler, and you're able to go out and, like, amplify what they can do to ship secure products effectively. I'm curious what comes next for you, and what's kinda on your road map for AppSec for the rest of the year? Yeah. So so right now, it's really two things. One, building out the story to to to get Chainguard libraries. Right? I mean, that is our next class. I mean, as we see weekly, a new Shai Halloud or some new super supply chain threat, and it's this constant reactionary thing. And and so you don't wanna have to react. Right? The more times your phone rings, that that raises the level of anxiety. So so building that story. Right? These things are sometimes multiyear, you know, story generations, but as long as you're improving 1% or, you know, 10%, whatever it is on whatever scale, That's one thing. Second is really ironing out the AI DLC. So leveraging deterministic security tools, feeding that data into a generative, you know, the the latest model, and help having it help remediate vulnerabilities. Right? Like, really levering up that that, remediation pipeline. So, again, kinda back to the advice to PSLs as give them tools. Right? Give engineers tools. I would love to go in and, you know, push code. And in fact, right, like, there's a cautionary tale there where, like, the more you enable somebody, the more they wanna go do somebody else's job, and sometimes it's important to focus. But by building out the right tool sets to enable your engineering team, it just it's the operational, the force enabler and the force multiplication is really powerful. And I know we're out of time, but so are we planning to test meet those capability at GV? Yes. We are planning to. Excellent. I see we've got one in here. What tool do you use for remediation automation? Yeah. So for remediation so if we're talking about, like, you know, open source libraries, we use Wiz, and it does a lot of our own, you know, data, like, you know, plug in auto PR requests. If we're talking about, like, the actual source code, right, SAS type findings, I wouldn't say we Again, very sensitive software, so we don't want to do a lot of automated remediation. We will provide the tools that will make the suggestions, but it requires a lot of testing before we go and merge it. Yeah. Excellent. So I think top takeaways for me, and I'd love to to hear your thoughts here. You know, what I'm hearing is, number one, you know, look. Secure by default isn't a luxury. Right? For companies like GE over and over, this is the only viable model to be able to deliver for your customers. Two is that by starting left with secure components, you are not just delivering an inherently secure outcome for customers, but you are reducing disruption. Right? And at the end of the day, like, that carries a lot of weight in this space. What am I missing? What what are one or two other thoughts we wanna leave folks here with before we wrap up? I think the important part is, you know, industrial, you know, system security is is hard. It's it's different. It's not special. Right? But, I think I think if anybody's out there questioning, like, for some reason, it seems obvious that, like, if if you're in an automobile, right, like and and I would classify that as sort of in the same kind of tight systems that we kind of operate within, like, real like, kinda real time operating systems. It's almost like for some reason, you'll use an open source, you know, container, but, like, should we use Chainguard? Like, the answer is yes. Like, it's not it's not, what's the right word, like, fragile. Right? It it it is everything that you would expect from an image, but without the problems. And for some reasons, you know, you get customers, that are worried about it because it's a different thing. So don't be afraid to use, good software. No. Outstanding. Brandon, it's been so great having you today. Thank you so much for coming to talk to everybody here, and looking forward to hearing more about what you're doing over at GE Vernova. Absolutely. Thank you so much. Take care.