 Hey everyone, this is Alan Schumer with Live here at Open Source Security Summit Linux Foundation Austin. We've been here all day for two days now actually. We've been here two days. Hope you are enjoying the coverage. I mean if you haven't quite got the gifts yet, this next interview I think we'll drive it home. This open, this OSS open source summit has become all about open source security, software supply chain security, SBOMs, and I can't think of a better person to discuss it with than the one and only Tracy Reagan. Tracy, welcome. Thank you Alan. Is this the first time we're doing in person? No. This is our first post COVID in person. So Tracy's been a staple during all these long months of COVID. Zooming in from her place in New Mexico, sometimes I feel like we're keeping her from going out riding and doing whatever she does out there in New Mexico, but it's so good to see you in person. Yes, well it really is. I'm so glad to be here. So you know let me ask with this question then what are you doing here? Well I came here, so this is the Open Source Summit, so this is about everything open source, but I was invited to speak on a panel at Open Source Security Foundation Day, which is the open SSF. I know all these open can get kind of confusing. And then I was invited to speak at the supply chain security con tomorrow. So today's kind of my day off. I'm in the middle of between two and I've been attending some sessions and learning a lot. I love it. So let's get something straight, right? Because there are a lot of O's, a lot of S's, and a lot of F's here. Yesterday the Open Source Security Foundation, OSSF, had their sort of conference within the bigger open source summit. We had kind of a community day I would call it. Yes, that's a good way of, I would call it you know a zero-day conference, but that's bad and secure. Yeah. And you are on the board of the OSS. I was, I decided to throw my hat in the ring. I'm a member rep, so you know I have a history of being a member rep for Open Source Foundations. The first time I was a member rep was for the Eclipse Foundation. Actually IBM reached out to me when the Eclipse Foundation was first being started and asked if I would be the member rep. And then I was the member rep for the Continuous Delivery Foundation. And then we moved, when they started talking S-bombs, I'm like oh we're over on the other side now. We're going over to the Open SSF because that's you know kind of my thing. And I went ahead and threw my hat in the ring and I got elected to be another member rep. So you know members out there, I fight for you, believe me, I'm constantly fighting for the members of the- And you know all kidding, you do a great job. You've done it at CDF, you've done it in every organization. But I got to ask a question, will you like the class president in school or anything? No, no, I was not. Come on. You know I wasn't. I didn't want to do that. But when I was probably about, I don't know, I must have been 12, I started a club. Oh really? Yeah, so I was into having a club. You always did. Never in high school. Were you like a sorority? No, God no. I was a competitive gymnast. I had a horse. I was taking music lessons and my parents kept me so busy I didn't have time to do any of that stuff. Really? But here you are. I mean, if there's an organization, Tracy Reagan, you're always willing to help? I love open source and I believe in the community and right now I believe the real problem we have with solving these this difficult situation we find ourselves in with a ton of open source. I called it yesterday in my panel, like you know I said let's think about the open source and all of its connections and all its dependencies. It really is a massive, it's like a death star. And it really is a death star. So we need community to come together to really talk about this. We are in such a flux right now between open source security, which we know we have a problem with, and now cloud native and microservices and a changing CD pipeline that this is time for discussion. You know, I mean facetiously, I think you were the first person to talk to us about this in the last few days. In fact, almost every person has. And you know, and listen, and that's how I learned, right? I'm kind of like an aunt or a bee with them in tenors and I just take in all this information and I try to synthesize it. And as I sit here, right, here's my new kind of reason for this. DevOps, because I'm all about DevOps, DevOps.com. DevOps has been so successful in fundamentally changing the way we build software, right? That we've introduced this concept of software factories and pipelines, microservices as part of that. I mean, when you think back to when my very first company that started in the 90s, when we would have to build software for a customer, you know, a project we would take on project, you know, we were software developers. And I think about what it was like to build software for those customers versus how software is done today. It's night and day, right? We didn't, I didn't realize it back then. I thought I was just young and stupid. But we were building bespoke custom applications or software for every project we did. And every project we did, I mean, there was no VB or even visual basic or anything like that. Every project was coded was coded by hand. Yeah. And you didn't use a lot of open source or shared libraries. Oh, well, a lot of people wouldn't let you if they knew there was open source in there. Oh, no. Yeah, exactly. It violates our licensing and our insurance and our, but anyway, you know, but when we when I think back to those days, versus ways software is built today, where I don't want to say it's Frankenstein, but you just you're pulling in stuff stitching it's about a business agility and speed and being able to stand up new applications as fast as possible has is the focus, which is what started really pushing open source because you know, who wants to go if you already have beautiful graphs, you don't want to write them scratch, just go find something out a library. But this is it's accelerated. I think DevOps and the whole agile and you know, these kinds of things have accelerated that. But it's also introduced the concept of supply chain security. Yes, who who wrote it? Is it secure? It should I trust it? So we have so many options now, we have so much open source out there that we can borrow from. Now we're realizing that we really do need to and I hate using this analogy, but it's appropriate. We need to be able to list our ingredients. Yep. And it comes, you know, I've been talking to a few of the government folks. Because in that supply chain discussion, you know, I when I think about it, it's like, what's the first thing we have to solve? To me, the first thing we have to solve if the house is on fire response, we need to have a good way to create a response. If there is something like another log for Jay, I don't want to hear about it because a new CVE came up or I saw it on Twitter. I want to know in a better way. And that you know, that's kind of my dream is that someday we will have a, you know, that's what we're working with on Artilius a unified place. So that you go and register if you're you're you've written something open source, you go and register you register who you are so that we can begin that trust story. And you can begin tracking the S bomb of that object that may be consuming other open source, right, components, which it's going to do, which is why we have this crazy dependency map. And it's very difficult to sort out the you traverse down. It's a rabbit hole you get to when you see all the different open source tools that you're using. And then that one way down there may have been using log for Jay, which then it can expose you all the way up the up the chain. So it's a good to cut. It's a really good discussion for us to start having. But to be quite honest, we are starting to break that, even though we're just now having this in a monolithic world, microservices does change that a little bit. Absolutely. So it doesn't change. I think it complicates it. Because now it, like you said, Oh, well, it might have locked for Jay way down here, a third party's third party, third party. Well, with microservices, and you have dozens of microservices, each one of them, and so on and so on and so on. Right. The problem becomes infinitely harder to solve. You almost look at it and say, Well, Jesus, I was just dealing with one thing monolithic right here. Well, if you just deal with one component right here and break it down, if we can get it broke down to individual components, that you know, it's like going into Home Depot, you've there's a there's a giant door of parts and pieces. And you go and you find exactly the party, right? One bite at a time. And so that's what you got to ask what you have. Because otherwise it'll scare the crap out of you. You just run away and say, Let me find a different to me. I think everybody should be thinking of components. We have a I want to call it a component driven architecture, because that's what we're moving into. And components are consuming other components. But we have to start breaking those components apart. And over time, this is not going to happen soon. But over time, we have to start decoupling this. Because one, one, it may be the case that you didn't really need that library in there was just stuck in there because somebody thought it needed to be there. And then you have a vulnerability for no apparent reason. And that does happen. There are dependencies that are unnecessary. And as soon as we start figuring out a way to centralize the data and be able to slowly break apart some of those components and decouple it, especially if we do that for like the top 200 open source projects, right? Open source libraries, then we'll start making progress. I feel like we have to we have to take that on and we have to be absolutely have to be accountable for it. So to me, there's two things here. Number one, and I'm actually looking forward to talking to our friends from JFrog about this is, I really think when so many of these components make their way into our software from being downloaded from repositories, there's got to be some responsibility or not so much, there's got to be an advantage to repo owners who are more responsible about what gets downloaded from their repo, right? Yes, but it's hard. It's a hard place to get it. It's a hard place to get it. But we've got to put this going to be choke points in on this. Yes. Well, developers don't do well with their game. Okay. I'm not joking. But you know, there's got to be gates places where we can get stuff of where we can regulate this. You know, I hesitate to agree with you because we fought so hard to break the gates down so we can move faster because again, we get back to this is a business agility discussion is I feel it's more, it's more like accessibility and visibility and information and appropriately using the tools we have. We're so much dev office intelligence underneath the device automation. Here's the deal and reporting. Let's take something old. Let's take struts to from Equifax, right? The Equifax culprit. Yeah. I believe wasn't that in the Sona type repository, Nessus? The problem with Equifax was they knew they had a problem, but they had too many gates to get it to production. Yeah, and that that is an issue. So then we're about breaking down the gates so we can get six to eight months after Equifax, people are still downloading and using that old version of struts. Why? Why? Why is it even on the repo? Shouldn't there be you know when you're using your browser and you go to a site that might be unsafe? My wife will call me with this all the time. I got a message. I'm going to an unsafe site, but I need to get to the site. My first thing is usually did you type the address right? But that being said, why can't I digress? Why can't we build? Why can't we build a warning like that? I believe that we should do that. I totally do. I mean, that seems like no brainer ish to me. Yeah. And you have to keep you have to think of it as historical too. Yeah. Because you have to know what versions of that. Hey, Tracy, our records indicate you downloaded of this component, which has now been, whatever the word is, degenerated, that was the word. So don't you don't do that. It might hurt. I know. I know. Why can't we you know? Because there may be a dependency on that that somebody needs. I get it, but at least I made you aware of it. And now you manage that. I know. I agree completely. There should be there should be accessibility. Did you hear this? She agrees completely. I because that's what we're trying to do with Ortelius, a central place for you to go and so that you can see for every version all the vulnerabilities. So I can make that decision if I want to use that in the same way as we now make a decision. If you want to put a mask on when you get on a plane, it's the same thing. You have to be able to make that decision. The problem is there's not a central place to get that information and it's not historical. It's not often built based on versions. So you can't see the vulnerability. You can't see the level of the vulnerability. It's it's you can find it if you work hard at it, but it's not just well the whole level of vulnerability thing is I think also look I was there with my my friend Bob Martin from MITRE at RSA one year announced the whole CVE thing and rating of vulnerabilities. What a great idea it was back then. But what I've come to understand in the year since and that was 15 20 years ago. What I've come to understand since then is just because it's a critical vulnerability to me. It may not be a critical vulnerability to you. For you may have done things that kind of deflect the the severity. I might not be using it as something that has a high risk value. Or it may not be accessible to the outside world. It may be there's a there's a lot of reasons. So it's very hard to say something is a high critical to everyone. I think it depends I think and that you know so I'm so I'm not a complete socialist right. I think individuals or individual organizations should have the ability to determine for themselves. But they have to have the data to do it. And this is the problem. And that's that's the data is the problem. It's out there but it's hard to find if you don't have something already automated you're asking your developers to look for those vulnerabilities before they release it. And they've got other things that they've got to do so we need it we need it served easy to us we're you we're becoming very lazy when it comes to to digging that kind of stuff up. I mean you know if I if I'm on my phone and I go to download an app and it gives me any hassle I just go find another app. I agree with you. So we have to make it we have to serve we have to serve the data up in a way that is in their face and it's easy to get to. And that's that's that's the challenge. And that starts with S-bombs because you have to have the S-bomb before you can find the vulnerability right you have to know what's in your package and to know what vulnerabilities to look for. And that's even a challenge for some teams because if you're right if you've written a manual kind of make process or build process or scripted process whatever you're building your packages you need to include all of that scanning and you know call something like sift or cyclone to create that information. And if somebody's not telling you to do it it's probably not going to because you got other things to do you're a developer you have your hands full. We all have right we have a design of hours in the day. So the automation is critical and it would be great to have some kind of again my complaint continues to be if if we have a fire in New Mexico we have a incident response system that starts to handle it from the very beginning you somebody who is in charge of that right now if we have a fire in software we don't have a central incident response. It's more like Florida. And you said it not me. So we need to work on that and that's again being getting the data having the data accessible and easy to access. Absolutely. Tracy Reagan it is a pleasure to see you in person. Pleasure I I always love doing these chats. I know you do but it's just nice to be in person with you and not have you up on my monitor in the studio there. And we didn't we didn't talk about continuous delivery. Now we did it. And you know what I was surprised I haven't seen more CDF presents. Well I wore my t-shirt. I see I do see you have that. That was two weeks ago. Yes it was. And you know that in the CD world things that you should be asking people as you're doing these interviews you start asking them about CD events. Because events are going to change the way our CD pipelines are. Not CD conferences events within that CD pipeline. Correct it correct because think about this think about you want to add S-bomb and vulnerability scans to your pipeline and you have two thousand workflows that you have to update. Are you really going to do it? No. No you're not going to. But if as we evolve through this we have to work on the automation and the event CD events having a single listener where everybody integrates in a similar way and there's a payload that you pass across based on an event like cloud events that's going to prevent people from having to write these very imperative pipelines and it'll get us there faster. CD events you heard about it here first from my friend Jay-Z. All right we're going to take a break we'll be back I think we've got some folks from IBM some folks from JFrog still got plenty more to do today here in Austin we'll be right back