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 that 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.

I sort of the next generation of monitoring. Tip tools driven by automation and remediation. They can ask hidden questions about the unknown unknowns hidden in your data and what we wanna 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, in DevOps and software development, let us know.

And if you have any questions, that's pure goals, 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 throughout this.

And so again, for, for Twitter, tweet us, for the other platforms, just comment in the stream. So our moderator today, Hilary, is going to be giving those questions back to me. So we really want to hear it from you. We'll 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 closebit. com for a slash blog after this. Now. So let's bring up our, 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,

Hey, this is our crack team. We have Claire burn 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 Sides 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 AirPods, his AirPods today. So I'm sad to see. And then last but not least, we have Josh Brazzers. 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 you guys

snoring. Yeah, so if anybody's wondering, yes, snoring. Hopefully it's not like a guest snoring. So it's so, you know, it's 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 tool? And if so, how many? Because we did hear that people are using like a good few monitoring tools. So yes, we'll, we'll. We'll get that from you. We'll talk about that later. So let's, 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 output. 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 logs, 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 an event occurred and everything, so they're an excellent source of visibility.

Metrics are like quantifiable measurements that reflect the health and performance of your applications and infrastructure. so For example, 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, 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. So with with, with 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, as a pointer as a point of reference when it comes to diagnosing issues, trying to understand the performance of the application.

You know, some of the points that Claire touched on. I. 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, they influence our approach to trying to understand how things are going heavily. And we heavily trying to 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, that's very sad. Like, is it hard to get started? Like, do you have to change your data to when you're, when it's being consumed by these tools? Or do you have to tag everything? What do you have to do?

So I'll take, 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 the 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 Coleman 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. So now what about in, oh, we have some results back. So for about how many tools are you actually using for observability?

So most people are using an observability on 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. Too many tools. Too We have a lot of tools here as well, so we can't look down at anybody. But yeah, so 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 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 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, 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 adjusting it.

And I think this is where this particular webinar really piqued my interest because CloudSmith brings up the, 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, what, when we talk 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? Well, 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, 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, how do we know where log for J is?

Why didn't we know this before? And that's very easy. Okay. 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 cap the log file. It's fine. I

was just configured. I, you know, like, it's like you have an incident and you look back, 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, 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, it's a good question.

There's, there's a lot, there's a lot of work in the space right now. I think what Josh has said is, is very much the case. It's a, it's a novel area, you know Prompted heavily by, you know, incidents of late, such as log for J, such as as as enumerable things.

Right. But we're starting to try and take a, an understanding 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 SBOM. I'm sure Josh knows it inside and out, but it's you know, SBOM is a, is a really, you know, it's a good starting point for some of this stuff because it like to, to, 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 has 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 into build a product.

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 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 Lock4J is 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. BOMs 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 using identifiers, such as PERL or SWIDS or something along those lines.

But, you know, there's there's a variety of other other approaches as well. And generally kind of starting at the source is probably the 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 later something is done about things, the more damage that it tends to the bigger way that it tends to create.

So given given more observability into this stuff from the outset is 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 virtual 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 hand it 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.

It used to be very much the security team was over here. The developers are over here. No one likes each other. And so we're going to avoid one another as much as possible. And, 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, and new startup 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, they're, you know, running the vulnerability scans themselves or using GitHub's Dependabot, for example, they're, they're the ones doing the work.

And I think, What I, 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 with just the amazing product that elastic search is morphed into is it used to be very much like you had 1 group doing all the care and feeding, but now. All the, 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 Engineer. So you're sort of a hybrid role yourself.

Yeah, it's, it's funny because, you, you said that we have guests here from the data, the security, and the engineering world. I'm all three.

I'm, I'm,

I'm dealing dealing with security data. I'm 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, it reflects where the organization of Elastic is going. Because we have both... Security and observability tools in the one product line, 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, seeing as we're, we've kind of touched on vulnerabilities. I don't know, my trusty sidekick there, Hillary, in the background. Ah, 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 you just click our poll. So yeah, we'll talk about that later. So have for for the software supply chain. What kind of Questions do you think that we'll be able to ask?

I'm like, I see an observability deal. I kind of think it's like Alexa be like Am I vulnerable? Alexa 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, just advertising

for it. But it also uses open telemetry anyway. Yeah. Yeah,

exactly. But one cool thing is that you can ingest security data, but then, like, have, 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, into your security.

Into your supply chain. It can tell you, like, if that vulnerability was exploited, and it can tell you, like, who exploited it. If you have your, your logging and observability set up, right? It's just, it's really cool. I really love, I really love where observability tools in general are going on this front, because I think it's presenting a, a unified way of, like, just collating all your data to provide.

Yeah, and do you find in Elastic that you're moving away from the sort of what is it? The visual, not, 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, is that where you see the future? To be, or uh, 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.

Yeah, 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 Thank you. 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 it depends, which is of course the favorite answer to all questions. So I don't see 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 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 SBOMs 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. I thought that time absolutely flew by. I'm just gonna 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 your 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? Of a prize? Is that it? Is that it? Oh! Oh, it's coming in! Okay, so we have free lunches for Gina Davis and Vinnie Machione. I'm so sorry if I'm messing that up. And prize packs for Mike Ameya 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 testament socks, which are Much coveted in, in CloudSmith. So that's pretty cool. So thank you to our guests today. We, I like 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, for listening 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 for coming and listen to us So next month we're talking about oh, we're we're talking to luke hynds from red hat. So stay tuned But thanks again. So this is a proper goodbye now So bye everybody. Talk to you later