The Application Security Podcast
Chris Romeo and Robert Hurlbut dig into the tips, tricks, projects, and tactics that make various application security professionals successful. They cover all facets of application security, from threat modeling and OWASP to DevOps+security and security champions. They approach these stories in an educational light, explaining the details in a way those new to the discipline can understand. Chris Romeo is the CEO of Devici and a General Partner at Kerr Ventures, and Robert Hurlbut is a Principal Application Security Architect focused on Threat Modeling at Aquia.
The Application Security Podcast
Paul McCarty -- The Burrito Analogy of the Software Supply Chain
"Visualizing the Software Supply Chain" is a project which aims to kick off a discussion about the scope and breadth of the software supply chain.
Paul McCarty emphasizes the importance of understanding what's in the software supply chain to secure it effectively. He uses the burrito analogy, stating that you can't decide if you want to eat it if you don't know what's in it. We discuss the nuances around the Software Bill of Materials (SBOM) and the importance of understanding the differences between various SBOMs, especially for companies that deploy frequently.
The conversation also covers third-party components, such as APIs, SaaS solutions, payment gateways, and identity providers, which are part of the software supply chain. Paul gives the example of Stripe, a payment platform that includes software components and SaaS.
Paul's project helps people understand the different threats associated with each category in the software supply chain. The episode concludes with a call to action for organizations to prioritize understanding their software supply chain and leveraging automation as much as possible.
Gain valuable insights into securing the software supply chain and consider guidance on actionable steps organizations can take to enhance their security.
Four key takeaways from the episode:
- Understanding the Software Supply Chain: Paul McCarty emphasizes the importance of understanding the scope and breadth of the software supply chain. He suggests you can't secure or have a valuable conversation about the software supply chain if you don't know what's in it.
- The Role of Third-Party Components: Third-party components in the software supply chain are crucial. These can include APIs, SaaS solutions, payment gateways, and identity providers. Paul uses Stripe as an example to illustrate this point.
- The Nuances of the Software Bill of Materials (SBOM): SBOM has nuance. We highlight the importance of understanding the differences between various SBOMs, especially for companies that deploy frequently.
- Threat Thinking in the Software Supply Chain: We appreciate the depth of threat thinking in Paul's project. This approach helps people understand the different threats associated with each category in the software supply chain.
Links:
- https://github.com/SecureStackCo/visualizing-software-supply-chain
- https://github.com/6mile/DevSecOps-Playbook
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @AppSecPodcast
➜LinkedIn: The Application Security Podcast
➜YouTube: https://www.youtube.com/@ApplicationSecurityPodcast
Thanks for Listening!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paul McCarty is a DevSecOps evangelist and the founder of Secure Stack, which helps software engineers and security teams collaborate better while building more secure applications. Paul is the author of several open source projects and is a collaborator on a number of others and helps run three meetups where he lives in Australia. Paul tried to be a professional snowboarder in the two thousands, but is now a skater dad who's passing his love of hacking software onto his kids. Paul joins us to discuss visualizing the software supply chain and the DevSecOps playbook. He shares insights on securing the supply chain. Walks us through these projects and provides guidance on actionable steps you can take to secure your software supply chain. We hope you enjoy this conversation with Paul McCarty.
Robert Hurlbut:Hey folks. Welcome to another episode of the Application Security podcast. I'm Robert Hurlbert. I'm a principal application security architect and threat modeling lead at aquia, and I'm joined by my friend Chris Romeo. Hey Chris. Hi.
Chris Romeo:Hey, Robert, Chris Romeo, c e o of Kerr Ventures, and, uh, super excited to have a fellow Michigander look that one up. If you don't know who it is. A fellow der joining us today.
Robert Hurlbut:Yeah, we have uh, Paul McCarty, uh, joining us. Uh, welcome Paul.
Paul McCarty:Hey, thanks guys for having me and uh, and shout out to Detroit for sure.
Robert Hurlbut:Definitely. So what we like to typically do when we're starting out our podcast is we ask our guests to, uh, give us your security origin story. So let us know what, what, uh, what brought you here, uh, for security.
Paul McCarty:Yeah, it's been, it's been an interesting journey. And by the way, thanks guys for, for having me. I'm a long time listener, first time caller. Um, the, the reality is that my journey was kind of unusual in the sense that, uh, I started out as a Unix admin, as many people did in the nineties. Um, I went to Wayne State University in Detroit, and, um, Got a job in the computer lab there and somehow found myself working for an ip, an early ip. And um, one of the things that I had to do there is I actually had to help them secure the network. And that was kinda my, my early days, but few years later, I was working for a large, uh, blue Cross Blue Shield affiliate out west. And, um, They came to the, the, the securities team, sorry, the Unix team, which I was on at the time. And they said, Hey, can somebody help us write a hardening document for, for all of our UNIX systems? And nobody on my team, everybody was like, I don't want, I don't want anything to do with that. And um, I'd always had interest in it. Had been writing some stuff in IP firewall for some stuff where kicked.
Chris Romeo:Very cool. So how, I mean, I'm curious now how, I mean, that's, you kind of stopped the story kind of midstream as a Unix admin, creating a, uh, creating a hardening guide, which I remember those documents as things guaranteed to stop the computer from working on Next reboot.
Paul McCarty:A hundred percent.
Chris Romeo:were referred to. That. So how did, I mean, how'd you get to the, to AppSec? Like what did you, was there a transitionary point from InfoSec to AppSec, or what's that look like?
Paul McCarty:Yeah, I mean I think that my specialty through the, the two thousands was really kind of building application environments at scale. So I did that for a bunch of startups and, and large organizations, John Deere and JPL, NASA JPL, and, and, um, Linux Networks and some others. And basically that kinda building the application environment evolved over time to, to working more and more closely with the dev team and then by BlueShield. I don't know. It would've been 2010, 2011, I joined the platform, the, the early platform team, and that's when I really started spending most of my time doing what was, was then not called DevOps, but that's what we were doing. We were doing DevOps, we were kinda a combined, um, team of qa, um, engineers, software engineers, and um, system admins working together. And that was really where my, my AppSec chops started.
Chris Romeo:Yeah, and I know we wanna talk about software. Supply chain, and it feels like everybody on earth should already know what software supply chain is. But I wanna get your definition. As somebody who's been diving in the deep end of the software supply chain pool, what do you, what's the official definition that you use?
Paul McCarty:That's, that's a great question because that, that was the problem that I, I faced is that we had all these people talking about attacks on the software supply chain and, and having issues around the software supply chain. And when you ask people, you'd get different answers. Right. Um, and there was a lot of kind of focus on open source libraries, but the reality is that, um, applications are built from a lot more than just the open source libraries. And so I, I really dove in to your point, and, and started thinking and talking to people about, you know, what were the things in the application that needed to be there? Because ultimately that's what a supply chain is. It's all the stuff that you have to pick put together to make an application work. So if you use my famous burrito metaphor, right? If you wanna make a burrito, you need a tortilla, you need some refried beans, cheese and sauce and some other things, right? And really understanding the complexity of the application, um, you know, environment and the supply chain that goes into it. It includes things like, hey, the software engineers, without them, you can't build software, right? The, the kind of custom local environments. The software engineers use the customizations to ides and their local environments, the ci, andd and runtime and specific hardware. So as I about this started coalescing it, writing my.
Chris Romeo:Have you thought about how software supply chain differs from other types of supply chains? So like, I remember when I first got introduced to supply chain, it was while working at Cisco, I. And so in those days, we're talking, I don't know, mid two thousands, 2005, 2006, in that timeframe. And supply chain from a Cisco perspective means something pretty different because for in those days, the supply chain was. The, what do they call it? It was the bill of materials, right? So it was the BOM. It wasn't an SBOM or an MLBOM or anything. It was just a BOM. It was a bill of materials. These are all the components that go into building a metal box and making it route packets, for example. So any, any thoughts about kind of comparisons between the software supply chain and other supply chains that exist?
Paul McCarty:No, that's a great point. I mean, cause we, we, we love to use that metaphor, right? We love, we love to talk about burritos or, you know, the way that cars are made on an assembly line, right? But the reality is that when you build that box, you build it, you put it in another box and you ship it off and it's done. It's a onetime thing. Right. Whereas with software, the software that we're building now is being, it's highly iterative. Like some, some of my customers are building 80 times a day. If you were to build a bomb or, or, or a snapshot of snap of the software supply chain, you'd have to do it 80 times a day because the application, guess what is changing 80 times a day. And so that's the main difference, mate, is that just how much it changes and it changes between, Dev, Staging and Prod too. And, and that's, that's another focus that we have to think about because as people start to, you know, want to secure the software supply chain, they typically don't use the same security controls in Dev and Staging. And, and you guys were talking about this in our earlier podcast, they don't use the same controls in Dev and Staging that they do in Prod, and that's a problem.
Robert Hurlbut:Yeah, definitely. Uh, so just to jump in, uh, there's a, a term you've used application composition awareness, and that's an interesting one. Uh, what do you mean by that?
Paul McCarty:Yeah, this is, this is me kind of, um, um, trying to be creative So this is real. I mean, so we're talking a lot about software supply chain nowadays and the government's talking about it. And you know, we, there's a lot of emphasis on SBOM Software Bill of Materials, um, as Chris brought up earlier. Um, and there's also a lot of talk about software composition and, and the tools that.
Robert Hurlbut:Right.
Paul McCarty:From a customer's business perspective, they don't care about any of those things. What they care about is, is that burrito safe for me? If I'm allergic to certain food items, is that, do I know if that burrito's gonna make me sick? And ultimately, is it safe to sell that burrito? Right? So using my metaphor, so I, I think. Application composition awareness is really about helping to deliver out of these things like SBOMs and software supply chain, what the customer really needs, which is understanding what's in it, is it safe for me, and can I sell it.
Chris Romeo:So you mentioned something that, uh, has been a bit of a dirty word for me over the last, uh, number of months, the SBOM. So I think I'm the only known pundit in the world of application security when it comes to SBOMs. And I keep trumpeting this everywhere I go, but everybody's so SBOM crazy. It's like the Beatles are. Coming to America and everybody's running around screaming because of the SBOM. They have SBOMs on their t-shirts or something. But like, I'm, I'm curious to get your take on, on SBOM. No, I'll just stop there. I'm curious to get your, uh, your take and I'll tell you mine after, but what, what is your take on SBOM?
Robert Hurlbut:No. no. Leading the question, right
Chris Romeo:uh,
Paul McCarty:Yeah, exactly. Exactly. No, no. Leaving the witness. I feel like we're back in Detroit. Um, the the, the reality is that I, I'm a proponent of SBOM. I'm a big fan. Right. Um, but however, Um, and maybe this is kind of where you're coming from. I don't believe that the SBOMs that most people are building or are obsessed with are really delivering the value, the business value that they need. Um, so to me, an SBOM that only includes a subset of your open source libraries that you build only occasionally has almost zero value. Um, SBOMs to me have to have several things. The first is they have to be timely. They have to be up to date, up to date. They have to have, they have to be contextually correct. They have to be also comprehensive, because if you're only talking about if we're trying to deliver an SBOM for a burrito or for a car, right? Let's not build an SBOM for a wheel. Let's build an SBOM for a car. And that means that there's a lot more that goes into that application and that application environment than just the open source libraries. And that's, and, and this hype cycle that we're in right now about SBOMs, there's a lot of people trying to, you know, meet compliance requirements. But really, ultimately, what is the business value for an SBOM? And that's what I, that's what I like and that's what I wanna deliver to my customers too.
Chris Romeo:Yeah, I mean, you, you hit on a couple of things that have been my challenges here with this one we're in, I like the fact you used the word hype cycle. Like there's definitely an SBOM hype cycle. Um, CycloneDX, the, the OWASP project has come out with ML BOMs and SAS BOMs and all of these other things, and, and I believe in transparency. I, I, I think that's a good thing, having transparency into what's being built. The challenge I have is, SBOM and BOMs in general are only 10% of the solution. It's it's if, if you don't take any action, we're spending all this time generating all of these piles of digital artifacts that describe the things that we think we're buying. That's 10% of the challenge, 90% is actually improving them, taking that actionable intelligence and doing something with it so that we have a better overall solution. And I just think we're stuck in this government mandate. Go thinking that this is somehow this solution to some gigantic problem. It's a, it's a solution to transparency. But you even mentioned if you're pushing software 80 times a day, nobody's keeping up with an SBOM for that. They're not taking any action as a result of it. They may be demanding that you provide me an SBOM. They're not gonna do anything with 80 of those a day. They'd have to have a system that could ingest them in real time and then provide some actionable value and get some change, and then monitor the changes amongst the SBOMs. Like, we're just not, there's none of that being talked about. And so I just think, I just think we're, we're, we're blowing a lot of smoke trying to, trying to be transparent with what we're building. When we should have, we should have taken it a step further and said, let's figure out how to, how to make things better with these things.
Paul McCarty:I a hundred percent agree. I a hundred percent agree. The importance, you know, for that highly iterative company that's doing 80 deployments a day. Right. The diff to your point, the diff between the last, you know, SBOM and the current SBOM is important cause has there been any change? Right. And a lot of this kind of finesse and the nuance around SBOM is being missed. Right. So I totally agree mate.
Chris Romeo:All right, we'll leave that. We'll put that back on the shelf to, uh, for my, one of my hot button issues to just continue to bang the drum. But, uh, um, I've been banging the drum since RSA. And saying the same thing and no one's even really taken any notice yet. But that's okay. I'm gonna keep banging the drum cause this is what I, what I believe. But Robert, uh, what are we, where are we going next?
Robert Hurlbut:Well, we're gonna look at a project, uh, that you've created. Uh, Paul, um, just wanted to, first of all, uh, tell us the project and, uh, the purpose. You know, why, why did you. Create the project.
Paul McCarty:Yeah, the, um, I, I've recently created something called the Visualizing the Software Supply Chain Project. It's just a document hosted in a GitHub repository. Um, and the idea really was to, to kick off a discussion about, you know, what is in the software supply chain, what is its scope? What is it's breadth? Um, and, and because we can't really hope to understand or secure the software supply chain or really to have a conversation of any value if we can't agree on what's in it, right? So if you don't know what's in the burrito, you don't know if you want to eat it. So
Chris Romeo:making me super hungry for a burrito, by the. way. Like this burrito keeps coming back up and I'm like, is there gonna be a burrito service? Is there a, a tray of burritos coming my way here?
Robert Hurlbut:this is, uh, you know, parentheses of food podcast all of a sudden, but yes.
Paul McCarty:Um, it's a good metaphor, and I keep, I keep beating that dead horse. But anyhow, um, the, the reality is that the project was really ultimately to, to start that conversation, like what is in it, right? Um, Because I think that if we start talking about, um, security controls and methodologies that we can use to, to protect our software and application environments, but we're not really looking at the whole thing, then we're gonna miss stuff. That was really, at its simplest that's what it is.
Chris Romeo:Paul, let's take a look at the visualizing software security project and ultimately this picture that you've created, cuz I'd love for you to just walk us through it and explain what are the different components of, of this project.
Paul McCarty:Yeah, thanks, Ben. The, the, it's just like I said earlier, it's just a, it's just a GitHub repo. Um, and it's pretty straightforward right now. It's just a single document, markdown document. Um, but the, if we click on the image here again, our nice bigger version of it, um, It was really about, you know, describing the software supply chain from end to end. Um, and so I talked to a lot of, um, our customers and a lot of friends and, and, you know, took a look at the applications that we were building and kind of broke it down into these, uh, 10 sections right here. So it starts at the far left with. The, the people that are required to build software. So these are the developers and the QA team and perhaps a DevOps team. And then there's the next stage is the local environment. So these are, these are things that customization or dependencies that are needed, uh, inside of the local development environment. You can think of this maybe like an i d developers help
Chris Romeo:SCV or is this source, yeah, sorry. S-C-V Source code. What's the V? Versioning.
Paul McCarty:Versioning. Yeah. Yes. Yes sir. Yeah. Yeah. It's important. Um, and I also, I'm glad you called that out because below that is, is also local tests. You know, I'm a big fan of running local tests, whether those are pre-commit hooks or what have you. Um, and I think that those are important as. You to call out as well. So, um, and these are just some of the, the, you know, these are just examples in the gray section here. These are just some of the examples that I came up with. Um, every software supply chain is gonna be its own unique, and so it's gonna have its own unique, um, components. But yeah, the next stage is the actual source, source code itself, and this libraries using to. Open source components, but also proprietary code. And I, and I think it's important to call that out because there's so much, so much emphasis right now on like open source and, and, and almost the open source is the bad guy, right? When, when you look at software composition analysis tools, they typically will only help you with open source components. Open source isn't bad. It's amazing, right? It's the, the whole internet is, is, you know, underpinned by great open source projects. So we need to also be thinking about the proprietary code that, that is in our applications as well. Um, so next, the next stage was our integration stage, and this is basically where the, the development team is, is integrating. Code together, um, as part of a, typically a GI repo. Um, it's also the s SCM providers like GitHub and GitLab and, and Bitbucket and so forth. The pull requests and any other kinda collaboration components that the team is using. Uh, next stage is deployment. Um, this includes the, the areas of the software supply chain where you're using to actually, um, to, to build. And, and create a deployable artifact. Um, the next stage is the runtime. This is how it's running. The operating systems, the containers, the servers, so, so on and so forth, that, that are needed for the application to run. The next stage is hardware, and this one's an interesting one because a lot of times nowadays in this kind of cloud enabled, we don't really think about is there hardware necessary, but there's a lot of applications that require. You know, GPUs or, um, or specific, um, you know, PCBs or, or, you know, customized microprocessors or, or things like that. So I wanted to call that out if that hardware is necessary for that particular software supply chain. If it's a dependency of that software supply chain, it should be called out. Um, the next step is actually the, the DNS or, or the, the namespace that the application uses. And, um, this is important because if you're delivering an application to customers and they interact with it, you need that That's part of that dependency structure, right? If that URL doesn't exist, exist, Your customers can't get to it. And, and that needs to be called out as well. Um, and then the last two stages are services, um, which are the kind of third party components that your application or your application environment uses. This is stuff like third party APIs, any SaaS solutions, payment gateways, um, identity providers, things like OAuth, what have you. And the last stage is, is cloud.
Chris Romeo:When you say, um, ser, when you say SaaS solutions there, can you gimme an example? Like what, what type of SaaS solution would be part of my software supply chain?
Paul McCarty:Yeah, great. Great question. Uh, Stripe is a really, really good example, right? Stripe is, Stripe is both a my, you know, our, our platform uses Stripe so our customers can pay us. Um, that includes, you know, both kind of software components, but it also includes the SaaS itself. If you don't have. Um, products and subscriptions set up in set in Stripe, guess what? You're not gonna be able to sell your product. And that's just one example of the kinda interdependencies that that many cloud enabled kinda modern, especially modern web apps have, you know, the kind of talking to a number of different things. Um, in some cases even pulling components from. CDNs, for example. So that's something that I call there in the last stage, which is cloud. So any cloud services or any components consume from service, that's part of your software supply chain as well.
Chris Romeo:And And one of the things I found interesting, Paul, about this project was really clicking, going a level deeper into what you've done. Um, because Robert and I, as our audience knows, we're both, uh, threat modeling proponents, big fans of threat modeling. And so as I started to kind of scroll down and look at. And, and click through some of these, you know, for example, I was just looking at source code a second ago. I click through and you've got this section that says what's in scope, examples of languages, but then what are the security concerns? And so for me that's kind of what are the threats, is what I'm seeing there. You know, if you keep scrolling down, what are the security concerns like? So for me, that's one of the interesting things is just to, to get a perspective on how have you. You know, the depth of, of threat thinking that you've done here as far as helping people understand what are the different threats that are then associated with each of those, uh, categories that you put together. So give us some context. For example, let's, let's talk about this, this, um, software specific, um, right source code, sorry, source code specific one we're looking at, let's talk about these security concerns.
Paul McCarty:Yeah, sure. Yeah. Good. Yeah, good question. So yeah, that's the, you know, as I was going over the image, the, the, we've built a matrix, um, in the markdown that allows you to click into each one of those stages. Um, and in this case, we're looking at the source code. Uh, I clicked on the source code, um, component here in the matrix. And if you scroll down, Talks about what's in scope, as you said, programming languages, the frameworks, and have you, and gives you some kinda visual examples of, of some things that would fall into this category, but then also talks about who owns it because one of the concerns is that, If you're identifying and visualizing the software supply chain, and you need to, you know, uh, collaborate with someone so that you can, you can secure that component. Who owns it? Who do you talk to, right? Um, then the below that are the security concerns, um, which is where we're kind of talking about. Um, the specific issues around that particular stage of the software supply chain. So in this case, we're looking at the source code stage of the, of the project. And I'm talking about here some of the things that, that are security concerns in my mind. Things like knowing what's. What's in your soft, uh, software is, is the primary concern, right? Uh, some other things that I touch on are, are the, the dependency origin for the source code. Um, that's, that's super critical. So understanding where it's coming from, um, and, and being aware of that and the team, and not just consuming things blindly. Um, and, and something like, you know, package managers, we're seeing a lot of attacks right now on package managers. And we need to call it out specifically as a target. And then underneath that I talk about how, what, what are some of the ways that you can actually secure this and this particular part of the visualizing software supply chain project. Um, this is where I wanna spend a lot of time in the future, is kind of flushing out the how do I secure it? Part of each one of these stages of all 10 stages. Um, so yeah, more, more to come for this section right here.
Chris Romeo:Now, is this a project that other people could submit PRs against?
Robert Hurlbut:Yeah, I was
Paul McCarty:A hundred percent.
Robert Hurlbut:Very cool.
Paul McCarty:I would. I would. I would absolutely love that. That's the reason I put this stuff out there, because right now is just, My take on it. Um, not only do I want to encourage, and that's, that's one of my asks, right, is, is if people are interested in getting involved, please, um, you know, fork it, create a PR and, and get involved. But beyond that, something else that I think is important is that, you know, the way that individual organizations define their software supply chain, or wanna secure it, that's, that can be individual to them. So if they wanna fork this and make their own version of this, You it, my, my version of the software supply chain is not necessarily gonna the same ass and.
Chris Romeo:Yeah, I could see how some organizations would say, I don't have these, I don't have some of the things that you listed here. And so they could scale it down and and ha create an artifact that's. Specific to their environment, has their own picture, has the things that they're really concerned about embedded within. So yeah, I see a, I see a lot of value in people being able to adapt this and uh, use it just because it does take a complicated concept. Software supply chain seems like it should be so simple, but software supply chain and lays out a framework a, a way to visualize and see what it is. And so that's why when I looked at this, initially saw it, I was like, yeah, this is a good, it's a good teaching. Thing that everybody like developers should understand because they may encounter threats and different components here that we as security people haven't even thought about yet.
Paul McCarty:Yeah, man, I, I, that's, that's a great point you make about, you know, being able to take the, the, the components from the, from my document here and being able to embed these into your own, you know, company's, uh, confluence pages or, or other, you know, doc internal documentation. That's, that's, you know, That, that's part of the, the value of this for sure.
Chris Romeo:So I think we had, um, mentioned of the DevSecOps Playbook, and so how does that fit in here? The DevSecOps Playbook with visualizing software supply chain.
Paul McCarty:The, the DevSecOps Playbook is, is a document that I started running in, in 2022. And, um, basically what it, the, the idea here was that I wanted to create a, a step-by-step guide for my team that I was building, um, in that role. To, to give them a list of things that we could do, um, you know, to, to make our application environments more secure. So DevSecOps is, is a journey. Um, and what I've done here is I've created the playbook, um, 60 plus, um, uh, different kind of tasks. I, I don't call them controls, I call them tasks. Um, and they're broken down into several different, um, Domains, which loosely speaking, kind of align with, uh, the visualizing software supply chain. So I, I rely heavily on this. And in the future, I'd love to do, um, I'd love to do kind of a, um, a collaboration or, or, uh, where I'm calling out sections in the DevSecOps Playbook from the visualizing supply chain project. Um, because ultimately as you identify, Security issues in your software supply chain. You can come here to the DevSecOps Playbook and you can identify, oh, hey, if I start using pre-commit hooks or commit signing, or this addresses some of, of those issues in my software supply chain. So there's, there's definitely a relationship between the two, um, uh, documents, and I'm gonna flesh that out more over time here.
Chris Romeo:Yeah, and I think it's, it's neat that you made the connection to DSOMM, the DevSecOps Maturity Model, Timo Pagel's project within OWASP, that I look towards and I point people towards. That often as just being able to have that maturity model kind of framework to help people roadmap and see. So I see how this, you know, lines up with DSOMM as well as you've mapped it to a lot of other frameworks as well to make it, uh, to make it easy to see how it integrates. Um, but yeah, anything that, anything that connects with the DSOMM, I think together allow you to create a, a solid DevSecOps strategy.
Paul McCarty:Yeah, I, I agree. I think that that, and, and by the way, I want just, I wanna make a shout out that the, the DSOMM mapping actually was, um, was one of the collaborators on the, the DevSecOps playbook, uh, Max. Um, he did the DSOMM work, and so I, I gotta shout that out. Um, yeah, it's, I think it's important for, for us to use documents and projects like this to reference, um, other. Areas where we can, you know, we can pull and, and learn from. And, and so I'm a big fan of things like the MVSP, the minimal viable secure project and, and the, um, OSC&R framework for kinda identifying threats. And if over time I can start to pull some of those relationships into these projects as well, I think that, you know, that that helps the community.
Chris Romeo:Yeah.
Robert Hurlbut:So just to think about security some more. Um, And for developers and thinking about security, uh, with increasing threats to the software supply chain, what advice would you give to developers or organizations to help them, uh, secure their software, uh, supply chain?
Paul McCarty:Yeah. I think the first thing, and, and I know we've all heard this before, visibility is key, right? we've all heard from, from a ton of vendors that visibility is important, but the, the reality is for the software supply chain, um, I think understanding. What's in it and understanding what your software supply chain is comprised from is the first step. It's absolutely the first step. Cause this goes back to what I said earlier, which is that, you know, you dunno how to secure something if you dunno what's in it. So, um, my suggestion to development teams is, um, to take a look at the, the visualizing software supply chain project that I created and use that to then take lens to your applications that you're building. Um, Let's start to understand what's, and think about what are the different components that I'm using that we're using that, that our application consumes. Because then once you understand that, you can map it out and then you can start to look at, you know, are each one of these stages secure? So without that initial visibility, um, it's tough to do any of the other stuff.
Robert Hurlbut:That makes
Chris Romeo:So Paul, yeah. From a, uh, kind of a key takeaway call to action. I know you mentioned, we already talked about people being able to submit PRs against these projects as one potential call to action, so I'll take that one off the board, you know, as I'm known for doing, uh, what other, like what other key takeaways or call to actions would you, uh, would you leave our, our audience with?
Paul McCarty:Yeah, I mean, I think that. Securing understanding the software supply chain is a complex task. Right. So, and I'm, and I'm not saying that, that this is easy. Um, so I think there are, um, some tools out there that, that companies can, can, um, leverage, um, to help. You know, their teams learn about the software supply chain and what, what, what is its scope and how do you secure each one of those components? So I would say that my, my, my CTA is to, to organizations to say, hey, um, make it a priority to understand what's going in your burrito and whether it's it's good for your company. Um, and if there are tools out there, um, that can help you. Um, bring that visibility and help you understand the, the, the scope of it and, and, and leverage as much automation as possible. Um, that's all good. So that, that would be my, that would be my shout out.
Chris Romeo:Very cool. So Paul, thanks for, uh, walking us through these projects, educating us about them. It was good to. To get this perspective. I've certainly reviewed them before, but having you walk us through and explain each step was, was very helpful and I think it's gonna be helpful for our audience as well. So thanks for the work you've done on these projects and I look forward to watching them as they mature into the future.
