Today's Software Supply Chain through the eyes of the AppSecDev

Opening

Mike Krass: Hello, everybody and welcome to What's the Problem, the podcast where we dive deep into the most pressing issues facing cyber and data security leaders today. In each episode, we're joined by expert guests who share their insights and their experiences on the challenges that they face or see in the world of cyber and data security. Whether you're a seasoned veteran or a new leader in the field, this podcast provides valuable info and some strategies to take your organization to the next level. So join us as we explore the ever evolving landscape of cybersecurity and discover new ways to tackle the problems that we face. This is What's the Problem. I am your host, Mike Krass. Let's get started. 

Conversation

Mike Krass: Today. We are joined by Derek Weeks. Derek, say hello to our listeners.

Derek Weeks: Hi, everyone. And Mike, thank you for inviting me.

Mike Krass: Absolutely. Glad to have you here, Derek. Tell our listeners why you’re qualified to talk about security.

**Derek Weeks: **One just specific on application security. I've worked in software businesses for the last 30 years. In the last nine years specifically, I’ve worked with software that helped software developers help application security professionals. I’ve also worked a lot within the open source software development community. In those years, I originated and championed an industry report called The State of the Software Supply Chain Report. I did that when I was at Sonatype. And I was the lead researcher and author of The State of the Software Supply Chain Report for six years there. During that time, I also championed a DevSecOps community survey that generally had between 3-6000 people a year participate in that, and gave evidence of what the trends were that were developing in the developer and security communities and where they intersected. I also spent a lot of time in the developer and DevOps community when I co founded the largest DevOps community conference in the world known as All Day DevOps. That's something that I co founded with a friend back in 2016. And that conference has been operating ever since.

Mike Krass: Well, Derek, I think that you kind of previewed what we were going to talk about today. We are going to talk about supply chain securities. And we're also going to talk about this handshake between app sec and developers and how they work together. What does the euphoric oasis relationship look like? What are some of the barriers to that relationship forming that some of our listeners could probably see themselves in and hear and kind of feel that? Yeah, I'm experiencing this barrier as well. So before we get too far, I just want to do definitions here. So we're talking about supply chain security, first of all, application security, and the developers component? Can you just define those three very quickly for us? Because we're going to use those words a lot throughout this episode.

**Derek Weeks: **Yeah, so I think developers, I use developers as a broad term. Obviously, they're developers, people that are hands on coding, hands on keyboard coding. But it's really anyone that is creating and producing and deploying applications and environments today. So think of it from ideation up through production. These are the people that are developing and moving software out to market to make available to the users. Application security is a team of people, usually within a larger cybersecurity practice, but focused on looking at understanding how is the application being built today? What is the application composed of? Is the application composed of secure components? Are there any vulnerabilities in that code that we can assess as it's being built? And also being responsible for the code out in production. Understanding are there any vulnerabilities in this code that we need to be aware of? Then collaborating with other folks internally to either work on improving or correcting those vulnerabilities, or putting together other barriers to entry or barriers to exploit for those vulnerabilities in the code. But it's basically an organization that can help look for and understand vulnerabilities in that code. Sometimes in a reactive sense, sometimes in a proactive sense. Like red teaming, where they're looking at applications and environments and proactively trying to look for vulnerabilities or inroads into applications and their data. In terms of software supply chains, it really takes on a view of how software is actually produced today. From where the code originates, either code that's written yourself or code that you're bringing into the organization from outside. Often in open source communities that have developed code that you're borrowing in order to be more efficient. And then how that flows through your environment out into production. And it's basically everything from the code that gets developed, the code that gets borrowed, and the infrastructure that is used to produce that code and get it to market.

**Mike Krass: **So you mentioned developers broadly. Any specific titles that we might see, even though it's a broad definition? Are there certain titles in this handshake with the software supply chain that are involved there?

