Supply Chain Security with Cassie Crossley

In Episode 11 of Secrets of AppSec Champions, Chris Lindsey and Cassie Crossley delve into the intricate world of supply chain security. Cassie Crossley, Vice President of Supply Chain Security at Schneider Electric, brings her extensive experience in software development and security to the fore, emphasizing the importance of following secure development practices. She advocates for the separation of build and development environments to avoid outdated methods and stresses the significance of modern frameworks like Google's Salsa platform and the NIST Secure Software Development Framework (SSDF), despite its lack of certification measures. Crossley also discusses the unique challenges of maintaining provenance for older software, especially open-source projects, and highlights the crucial role of developer education in preventing vulnerabilities introduced by unverified code snippets.
 
Chris Lindsey raises pertinent concerns about access control complexities within production environments and underscores the need for rigorous security measures to ensure the integrity of devices and software. The conversation shifts to the potential threats posed by AI, with both speakers stressing the importance of embedding security into AI-generated code from the outset. They explore global supply chain security issues, referencing Cisco’s audits and the effectiveness of zero-trust policies. Crossley also addresses the impact of legislative measures like California's connected devices law on both consumer and industrial devices, and how cybersecurity practices have evolved since the 80s and 90s.
 
The episode wraps up on a personal note, with Crossley sharing her views on career growth and the importance of pursuing roles that bring personal fulfillment. She advocates for exploring opportunities within the same organization to foster both personal and professional development without losing accumulated knowledge and experience. This episode offers listeners a comprehensive overview of supply chain security, blending high-level frameworks with practical challenges, and provides valuable insights into both the technical and human aspects of the field.


Key topics with timestamps:
 1. Understanding Supply Chain Security and Modern Software Practices with Cassie Crossley
 
 2. Securing Software Development: From Google Salsa to NIST SSDF Standards
 
 3. Protecting Supply Chains: Challenges and Solutions in a Digital World
 
 4. Cassie Crossley on Cybersecurity Challenges in Modern Supply Chains
 
 5. The Role of AI and Secure Development in Supply Chain Integrity
 
 6. Ensuring Safe Software: Best Practices and Emerging Threats
 
 7. Access Control, Zero Trust, and Supply Chain Security Insights
 
 8. Cassie Crossley Discusses Securing Legacy Systems and Modern Software
 
 9. From AI to Software Certification: Enhancing Cybersecurity Practices
 
 10. Navigating the Complexities of Supply Chain Security and Software Updates

For more amazing application security information, please visit the following LinkedIn communities:
https://www.linkedin.com/company/appsec-hive

