 Today on our webinar, we're going to be talking about securing your software supply chain using observability hot new topic. So we've assembled our panel of experts from software security and data to talk about observability and what it means to your software supply chain. So when we talk about your software supply chain, we're talking about all the steps to go back go into building your software, all your third party dependencies, your open source data. And we and there's a huge amount of risk involved in your software supply chain. Even a small application can have thousands of dependencies. Securing your software supply chain means having visibility into your supply chain and how that software is built. And this is where observability can come into play. Observability tools are the next generation of monitoring tools driven by automation and remediation. They can ask hidden questions about the unknown unknowns hidden in your data. And what we want to know, what can this do for your software supply chain? Hopefully it can help us secure it. So today we want to hear from you. We want to hear who you are, where you're coming from, what kind of work do you do? Do you work in SRE and DevOps and software development? Let us know. And if you have any questions, that's pure gold. So we want to hear all that. If you're on our streaming platform, it's really obvious what you do. But if you're on Twitter, tweet us. If you're on Facebook, YouTube, LinkedIn, comment in our stream. So we're going to be conducting polls, a few polls right this. And so again, for Twitter, tweet us for the other platforms, just comment in the stream. So our moderator today, Hillary, is going to be giving those questions back to me. So we really want to hear it from you. We're also going to be randomly drawing a few prizes. There's two prize packs and two free lunches at the end of this webinar. So stay till the end, if you can. And if you want to watch this on demand, you can go to www.clayswood.com for a slash blog after this. Now, so let's bring up our three guests. This is who we, this is what it's all about. So if you can come on stage, don't be shy. Hey. This is our crack team. We have Claire Byrne from the data world. She's our data magic practitioner. She's a software security, she's a security data engineer from Elastic working in Belfast, but she's also a community organizer and collaborator in the tech industry. She's the founder of Women Tech, Women Techmakers Belfast and the co-organizer of Security B Besides Belfast. Then we have Tom Gibson, our senior staff engineer from CloudSmith. If you hear his dog snoring in the background, don't worry. It's actually, I think he's wearing his earpods, his earpods today. So I'm sad to see. Last but not least, we have Josh Brezers. He's the VP of security from Anchor. He's also a blogger and a podcaster from open source security podcast. And he's someone who's been talking about your software supply chain before it was cool. So thanks everybody for joining us. I'm really happy to have you guys today to tell us about what you think of observability and your software supply. I actually can hear your dog snoring. That is someone snoring. Hopefully it's not like a guest snoring. So it's, you know, it's a step up. So before we, let's start with getting some feedback from our people listening. We want to, if you can participate in the poll and again, if you're on Twitter, you tweet, if you're on LinkedIn, if you're on YouTube or Facebook, you just comment in the stream. So our first polling question is, are you currently using observability or monitoring tools? And if so, how many? Because we did hear that people are using like a good few monitoring tools. So yes, we'll get that from you. We'll talk about that later. So let's crack on with our, with our first question. So I thought I'd put the first question to Claire. So I want to know like, what is observability and how is it like different to those traditional data monitoring tools? Yeah. So observability is more or less defined as being able to judge the state of the system based on its outputs and gain actionable insights into the state of your tools, like root cause analysis of issues and context into why your software is behaving like it is. So for most observability use cases, three types of data matter the most, blogs, metrics and traces, because these can provide a sort of holistic picture of your, your organization's resources. So yeah, as most of you already know, like logs or files that report events, contextual information, and such as the time and event occurred and everything. So they're an excellent source of visibility. And metrics are like quantifiable measurements that reflect the health and performance of your applications and infrastructure. And so for example, see CPU or memory resources. And traces are like is data that tracks an application request as it flows through the various parts of an application. So like for example, recording how long it takes each application component to process a request and pass the result to the next component. Yeah. And Tom, like software developers traditionally use these kind of like they're already using observability tools. I'm sure we are in Kitesmith and they're kind of more used for like checking if you're available and sort of performance issues. Is that is that right? It's like that's what's the main? Yeah, I think it's certainly an element of it. Like certainly our own internal use case, as is the case with many, many other organizations, we, we rely heavily on observability platforms to help indicate to us the health of the service. And use it almost as a pointer as a point of reference when it comes to diagnosing issues, trying to understand the performance of the application that, you know, some of the points that Claire touched on and mentioned about the pillars and traces being one of them. That's probably our bread and butter aside from the log side of things and all that, you know, they, they influence our approach to trying to understand how things are going heavily. And we heavily try and instrument all parts of the service and leverage distributed tracing across the board where we can. It makes, makes a big difference. Yeah, like and if you're currently like tailing logs to get this information, very sad. Like is it hard to get started? Like you have to change your data to when you're, when it's being consumed by these tools or you have to tag everything? What you have to do? Um, so I'll take that one. So in general, you'll want to, you'll want to send your logs to your observability tool, but in general, it will perform heavy lifting for you. It can like aggregate and filter and organize your logs or whatever based on a schema that you define. So for example, in elastic, there's elastic common schema, which you can, you can like orchestrate yourself. Oh, cool. So you can set up your own schema. Like if you don't need to change how you're currently logging stuff, like yeah, cool. Okay. Uh, so now, um, what about in, oh, we have some results back. So about how many tools are you actually using for observability? So most people are using an observability and one or two. So that's, that's pretty good. But some people are using over five observability tools. That seems like a lot. That's a lot of tools. Too many tools. So we have a lot of tools here as well. So we, we, we can't look down at anybody. But yeah. So, um, so moving on. So what, what problems are security teams using observability tools for? Like even like the wider security problem, maybe Josh, you can kind of help us out there. Sorry, Josh. I'm just wondering. No, no worries. No worries. I mean, so that's, that's a great question. I think this is where you can kind of look at some of the work elastic has done. So kind of full disclosure. I was previously at elastic before coming to Anchor. So I've got a great deal of love in my heart for everything they're doing. It's, it's, it's a fantastic company and product. But when we think about observability, there's often this kind of focus on logs and logs are super important. I'm not going to say they're not. And obviously, if you look at the history of nearly every modern observability tool, it has its roots in logging. But we also realized some time ago that we can start ingesting all this extra data. You can bring in observability data. You can bring in things like data from your SIM, your security, security incident event monitor. I forget what SIM stands for. It's been a long day, but there's things like your firewall details. You've got bits and pieces from network monitoring tools from, from your antivirus from like a million places, anywhere you can get the data from, you can now start bringing this in and justing it. And I think this is where this particular webinar really piqued my interest because CloudSmith brings up the supply chain and observability. And I'm like, this is a perfect fit because when we think about our software and our supply chain, it's just part of the data because the data all comes together and tells a story, right? And your software supply chain is part of that story that to date, I would say has not been getting the attention in this way that I think it should be. And so I'm very excited to see where this can go. And like, well, we talked about the software supply chain. What are the elements in it? And why is it, why is it so risky? Why, why is it difficult to find out what components are in your software? It seems like we should know that. Well, I mean, okay, it is easy to say that, but I don't think that is necessarily how, how this has worked out over time. If we look at, I'll pick on log for J, right? Because that's all, we all remember log for J, like it was yesterday. And we have this incident and then everyone says, how can we, how do we know we're log for J? Why didn't we know this before? And that's very easy to kind of pick on and say, we should have known this. But the reality is, I mean, it's just part of maturing every organization. I mean, there was a time we didn't have logs from all of our computers, right? All of the servers in the server room, no one knows, whatever, just SSH in and cat the log file, it's fine. I was just configured. I, you know, like, it was like, you have an incident and you look back and you're like, Oh, we didn't have that turned on. Exactly. Exactly that. And that doesn't cut it anymore, right? And that's fine. That is just how all of this works together. And so I think from the supply chain perspective, it is relatively new. And we have a lot of learning to do. And I just think putting all these pieces together is, is the next step where don't say, why weren't we doing this? Because, well, we just weren't. So who cares? Like, how do we start? I think is the better question to start asking. Yeah. And so, Tom, what kind of data should we start generating in order to answer some of these questions? Yeah, that's a good question. There's, there's a lot, there's a lot of work in the space, right? I think what Josh just said is very much the case. It's a novel area, you know, prompted heavily by, you know, incidents of such as love for Jay, such as as well, innumerable things, right? But we're starting to try and take a, an understanding now of what goes into a piece of software and what that actually means for us. So today, you know, there's, there's a variety of ways we can do that. Some of our audience will have heard the term S-bomb. I'm sure Josh knows it inside and out. But it's, you know, S-bomb is a, is a really, you know, is a good starting point for some of this stuff, because to take it back a little bit, we're talking about a bill of materials for software. So essentially, you know, the manufacturing industry, and I've used this on several webinars now, so apologies for anyone else who's seen this, but, you know, the manufacturing industry has, has used bills of materials for a very long time. You know, there has to be an awareness and an understanding of what goes in to build a product. A manufacturer of a mobile device, for example, they, they understand it's made up of a, of a display of some sort components that make up the main board and speaker, that kind of thing. And they'll source those components from external and some of those they'll build in-house. Software is no different in that respect. We're looking at pieces of software that can be sourced from the public domain by great contributors out there, as well as other organizations. And the, whilst that's amazing, it also brings an element of, I wouldn't necessarily say distrust, but certainly deserving of a bit more scrutiny. And I love for Jes a very good example of that, you know, it's heavily used across the board in a variety of different projects. And I think to get that sort of information into your observability pipeline, bombs are a really good place to start. You've got information in there containing things like the third party dependencies. You know, those, those are usually referred to as identifiers such as Perl or Swids or something along those lines. But, you know, there's a variety of other approaches as well. And generally, kind of starting at the sources, probably, like they talk about shift left security, right? You've heard it many, many times, many of us have, but it's true in the sense that, you know, the, the, the later something is done about things that the more damage that it tends to take to the bigger way that it tends to create. So given, given more observability into this stuff from the outset, it's no bad thing. And, you know, we can, such information vulnerabilities, for example, about, about third party dependencies, the number of third party dependencies. This is all information that tends to be produced by these reports. And they make great candidates for injecting into observability and treating like anything else that goes into those platforms. We can model SLOs or sorry, SLIs about those. We can track things on alerts and alarms. We can do license compliance checking. All this kind of useful stuff that's very useful for security teams. But I think in general, we're starting to see an approach that security doesn't just rest with security teams. We're starting to see it that it's becoming a practice across both security data and engineering teams as well and disciplines. And I think that's important to continue. Yeah, actually, Josh, coming from the security space, do you find that like your security teams are working closer with your developers? Or is it like, oh, we set the policies we just handed to the developers? Is there more, is there more communication there now? I think there is. I think we've seen a definite shift over the last probably 10 to 20 years of it used to be very much the security team is over here, the developers are over here, doing like each other. And so we're going to avoid one another as much as possible. And that's definitely not what I see anymore. But I think more importantly even is when you look at some of the kind of smaller and new start-up-y type organizations that might have only a dozen people, you're seeing the developers kind of doing a lot of this legwork where they're running the vulnerability scans themselves or using GitHub's Dependabot, for example, they're the ones doing the work. And I think what the vision I have is that we make a lot of this tooling so easy and so good that you don't need a security team like doing all the work. The security team is there to define policy and help with problems. But fundamentally, you're going to see the developers actually kind of picking this up. And I mean, I'd even kick this over to Elastic is this is exactly what you're seeing with just the amazing product that Elastic Search has morphed into is it used to be very much like you had one group doing all the care and feeding. But now, I mean, Claire can certainly comment on this. Now you're seeing the individual business units and groups actually doing the data analysis and adjusting the data, which is amazing. And actually, Claire's title is like data security engineers. So you're sort of a hybrid role yourself. Yeah, it's funny because you said that we have guests here from the data, the security and the engineering world. I'm all free. But yeah, I'm dealing with security data and dealing with the architecture of that data. I'm dealing with like software engineering problems on a daily basis. And that kind of reflects on an individual basis that reflects where the organization of Elastic is going, because we have both security and observability tools in the one product and it's really cool because security like monitoring security means monitoring your data nowadays, because there's just so much data everywhere. Absolutely. And actually, let's start our next poll soon as we're we've kind of touched on vulnerabilities. I don't know my trusty sidekick there, Hillary in the background. See that? It's magic. So our next poll is on are you happy with your workflow for finding vulnerabilities in your software supply chain? So it's a touchy topic. So if you're on Twitter, tweet us what you think. If you're on LinkedIn, YouTube, Facebook, comment in the stream, or if you're on our platform, you just click our poll. So yeah, we'll talk about that later. So for the software supply chain, what kind of questions do you think that we'll be able to ask and observe? I'm like, I see an observability detail. I kind of think it's like Alexa be like, am I vulnerable? Alex, I don't know. That's my dream. So Claire, can you imagine like, say you get all this data in, this new vulnerability pops up? Are these kind of these questions that you can ask your vulnerability tool that were not necessarily thought of as you were generating the data? So yes, absolutely. So I can only talk about what I know, which is Elastic. So I promise I'm not like just advertising. But Elastic is open to chemistry anyway. So you kind of, it's more generic anyway. Yeah, exactly. But one cool thing is that you can ingest security data, but then like have that all correlated within the observability product. So like it can tell you like, it can pinpoint when exactly a vulnerability like was introduced into your security into your supply chain. It can tell you like, it's a vulnerability is exploited. And it can tell you like, who exploited it. If you have your logging and observability set up right. It's just, it's really cool. And I really love, I really love where observability tools in general are going on this front, because I think it's presenting a unified way of like just collecting all your data to provide a defense basically. Yeah. And to find in Elastic that you're moving away from the sort of, what is the visual light? Not moving away from visualization, but these dashboards, is it more about like remediation and automation as opposed to something actionable rather than displaying on a dashboard and have someone monitor that? Like is that where you see the future to be or? Yes, absolutely. So for example, in Elastic security, you can open cases and like trace where a vulnerability is happening. Like I said, and you know, like log, like data as you find it. So you can basically set up a security remediation case, like as you, as you find it, you know, and it means that analysts don't have to, you know, stare at dashboards all day and, you know, get alert for proof and everything. So that kind of automation is really, really useful. Just helps to provide a layered, layered defense model, I guess. Yes, yeah. So, and Josh, do you think like in the future, using these observable observability tools that would actually be able to like prevent a supply chain attack? So supply chain attack is something that it's an attack on your supply chain. So maybe it's malware and your dependency, or it's a vulnerability that's exploitable. So, and do you think that using these tools, having this visibility, having these sort of like machine learning tools, could they prevent an attack? Or is it all about detection and fixing it as quickly as possible? So I would answer your question with a, it depends, which is of course the favorite answer to all questions. So I don't see a lot of observability tools directly stopping an attack in the regards you might think of where an attacker is actually like coming in and doing a thing. And then you have a tool paying attention because prevention in that regard is actually very, very difficult to do. I'm not going to say it's impossible, but it is incredibly hard. But I would say from the concept of preventing a bad thing, I would think of it more as when you have tools that are paying attention to what's going on, you can, for example, say, okay, I see this vulnerability just appeared in my product before I shipped it. Now I can use that knowledge to prevent a vulnerability from entering my supply chain, essentially. And then, but I mean, you could, is that stopping it? I mean, we could argue that probably for hours, but there's, I think that aspect of it. And then there's also the angle of, for example, you might have a developer who includes a dependency that then pulls in hundreds of other dependencies beneath it. And so you can look at your tools and say, whoa, why did we just pick up 700 dependencies yesterday? Something weird is going on. And that's another example where, obviously, as you add more dependencies in your supply chain, you're increasing your risk. And so it's not about necessarily like prevention as much as understanding risk. And once you understand your risk, now you can start to control your risk. And so I think that's probably a better way to think of it. Do you think people are going to start making decisions like, I'm going to try to cut down the number of dependencies I have in my product? Is that like something people are going to do? Definitely. I think everyone I know, as soon as they start generating espoms and they look at the data, the first thing they say is where did all this stuff come from? Every single person. And then obviously, but again, once you have data, you can start asking intelligent questions and solving problems, which is why data is magic. And it's amazing. So, oh, we have some of the results of the poll. So the question was, are you happy with your workflow for finding vulnerabilities in your software supply chain? And most people said yes. So, bully to you. Yeah, we must have a security focused audience or part of you. Yeah. So that's great. And so it's like, it's like five minutes to go. That time absolutely flew by. I'm just going to check if we have our, oh, can I just say my favorite comment was from Jason, you need observability tools to observe the output of the observability tools, which is what we're all thinking about. So there's that. It's just turtles all the way down. So let's see. Hilary, can we get a winner? Off a prize? Is that it? Is that it? Oh, oh, it's coming in. Okay. So we have free lunches for Judah Davis and Vinnie Mashione. I'm so sorry if I'm messing that up. And prize packs for Mike Amaya and Chrissy Sutton. Oh, that's so nice. So that's brilliant. I hope you enjoy your free lunch and your prize pack. Apparently the prize pack has the Kleismith socks, which are much coveted in Kleismith. So, and that's pretty cool. So thank you to our guests today. I loved chatting to you. I could talk to you all day long. Really appreciate you coming for all your insights and everything. And I'd just like to say thanks to everybody for listing about observability. I hope you had an idea about how you can use observability to secure your supply chain and learn the new things about your supply chain that maybe you didn't know that you had to ask when you collected all this data. So thanks so much. And thanks for everybody for coming and listening to us. So next month we're talking about, oh, we're talking to Luke Owens from Red Hat. So stay tuned. But thanks again. This is a proper goodbye now. Bye, everybody. Talk to you later.