**Derek Weeks: **Yeah, I think the titles evolve over time. So obviously, there’s software developers, senior software developers, anything up to the CIO within an organization. DevOps engineers. Platform engineering is one of the newer terms being bantered about in the organization. I think the title doesn't matter as much as you know, as a professional, that you are working to get code and application out to the customers and users that you have within your environment. And if you're hands on keyboard, touching that code or touching the environments in which the code lives, that puts you in the development camp for me.

**Mike Krass: **Let's talk about the barriers in the software supply chain to a high functioning relationship. I feel like this is now an advertisement for a Wiley book. Like, you know, Seven Elements of a High Performing Team. Which are books I have read, so I’m not coming down on you, Wiley Publishing. I’m just saying y'all publish a lot of those kinds of books. Let's talk about the barriers. What are barriers to a high functioning handshake in the software supply chain? What gets in the way?

**Derek Weeks: **I think one of the key things… and I've said this for many years. It comes down to awareness of how applications are built and developed today. Developers, I know, recognize how the applications are being built. But the organization has to recognize that applications are not built like they were when I started my career. Literally every application and all the code that you wrote within an application was done within the organization. Your developers wrote 100% of the code that went into the application. And today, that environment or how applications are built has changed significantly. Today, maybe 90% of the code in an application, your organization did not write itself. You borrow that code from someone else that developed it. So you found the code on GitHub, on StackOverflow. Maybe today you’d use generative AI to build code, again, that you didn't write yourself. Or you source it from one of the large open source repositories out there. Like a Maven Central or Ruby Gems repository or Pipeline repository. And you bring that into your organization. So 90% of an application today is code that you didn't write yourself. And if we look at just some of the evidence of this. In public repos like Maven Central that runs or houses all the Java open source components, there were 675 billion download requests from that repository in 2022. By software developers. The only people downloading those components are software developers. And if you imagine there are 50 million software developers in the world, of which maybe 10 or 15 million are Java developers, and they are downloading 600 billion components. There's a huge amount of downloading code that I didn't want to write myself. I'm relying on others that have expertise in that code. I’m downloading it and bringing that into my organization. Now, that's making software developers very efficient in what they're doing. But if we look and turn to the security side of this equation and kind of the handshake, if you will, between these or the partnership between these organizations. Imagine that 10 to 15% of those open source component downloads had a known vulnerability. And they were known vulnerable the day they were downloaded. So you're effectively using parts or borrowing parts. And some of those parts are good, and some of them are bad. And bad from a vulnerability perspective. They could also be bad from being very outdated, working on a version that's three years old that has 50 better or newer versions available. But let's assume it has a vulnerability. Now you're bringing that known defective part into your manufacturing of software. And as a developer, you're thinking I'm more productive. But as a security professional, you're looking at, you just brought a known defective part into our manufacturing process of software. And we should be aware of that. And as an organization, I don't want to stop developers from being more productive. But I don't want to say, let's focus 100% on productivity without worrying about the quality of what we're building. So as an application security professional, a simple question could be, do you know that what you're downloading and borrowing in terms of code that we didn't write ourselves is good or bad? If it's bad, is there an actual known safer, better version of that that we could use so that we're not producing applications that have known vulnerabilities in them today? And really, these are what I would call avoidable vulnerabilities.

**Mike Krass: **How does that conversation take place? I mean, I'm picturing a dark room, an FBI style spotlight, you know, some stale coffee smells. I can't imagine any of that is real though. So I’m asking you, somebody who's been involved in these conversations. How does that go with the developer? Like how do you productively have that conversation?

**Derek Weeks: **First, I think you have to… I'll go back to awareness. The developers know that they're doing this. Does the application security team? Or does the CIO and the IT organization or the business leaders of that organization? Do they recognize that applications are being developed in this manner? And there's a lot of evidence over the years that has pointed to… I mentioned the DevOps community surveys that I did, which pointed to this. And when I was at the Linux Foundation as the chief marketing officer there, I also saw in Linux Foundation research, 35% of organizations build a software bill of materials. What a software bill of materials says is in your application, what components is that application built from? There's code you wrote yourself and there’s code you borrowed. Just to keep it simple, but it will tell you more information. But if only 35% are producing a software bill of materials to tell them what components they're building with, that means 65% of organizations aren't paying attention to what they're building with.