Provided by Mend.io  (https://mend.io)

Creators & Guests

Host

Chris Lindsey

Chris Lindsey is a seasoned speaker who has appeared at conferences, webinars, and private events. Currently building an online community and creating a podcast series, Chris draws on expertise from more than 15 years of direct security experience and over 35 years of experience leading teams in programming and software, solutions, and security architecture. For three years, Chris built and led an entire application security program that includes the implementation of mature AppSec programs, including oversight of security processes and procedures, SAST, DAST, CSA/OSA, compliance, training, developer communication, code reviews, application inventory gathering, and risk analysis.

What is Secrets of AppSec Champions?

Join host Chris Lindsey as he digs into the world of Application Security with experts from leading enterprises. Each episode is theme based, so it's more conversational and topic based instead of the general interview style. Our focus is growing your knowledge, providing useful tips and advice. With Chris' development background of 35 years, 15+ years of secure coding and 3+ years running an application security program for large enterprise, the conversations will be deep and provide a lot of good takeaway's that you can use almost immediately.

Cassie Crossley [00:00:06]:
So the supply chain, just for a single device, it's thousands and potentially millions of people involved over time. So supply chain is very complicated. So where do you start? Well, you need to focus on what you want to know. It's way too large of a topic to ever truly grasp everything. I talk every day with folks understanding some of the specifics of the hardware and, you know, having conversations about people rights management and human rights management and materials and chemical makeups and things like that. It's much more than the bits and bytes that we normally see. So it's really what they're interested in. And that's again, why I wrote the book, is for those that are producing products, but also purchasing products, because, you know, CISOs and CIOs and those, they don't realize what they're getting themselves into always when they buy a printer or a phone, let alone they're buying IoT and smart, intelligent devices for their companies, not just software.

Chris Lindsey [00:01:14]:
Hello, and welcome to Secrets of AppSec Champions. My name is Chris Lindsey, and today we're going to be speaking with Cassie Crossley. Today's conversation is going to be centered around supply chain security. Cassie is the vice president of supply chain security at Schneider Electric. Cassie, please introduce yourself.

Cassie Crossley [00:01:31]:
Hi, I'm Cassie Crossley. I'm the Vice President for Supply Chain Security at Schneider Electric. We are a global company headquartered in Paris, France. I've been here 14 years. I come from a background of software development, a lot of project and program management, and at the company, I've been in the CISO and product security office for eight years. But back in the day, in the mid-90s, I actually worked at McAfee. So I was one of the first startup security companies way back when. And I specifically have a lot of passion around supply chain security from a software side, but also from a hardware side.

Cassie Crossley [00:02:09]:
So it's an exciting topic. And the fact that there's now a software supply chain security aspect to it.

Chris Lindsey [00:02:16]:
Awesome. I appreciate you coming today. This is going to be an amazing conversation just for everybody. I went to Black Hat and I saw Cassie talk, and it was just absolutely amazing. And so I want to talk more about that. I want to talk about the supply chain because your background and the conversations we've had have been really, really deep. And one of the things I want to do too, as part of our conversation is maybe some companies don't know where to start for a supply chain or even understand really what a secure supply chain looks like. So can we start there? Sure.

Chris Lindsey [00:02:48]:
What does a good supply chain look like?

Cassie Crossley [00:02:50]:
Right? And that's why I actually wrote a book. I don't have it right at my hand. I should have brought it over here. But I wrote a book on software supply chain security, securing the end to end supply chain for software, firmware and hardware. Because there isn't and was not a single reference that I could go to and provide people to from a supply chain standpoint, because it's, I think we all understand a common supply chain. So if you're making a cookie, you know, you need butter and flour and other ingredients and milk and things like that to make it. But where did the cows come from and you know, who processed the milk and all of those other happenings like churning the butter and where it gets packaged and all of that. It all has an origin, right? And the same thing with software and hardware.

Cassie Crossley [00:03:39]:
And we're seeing that a lot on the supply chain side. We saw it specifically in Covid when supply chains were affected. So we realized that there is, you know, places that things come from, multiple places, and there's, you know, just in one iPhone, for example, you have hundreds of thousands of people that have put that just in the factory together and a part of the tooling and everything that's with that. But in the Software itself, there's 50 applications that come pre installed on an iPhone, the operating system and 49 other applications. So the moment you turn it on, it updates. Right? What about all the millions of developers that are in the background that have helped build that and let alone everybody who's designed the platforms and the chips and everything. So the supply chain just for a single device, it's thousands and potentially millions of people involved over time. So supply chain's very complicated.

Cassie Crossley [00:04:35]:
So where do you start? Well, you need to focus on what you want to know. It's way too large of a topic to ever truly grasp everything. I talk every day with folks understanding some of the specifics of the hardware and you know, having conversations about people rights management and human rights management and materials and chemical makeups and things like that. It's much more than the bits and bytes that we normally see. So it's really what they're interested in. And that's again, why I wrote the book is for those that are producing products, but also purchasing products because, you know, CISOs and CIOs and those, they don't realize what they're getting themselves into always when they buy a printer or a phone, let alone they're buying IoT and smart intelligent devices for Their companies, not just software.

Chris Lindsey [00:05:25]:
Right. Well, and you bring up a good point. I mean, when you mentioned printers, most people don't realize printers, they create the firmware, the pieces, they ship it off and sometimes there's updates. And most people don't realize you can update your printer.

Cassie Crossley [00:05:38]:
Yeah. And that's what's interesting, the difference also about some IoT products versus OT. So everybody knows IoT but operational technology, which my company builds a lot of products and systems and software and everything for those. Operational technology is really what runs our critical infrastructure. It's what runs our factories. Manufacturing, electrical utilities, water utilities, but also buildings. What runs the building management systems. A lot of that is ot.

Cassie Crossley [00:06:07]:
And that's something that you don't want just an auto update to occur because it can mean safety. It also, most of those products should not be directly connected to the Internet unless they're a specific gateway or something like that. For example, if you bring in your oven, you know, a smart oven, when we were redoing our house, I didn't want a smart intelligent oven because I didn't trust that a future homeowner would know to do the firmware updates. And what's the risk and the safety risk of all of that brought in? It's probably different than a smart washer. But there are certain technologies that have that safety implication and that we need to be more aware of what's happening. And that means the responsibility of that asset owner, whoever it may be, may need to choose whether or not they want to update that product at that point in time.

Chris Lindsey [00:06:59]:
Right. And to be honest with you, I actually have a smart oven upstairs. And the last time I updated its firmware has been a very long time. And when you think about supply chain security, it may be auto updating, it may not be. Who knows what it's doing and what risk is it bringing just into my network just because of that. And you just don't know.

Cassie Crossley [00:07:19]:
Right.

Chris Lindsey [00:07:19]:
So you bring up a lot of great points because when you start looking at ot, you had mentioned people are putting things on the Internet that were never intended. And really when you look at technology and how we've advanced, really in the last couple years, we've come a long way. But back in the 80s and the 90s, when your company was producing product, was it ever intended or thought of that, hey, maybe 20, 30 years someone's going to drop this on the Internet, right?

Cassie Crossley [00:07:45]:
No, it wasn't. There is specifically the first question when California released a connected devices law and it went live in 21. And this law. And this activity was connectable devices. It didn't say consumer. That's what we heard that they intended. But all of that makes a big difference. This is not meant to be connectable.

Cassie Crossley [00:08:06]:
You know, this doesn't have WI fi, but it may have an ethernet port, so it's connected into other systems and it could be accessible. So a lot of operational technology, it's meant to run physical processes and that means that it can be in a place for a long time. Us and others in the industry do our firmware PKI certificates for 30 to 40 years. So the intended lifespan is decades. And so when you're designing this 15, 20 years ago, my Linksys router, just like everybody's else, said admin, Admin. Right. The intelligence of what we needed to do from a cybersecurity standpoint wasn't there. Thankfully, we now have things like the OWASP top 10.

Cassie Crossley [00:08:48]:
We have Mitre's Attack Surface. There's all sorts of areas that provide that guidance for secure by design. We ourselves follow and are rigid to the ISAIC62443 standard, which is an industrial control series of standards. And this includes a secure development lifecycle standard. And so this was constructed over a decade ago and our company has reached globally maturity level 4. But there are thousands upon thousands of suppliers that don't even have a secure development lifecycle. So this is a large problem out there just in the general industry, and one that is one of the reasons why not only did I write the book, but I talk all the time with suppliers, because this is so key and instrumental for this designing securely, but also understanding all the way to secure operations, like what is the asset owner responsible for? Just like we've heard of the cloud, let's just say responsibility model, shared responsibility. The same thing is with assets.

Cassie Crossley [00:09:55]:
If you have an unprotected asset, doesn't always mean that you need to replace it. You can put in additional mitigations and controls so that there is that level of security. Before that, segmenting your IT and OT networks, putting in the proper defenses for OT and other operational technology, just as you do with it. And that's what's really important is making sure that you understand the threat model, do simulations, do pen tests, just walk through it. Doesn't even require a lot of money, just you've got to do asset inventories. If you don't know what you have, you don't know your exposure.

Chris Lindsey [00:10:34]:
And that's a good point. If you don't know your threat model, you're in trouble. And when you do have your exposures, I mean for most of what you're talking about in ot, it's more about maybe air gapped and being on prem. If I'm going to come and do something, I might try to walk into an environment that I shouldn't be and slip something into the network. But when I think of these devices, a lot of people in today's world feel like, you know what the program, the thing works, get it out the door. And what you're talking about is that might sit out there unpatched for a very long time. And so kind of like the days of old past, when you're putting something together, you've got to think outside the box. What could possibly go wrong? How could this be used? And to your point forward thinking, what could be the environment in 10, 15, 20 years, when you're talking a certificate that long, you're looking at a 20, 30 year, you know, in the field.

Cassie Crossley [00:11:31]:
Yes.

Chris Lindsey [00:11:31]:
And so having to write things correct the first time and secure to the best that you can be at that point is absolutely critical.

Cassie Crossley [00:11:39]:
Yes, it is.

Chris Lindsey [00:11:40]:
What about the auto updates? What about devices that are Internet connected? What should we be thinking about from a secure standpoint? You have multiple maybe go back to an Iot kind of idea, but you have things like an oven or things that are connected in your home or in an environment. I mean you could even have a printer that gets compromised inside of an enterprise just simply because somehow or another. So what should we be thinking about there from a secure standpoint for supply chain? Should we be thinking about auto updates? What could possibly go wrong with auto updates? Sure, let me throw that out there.

Cassie Crossley [00:12:14]:
Well, and I actually had to create a new diagram just for the book because the distribution methods that could be compromised along the path are actually there's so many. So for example, we're seeing with cars now, right? Software over the air updates. Well, there isn't any large scale attacks that we've seen yet. But at some point in time what happens if there are? So that's one distribution method, of course people we've seen definitely over the years where websites have been compromised or fake websites have been put up with compromised versions of the firmware because or people are trying to get cracked software. So that is a distribution method that could be attacked or just mimicked so that there are those updates, if they're not auto updates. And then you have of course the auto update facility. But what happens is we see in the software supply chain world, I think the most well Known was the case of SolarWinds where the malicious actor actually went inside the build environment, put the code directly into that environment change when it was doing the build process so it was signed and looked perfectly normal. And we've seen many other cases where signed software has been maliciously affected and that has been distributed through auto updates.

Cassie Crossley [00:13:38]:
So when you have all of those different cases, that means what I see is that developers, those that are seeing are familiar with software security, then it goes to okay, I'm finished, you know, ta da, and then you move on.

Chris Lindsey [00:13:54]:
Exactly.

Cassie Crossley [00:13:54]:
And so let's talk about your oven. How do we know that the software that was released out of that firmware group was distributed to the factory without any compromise? How are they doing the integrity checks along the line to the point that they're packaging it? We all get those little slips where it's tested for voltage and this and that. Where are all the integrity checks listed on those packing lists. And that's something that the industry is working toward. And definitely when you're working in critical infrastructure base and other areas, that integrity checks is part of that validation for acceptance testing. But on a standard IoT and you shouldn't have to be an IoT expert and security expert to get that confidence either. But that's where things are happening. So it's not just in those auto update areas.

Cassie Crossley [00:14:48]:
It's all along the line where we can see and have seen different examples, real life examples of where supply chain compromise can happen. Because you know, let's just be very honest about the manufacturing process. Globally there are many manufacturers. So for example, Cisco uses all contract manufacturers and they do audits of those contract manufacturers. But it's very difficult to audit each individual person. So just like we see risks with people in regards to fishing exercises or other things, you have the ability somebody is paid off that could compromise and can it be detected. So we've seen lots of penetration tests where they get into it, but what about those that are insider threats and so those are all complications in the supply chain? There were reports just a few months ago where North Korea had actually put it personnel at certain companies. And things can happen in the supply chain accidental, but there can be espionage and intentional activities.

Cassie Crossley [00:16:00]:
So it's a very complex topic.

Chris Lindsey [00:16:02]:
So you and I are thinking the same because I was thinking about the Solarwinds and I was just thinking about the North Korean hacker that found his way into the company. Which the cool part about that, I don't want to call out the company, but a quick Google, you'll find it but the reality was by zero trust in what they did and the security policies they had in place, they limited the scope of what happened. I mean, they knew immediately they auto shut the thing down. They were able to take this person offline and come to find out he was actually from North Korea. And it was amazing in SolarWinds what happened there was amazing. When you look at state actors and they go for the long run.

Cassie Crossley [00:16:42]:
Yes.

Chris Lindsey [00:16:43]:
When they found the build server, they found what was happening. They injected. After the information was pulled down from the repository, they did a hash check on the file. It's the same file. They replaced it with their own, built it, put back the original file and then deleted it. So if you were to go back and say something's just not right and you did a code diff between what was on the build server and the repository, it would match and you would think we're good. Yeah. One of the best things that you can do is when you do take your builds, occasionally decompile it back to code if you can, because you still have some of those other files, depending on the language, and do a code diff there too, just to make sure that nothing from front to back is injected.

Chris Lindsey [00:17:28]:
The process that does happen sometimes is people think, man, it takes forever to build the regression testing. I have a hotfix that I need to get out the door. Developers will sometimes just compile locally and just push.

Cassie Crossley [00:17:43]:
Right.

Chris Lindsey [00:17:43]:
And that's a big risk that you just gotta be careful.

Cassie Crossley [00:17:47]:
Well, I hope they're not doing that anymore and selling to the US government because one of the first points of the secure software attestation form is having separated, basically effective build management and development environment separated. And what that means is in, let's say more legacy platforms building on your machine, it was common, right. We do a test build and so on and so forth. We wouldn't see that more in a container environment, but definitely some of the different platforms it's still possible and especially if you're maintaining older versions of the software, hey, I'm just going to rebuild it on my machine and this will be the release. So having the ephemeral builds, having that process where you're able to duplicate and replicate and make sure that you get that same activity. And so when Google released its Salsa platform, slsa, really I think that that helped with the industry to be able to say, hey, this is a best practice. It's not exactly referenced by that, but you can see a lot of that in the NIST SSDF, the Secure Software Development Framework, which version 1.0 was such light years ahead of 1.0 because it used to be I would ask suppliers follow Microsoft SDL because that's what you could get for free if they didn't follow 624-4341. And now with SSDF, at least there's something.

Cassie Crossley [00:19:09]:
I still think it's got a ways to go. Having things just in examples and not having a way to certify against it is a problem. But having secure software attestation form pick up things like this is one of the key things is let's not build on our dev machines. That's pretty important.

Chris Lindsey [00:19:27]:
Yes. Well, and the other thing too is can the interns hit production? Because that's something that I saw frequently at companies and I talked to frequently, is who can reach production, who can actually get out to that environment and do things and what is your development process? Because you know, we're talking about supply chain, we're talking about all the bits and pieces. And really it's amazing when you think about it because your example of an iPhone is probably one of the best because who created the chips, what files, what firmware is in those chips. We trust the devices that we get are clean and good. And when you start looking at the development process, you know what happens there, Your developers, to your point, I mean, there's so many, it's thousands if not millions of interactions happen just to get this device into your hand.

Cassie Crossley [00:20:19]:
Yeah. And you don't have the historical information for most of it. So that was one of the pieces that I pushed back on that I was able to get in the Secure software attestation form is that it asked for provenance. And then According to the NIST and DoD definition, that includes the historical records of developers and everything else. And I'm like, unless they've got a more modern system where it lists all the commits and all of those activities and contains truly the attestation pieces as part of the build process. Let's just say that within the last five years, tools that have really done that well before that, any code over that, especially open source, you don't have that information. How am I going to be able to provide the provenance for software library that I have no control over, let alone one that was built 10 years ago. This is where I always bring up the reference that I mentioned is that I wrote code for Paint Exe.

Cassie Crossley [00:21:17]:
I am positive that if you have a Windows platform, it still has Paint Exe because I worked at the company that we sold that product to before we created Publishers paintbrush. When I was with Zsoft, we were editing in VI on a UNIX system. And the only way you knew that Cassie wrote code is I was required to put comments in. There was no commits, there was no source code repositories and all of that back then in the 80s. But lines of code still live on. I mean that is just, it's going to be there forever, you know, in some form or fashion. And so provenance and really those attestation and going forward is something that obviously we're as an industry everybody's working toward. But you can't go back and fill 98 to 95% of the gaps in today's environment.

Chris Lindsey [00:22:10]:
You have so many different things outside of just the normal development. You think that you're done once you've released it, but that's not the case.

Cassie Crossley [00:22:18]:
That's right.

Chris Lindsey [00:22:18]:
You have those images or containers that could be compromised. You have your third party libraries, things come out, things are found. Some of the vulnerabilities or security incidents happened because somebody created a backdoor. Way back in the day, nobody thought about it, or somebody put something in that was so crafted and sly that it was just never detected. And then today, all of a sudden it's a big thing. And so it's an evolving process. And I love all the different things that you've talked about. How do we know that our stuff is secure? Because honestly, the consumer just takes it for granted.

Chris Lindsey [00:22:56]:
But to your point, our cars are starting to drive us places. How do we know that the car is not programmed to, hey, if I see this given kind of thing happen, crash in or whatever, right?

Cassie Crossley [00:23:09]:
You could have one line of code that says when you see a deer go 80 miles an hour, right?

Chris Lindsey [00:23:14]:
You know, somebody aim for it. Yep, yep.

Cassie Crossley [00:23:17]:
So it's very hard to understand. And one of the points that I wanted to just mention is that developers can be completely innocent and not realize that they are also harboring fugitives. If you start a new instance and you're using the gold official image of that instance and you set up, you spin it up and the moment you download a plugin that hasn't been scanned or you're bringing a code snippet from somewhere that's not an official bringing it in from open source, how do you know that that one little piece didn't have a keylogger, didn't have a logic bomb, didn't have something that could potentially future compromise or have command and control back into that. And that's where I like to say developers are now doctors with a scalpel, but yet they don't have that level of training in most places where they realize the impact that they have they've been given in a scalpel. You don't have a certification of any kind. And that's one of the things that I've been working with nyset, we're releasing this software system integrator certification that really talks about that due care. And so we do have a responsibility that we may not have. And you mentioned, because we can't have a podcast without mentioning AI.

Cassie Crossley [00:24:41]:
What has it been trained on, all of that? You know, it could have been trained to maliciously insert every 1000th line. You know, this little thing you just don't know because it's so complex and large. And I know it sort of going back to sort of olden times, but doing those code reviews, really walking through and understanding the code is very important. Whether you're taking in an open source project, you're using a package you should be scanning, you should be looking at potentially who created it. Definitely not taking any package that was created recently because of the risk that it could be one of the thousands of malicious packages that are deployed every month to all these different sites. So we have a responsibility, a due care that we now as developers and engineers need to follow.

Chris Lindsey [00:25:32]:
Right. Since you opened up the AI can. Because to be honest with you, I love AI, but it's one of those things where you just have to be cautious and careful to your point, because you can ask AI, go create an endpoint for me using JWT tokens, which is secure, and it will then you turn around, pass that same code back into it and say, is this secure? And then it will come back and say, well, no, and here's the changes to make it secure. Well, why didn't it create it secure the first time? You know, and you start asking it. And the thing is, to your point, the developer training is critical for success because if a developer doesn't understand the security aspects, they're going to just simply do what they do and I'll hit on authentication. When I ran my program, they hated me. They absolutely hated me. 5 minutes.

Chris Lindsey [00:26:22]:
The JWT token lifespan was 5 minutes and they hated me for that because the users can sit there and expire themselves out. Well, there's things you can do that you're not having to have them re log back in, but if you understand the whole process and do it properly, it's nice and secure. And you have companies and people out there that are like, look, I Don't understand it, I need it to work. And they throw a 24 hour window on it. And then what they don't realize is just simply if they walk away from their desk, somebody comes in, hits control H, sees your browser history and then clicks on one of your previous pages that you were on, it let you right back in. And then somebody, hey, how'd you get in?

Cassie Crossley [00:27:03]:
Right?

Chris Lindsey [00:27:03]:
Well, you never lost your authentication, you never logged out, you never invalidated anything. And as a direct result, that 24 hour window was, you know, guess what? And so it's just those little things. And to your point, if you don't know the good clean coding around it and AI is spewing things out, we used to look at Stack Overflow, we used to look at other websites to get ideas for, you know, hey, I need to be able to do a file upload, let's go. Stack overflow, it's got 30 examples. And then you find something, grab it and go with it. And today you're asking AI, give me this example. And it goes, here you go. Part of the problem is a lot of developers got upset with their stuff being scanned in from Stack Overflow, that they actually went back and poisoned their own data.

Chris Lindsey [00:27:48]:
And so the reality is when you're using AI and you're getting that good data or bad data, who knows? And so the reality is it compiles, but it's not right. And so you're right, that senior tech review is absolutely critical to ensure that this thing actually, is it good? Is it secured? Does it follow company development guidelines? Does it match?

Cassie Crossley [00:28:11]:
Right. And now documentation is preferred to be removed. You have to put it in a separate, for attestation purposes because it was giving away too much. Yeah, right. It was like, oh, that's how that works. Now I know how to adjust it. So the separate documentation requirements, it can be difficult. So one of the items that it takes me back to is that we've seen AI write wonderful things, right? But AI wasn't trained on kindergarteners and first graders and second graders, Right.

Cassie Crossley [00:28:41]:
It's generally graded and trained on, let's say more professional level, 8th level and up writing. But what about code? I mean, just a brand new graduate, are you going to have them write that certain code or was it going to be somebody with 10 years of experience? And when you have that, when the AI models were created, which code was it trained on? There's not a quality indicator on that code. So just like you said about the security, just overall the quality may not be there. What we could as an experienced developer write in 10 lines, somebody else may write 200 lines and that could be the difference where you could add additional compromise and vulnerabilities, or to know to use this library versus that, or to use, as you were talking about, this sort of architecture and approach for modeling versus another one. And that's the things that it's going to take such a long time to train AI on, to be able to say, yes, no, yes, no.

Chris Lindsey [00:29:42]:
Right.

Cassie Crossley [00:29:42]:
And we've talked about in the past the complicated measures of training. So those specialized companies that really do have that skillset, that are working toward it, where they've developed those models, that's great. But straight out of ChatGPT, no thank you.

Chris Lindsey [00:29:58]:
And to your point, your co pilots, your chat GPTs, your stuff that are publicly out there, you don't have that adaptation where all the information came from. And in a lot of cases it can't tell you or it doesn't want to tell you where it came from. Right, all great points.

Cassie Crossley [00:30:14]:
And I see some incredible startups today starting to use AI to be able to help developers. And that's the part I love, is being able to see, okay, this will provide you some fixes for potential vulnerabilities. Like, we've actually written the code, you check it, we're not going to commit it, but here is code which in the past has been very difficult, especially if you're trying to maintain a product. Think about remediating again, my old code on a C platform and this person only does rust and go, we don't want to convert it. So all of those technologies and where AI is headed though can create a lot of efficiencies in the right hands and so I'm excited for that. From a pen test standpoint, there's a lot of uses too. Like a pen tester themselves is not going to know every potential path, but I guess it goes back to that. Like in Endgame and doctor Strange going, I did all these different paths and the only one is where I sacrifice myself.

Cassie Crossley [00:31:15]:
So, and that's all those different paths AI can work toward. But yet, you know, as a human, we won't have those lifetimes of knowledge, but I see it really being able to start giving advantages. Now, from a software supply chain security.

Chris Lindsey [00:31:31]:
Standpoint, what is the best advice that somebody has ever shared with you?

Cassie Crossley [00:31:36]:
The best advice, and it's not really much of a supply chain topic, probably the best advice is to really focus on what really brings me joy. I mean, so I got into the whole SBUM and supply chain topic because by default I like being on the bleeding edge but I'm not a developer anymore and was not a good developer. But I love to bring ideas, I like to innovate in other ways and a lot of that innovation is with new processes. So I've got a Six Sigma training in a black belt but what I really enjoyed was the DFSS designed for 6AMO. Really how do I build this process? So things like when I get bored in a role then I'm ready to change roles and I've been at the company 14 years, I'm in my sixth role and you know, it's like okay, I've optimized or brought that up now I'm ready for the next and for the last year and a half been really focusing on the supply chain security topic. And I do it because I was heavily involved on the software bill of materials and I'm still like I'm pushing the envelope every day trying to do things that other people aren't doing yet from the largest scale. First customer providing for a certain company, all of this is, it's a new challenge and knowing that I can make a difference and really bring this, how do we make this where this can happen today or in the next few years? I love that. So the best advice was really it doesn't have to be a title, it doesn't have to be a job title or something like that.

Cassie Crossley [00:33:18]:
It's what's making you excited to get up and go to work every day and focus on those qualities. And you can find that I've been in so many different roles and in different positions and it's given me this breadth of experience but it's all, you know, a lot of that is the learning because I got joy of probably that innovation of that next topic. And so right now I'm going to be focusing on supply chain security and when I feel I matured it to a certain level both in my own life then it'll be something else. That's what I can recommend. So it's not I'm going to go out and be such and such. So I really recommend people understand exactly like not just which class and school you liked or which this out of the job. What did you like most? Did you like testing? Well then where could you go from that? Did you like this? Did you like the write ups? Did you like planning it by default? Are you just a natural project manager which you know, seeing that vision, there's so much to do and that's really what the advice I give because I went to someone and I said, hey, I want to be a cio. And she goes, no.

Cassie Crossley [00:34:25]:
She goes, no, there's so much more you could do. Go into the business, understand broader where it is. And I did, because I trusted her. She was like, you need to find something that you love, not a title.

Chris Lindsey [00:34:38]:
Right? I want to throw one more thing on because a lot of people think, all right, I've been doing development for a long time. I want to move on and do something different. And they go find another company. And what you did is you stayed in the same company because that knowledge, that information that you have just helps the company grow and be better. And so for those listening, you don't need to leave your company to grow. Just talk to the different leaders, the directors, the VPs, and say, you know, I love your area. This is something that might be a fit. And find out from them what their day to day looks like, because that might be for you.

Cassie Crossley [00:35:12]:
Right?

Chris Lindsey [00:35:12]:
And maybe not. So, no. That's amazing advice. So I absolutely loved having you on today. Thank you so much for coming and I look forward to running into you at these other events that we keep running into.

Cassie Crossley [00:35:25]:
Okay, great. Thank you for having me, Chris.

Chris Lindsey [00:35:27]:
All right, thank you. We'll see you. Thank you so much for joining me on this episode of Secrets of AppSec Champions. If you found this valuable, hit that subscribe button on Apple Podcasts, Spotify or wherever you get your podcasts. And hey, ratings and reviews are like gold for us. So if you're feeling generous, please leave a kind word. It helps others discover our show. Until next time, take care.