**Mike Krass: **You can’t optimize what you don’t measure. So if 65% don't even know, it's like, well, who knows?

**Derek Weeks: **Exactly. So if you go back to the question that application security professionals want…the basic question you want to answer first is, what components did we use? And were they good or bad? If you don't produce a software bill of materials that says what did we use to produce this application, you don't even have the list. So you can't get to the second question, which is, can we evaluate good or bad from that? And that is something that building awareness of applications are built differently. Everyone out there, every single software development organization, everyone listening to this, their organization has a software supply chain, whether they know it or not. So recognizing that you have one is the first set. So you need to go and explore how are we actually building. And then be able to bring in practices and processes, and even technology and automation to give you some visibility into what it is. And you, you mentioned when you were talking about, there's this dark room and people are trying to evaluate, what did they build with it and so forth. The concept of being able to look at an application and study what's in it, what parts did we use, the idea that you could do that manually was valid a decade ago. But ever since then, there has been so much consumption of borrowed code, it's literally impossible to do from a manual perspective. You have to apply automation to look at the code, understand the parts, and evaluate those parts. Because again, go back to the numbers. Developers worldwide downloaded hundreds of billions of parts. As an enterprise organization. If you're a large bank, large software development house, even a medium sized organization, let's say top 5000 companies in the world that are building software. Your organization is bringing in 300,000-600,000-2 million open source parts a year. You don't have enough people and time to manually evaluate what did we use? Are they good or bad? And to take action on that. So you have to look at this production, software production, is really high velocity manufacturing. Now, if we have high velocity software manufacturing within a software supply chain, how do we evaluate good or bad in that? From an application security perspective, you have to look at, we need to bring in new tooling and automation to help us evaluate the state of good or bad within the organization and our development practices.

**Mike Krass: **Derek, when we were speaking earlier, you mentioned that you are in the process of writing a book. What can our listeners expect to learn from your book when it is published? What are you writing about?

Derek Weeks: Yeah, so this is not a book on cybersecurity or application security. But it's definitely a book about work that I do as a marketing professional and chief marketing officer. The working title of the book is called Unfair Mindshare. It's a CMOs journey into community led marketing in a product led world. But I think that the interesting thing about this is it really talks about how to invigorate and bring a community of people together in an industry to share information, share insights, educate one another, motivate one another, inform one another, and make one another better at either the thing you're pursuing in your personal life or the thing you're pursuing in your professional career. And it's really looking at as a business, how do you work with the communities that surround your business and serve them well, in a way that makes your industry better, your profession better in that practice? And then through that, there are ways to build brand affinity and actually build your business upon those practices. So I explore how businesses can leverage activity within a community, help build those communities, and then help build their business through that work through that associated work and communities. So the book is scheduled to be out summer 2023. It's going through editing as we speak. And I'm really looking forward to sharing that out with the community of marketing professionals that I also work with.

Mike Krass: That's awesome. Derek when it is released, we'll make sure to get a link to that for our listeners in the show notes.

Outro

Mike Krass: And for our listeners. It's that time. That's a wrap for this episode of What's the Problem. We hope you found our conversation with Derek to be insightful, to be informative. I certainly have a list of takeaways. I’m curious to hear about yours. So definitely let us know what takeaways you heard. And remember to tune in next time for more discussions on the latest challenges in the world of cybersecurity. Also, I want to give a quick shout out to our host MKG Marketing. MKG is focused on helping security companies get found, get leads, and close deals. So if your cybersecurity business is struggling to generate leads or closed deals, let us help you. To learn more, you can visit our website at mkgmarketinginc.com. Thanks for listening and don't forget to subscribe and leave a rating for the podcast. We prefer five stars but we also want you to be honest. So let us know how you felt we did today. We appreciate your support. Until next time, my friends.