 Great, thank you everyone for joining. So we're going to talk about shift left and the value of knowing what's in the software that you're running across your environments, as well as some of the license compliance issues that you might run into. As mentioned, I'm Taylor Smith. I'm a senior product marketer here and I'm here with Ashley Ward. Hello all. So applications today are assembled more than they're built and what I mean by this is if you've ever seen or talked to anyone from a major car company, you hear about how most of the parts are not actually made by the major manufacturers. So like think of GM or I don't know, Ashley, maybe Jaguar in the UK. Most of the parts are the doors, the handles. All those parts are not actually made by those companies. They're made by some subsidiary or another third party and they bring them all together in the GM factory to actually form the car that you can drive off a lot. And that's a lot like how software is built today. So Forrester did a study where they found there was only 1% of code bases out there that didn't have some sort of open source component. So all the rest of them had a major portion of it up to 70% were made up of open source components. So they took stuff off the shelf from open source, pieced it together to make their applications, make something that you can enjoy like a hotel booking site. And the reason why they're doing that is because it's easy, fast, safe and extensible to use open source. You can just grab things off the shelf. You know that it works. You don't have to reinvent the wheel and it's a lot faster than writing all that code by yourself. It's vetted by the community and it's extensible because it's open source. So there's nothing you don't have to worry about taking that code and not knowing what's how it works on the inside because it's fully open source. Now those last two, the safe and extensible, those can, those are great, but it means there are some implications of that and we'll go into that in a bit. So what happens when you add an open source component? So I have four different languages here and how they work and they're slightly different. So if you add a package to Node or Python, they're statically linked. So they'll import all of the data in, they'll compile it just as if it was part of the proprietary code. Now Java is kind of a funny, so sorry to pack it up and Node, you might have seen if you're building a container, the package.json or in Python, the requirements.txt, these are all the different components, open source components that need to be installed prior to running this application. And now in Java, it's slightly different because you actually have them built out in a tree structure. So all the components are built in there and then it's compiled and then go, it depends on the build manager you have. So some build managers work just like Python or Node where they'll grab different packages and bring them in or some of them just tree through the import statements you have and install those and then compile it. And so all that code is in there in the package with you. And I'm gonna jump over, make sure you, Ashley, can you see the demo screen? Yeah, I can. Awesome. So all that code is in there. Oh, actually, I think my apologies. That's your cue, Ashley. Oh, would you look at that? I thought you were going to do it for me and then send me to that. Steal your thunder, my apologies. Very little thunder. No, I mean, so Taylor's absolutely right. And when we do this for an audience, obviously the Linux foundation, everybody's there going, well, we know open source, we know this, this is so very important. It is something where though people come along and this can be new to them. I mean, certainly when I'm back in the bad old days as an operations guy, moving from my cozy little world of Solaris and big sun micro systems machines to then running Linux and going, wow, there's an awful lot of moving parts and there's a lot of different communities involved. And so for me, it's about level setting and saying, okay, well, listen, everybody that's here, we know this, you probably know this, but let's talk through it anyway so that we can understand where the issues might arise. So the magic of course is that if we're using open source and we have that source code that actually it's made up of lots of little bits. So we don't get rid of any complexity. We just shifted around a little bit. So yes, we don't have to write everything from scratch, but actually by making use of other components, there's still components that we need to feed and water and look after. So Taylor had mentioned a package.json. So here's one here, I'm in my terminal because it makes me look very cool. But I'm in my terminal, we can see here, I've got checked out microservices demo, I've got some source code there for the payment service and I've just done a nice little cat of that package.json. So for those of you who don't know, and apologies if you do already know, what we can do is we can specify things like saying, well, I don't want to always have a hard coded version in here. I just want to say I want this version or later when it comes to building my application. So that's where we can see that we have this lovely little party hat as I remember getting told they were, but that may just means here that in fact, we can accept minimum version of three to one. So three being the major release, two being the minor release, one being revision and sometimes you can have other characters in there for the revision. But what we're saying here is that the minimum is three to one. So if there's a three to two available though, we'll take that. Or if there's a three, three to available, then we'll take that as well. You can also have tilde's in there that are going to say we want higher revisions but not higher minor releases. So the point being that we don't actually know what version we're going to get in there. And that's important when we're looking at things like vulnerabilities. So if I try and do that again, but this time look at my keys and pop in that I want to look at the lock.json. Let's see if I've managed to do that correctly. I've not because I've put in an extra dot. Thanks for shouting there for me and telling me that I'd missed that Taylor. I remember that. So here we have the lock file. Now that one, the lock file is what's actually been included. So for the example I was using, which was UUID, I can jump up here and I can see that it's three to one was the minimum and actually it's three, four, zero that's in there. What does this mean? Well, this is just so that we can understand what's all involved in our package. And so when we want to scan that for security, actually what we can say is, let's bring up a nice little scanning tool. Our nice little scanning tool. I'm going to scan here and I'll talk you through what I've put just so you're aware. It's going to be a little bit ugly because the size of font that I'm using for this show, but I'm using my scanning tool twist CLI. I'm saying I want to scan the code repo that I have checked out. So that raw code and I want to scan it. That's the scan there. The options, just the authentication, the token or whatever I need for that. And I've said, please tell me the details of whatever it is. Now in this case, I've specified exactly to the service I want to scan, although I could have done this for the whole kit and caboodle, but that would have really spread an awful lot of stuff on my screen. So what we're saying is, okay, in this repo that I have checked out, there are vulnerabilities and I do apologize for the way that this has appeared on the terminal. Obviously, if you're not got it at a normal size, it looks very pretty, but we've got a critical vulnerability here. It was fixed quite a while ago. We've got the version that fixes it and we've got the details of what that means. And so being able to do this straight away with just the source code is incredibly valuable. If I do again, let's actually do microservices very quickly. I can see Taylor's going to be like that. Will you hurry up? You silly Scotsman, this is taking too long. If I come over here and let's just take away some of the details, do, do, do, do, I will remove this and I will do this. And so this is a much bigger scan. I've gotten rid of the details. So it's just going to bring it up, but we could, if we want to just say, just show me what the actual results are. Okay. So we've had a look there at actual my repo and saying, what is it that's inside of that? Let's get a report. We could have been pointing that actually at a GitHub repo, actually something that's remote. This was local. We could be doing it a number of different ways, but at this point, we have these opportunities to see what's in there. So the problem with all of this, of course, with vulnerabilities that are there is that the exploits come before the patches are released. Gartner estimates that over 70% of applications contain flaws stemming from open source components. Now, this sounds like that big scary thing. It's not. This is really good that we're using all these open source components and that we can see these vulnerabilities out there. 80% of public exploits are published before the CVEs are published. On average, an exploit is published 23 days before the CVE is published. That's all from our Unit 42 Threat Research Department. But even if you were to say, Ashley, you're a security vendor. I don't listen to you. You're talking nonsense. Actually, we all know that the real life way that we do patching is like this. And that's simply because once the patch is created, then it does have to go through some form of testing. We do have to put it through change control. There will be some sort of organization for patching resources. Yes, we want to have all these things automated and that's only possible if we're using the tools that can accommodate that. The average organization takes over a week to patch open source vulnerability. Think back, we all know of them and I'm sure that anyone who's worked in enterprise would be able to say examples to me about they know that machine that's sitting spinning that isn't patched or that service that's been running. Equifax Breach in 2017 was Apache structs and there was a fixed two months prior. And then the last one and I'm going to read my notes here because I really enjoy this one. There was a Node.js, it was the event stream module. Now this was an example of social engineering rather than an attack that we in IT would normally be comfortable with. Social engineering, someone got in touch with the maintainer of that module. And the maintainer said, and this is where I'm, you're going to see me look at my notes, this is the quote from the original developer. He emailed me and said he wanted to maintain the module. So I gave it to him. I don't get anything from maintaining this module I don't even use it anymore and haven't for years. And that instance, somebody social engineered their way into a popular module that was being used and managed to put in some nasty stuff to do with crypto mining. And that's just us looking at vulnerabilities. We've got, you know, there's a lot of different things that you need to look at and worry about. And of course licensing then comes in as the next part. So licensing, open source licensing. I used to think this was a big fear exercise from a lot of people, but actually this has been tested in the courts in Germany. And so organizations actually have to pay a lot of attention to the open source licensing that they're using because there are real world consequences. It's not just some sort of theoretical breaking of licenses, not that anyone would want to do that intentionally anyway. But think about it, you've got copy left licensing in which case you need to be able to publish the code that's being used, the GNU general public licenses as an example. There's also the lesser general public license that's there. The Apache 2.0 where you need to have attribution and some custom rules around there. And then even simple ones like MIT license and Eclipse public license, the list goes on and on. And so you need to be able to have visibility into these different licenses and be able to say what your organization is willing to accommodate. And at that, I will now hand over to Taylor. Yeah, and that's very appropriate timing with the change in license that Grafana is going through. And so a lot of people are experiencing this and trying to understand the licenses. What does it mean that they've switched to an HGPL license? And it casts up all those different ones where then when you read into that and people are going, well, I'm surprised they didn't go for this other license that another organization went for it. I don't think I'm giving away too much by saying that. And there's all that different conflicting information. Anyway, sorry for jumping into it, go ahead. No, that's great. And yeah, absolutely. You do look at all the different licenses available and you wonder why people picked one over the other. And now even some are talking about modifying some of the existing licenses. So we're just making it more complex and understanding that. So just to give an example, this is just going through an example, but you can set up alert and failure thresholds with a software composition analysis tool where you can take all those licenses and you can say the ones that are copy left, maybe alert on those, maybe even fail builds that have the copy left licenses. And the ones that are low like MIT and Apache 2 that are very open, very free to use, maybe just alert on those because you still need to give attribution. So if you go into the licenses of the tools that you're using, even the proprietary tools like ours, you can go in, there's license attribution section. You can see all the tools that we're using in our application that we need to give attribution for. And if you don't give attribution, that's when you can get in trouble. And so it's just really important to know those licenses that you have. And if you look, so these are just the A's. There's a whole bunch. And then you add in like, if I start to filter down to just the GPL licenses, there's still a whole lot and different variants. So keeping track of all of that is a job in itself. And that's not something you should be doing if you're a developer. And just to give another view of that, if I go into a running application and here I have the classic SOC shop with an Ingress gateway, an Android X1. And if I click on one of the applications, I can see that there are a whole bunch of vulnerabilities in my application. And I can see some of those are applications I've installed, but also some of them are my open source components. So I can open up one of these and I can see a similar view to what Ashley was showing, where I have the package, the vulnerability, how it was fixed over two years ago. That's something I should address. And just knowing the posture of the components you're using is super important. Knowing what you have in your environment, putting in those guardrails so you can block the vulnerability levels that you don't wanna have, as well as the licenses that don't meet your company or your country's level of licensing that they allow. Just going into the package info you can get more of that licensing. So you can see some of these components are GPL based. And so just having that runtime view, but also as Ashley showed, back in the CLI early for developers, getting that view of what components they're using, should they be using it? And really knowing these are the different components we have, the software bill of materials as they build it out. Let's switch over to this. And so why do we care about this? Again, Ashley alluded to this with the fear exercise with Apache Strips, this is a real thing. People are taking advantage of open source components and they're injecting, in this case, I have two examples of that. So we have a remote code execution. So FSPath is a very popular open source component for interacting with file systems using node as an alternative to just the built in OS file system access. And you can see if you add in, if you were able to inject code into this, you can have it do whatever you want. So you could have it write to your file system. If you just inject this line of code, it's going to write whatever you have in here. So in this case, I just did who am I to the temp bar and it will write to that. And this is a remote code execution vulnerability, but you also have some denial of services attacks that can be done with open source components. Now HTTP, Plib is one of the more popular HTTP libraries for Python. And this one is just super simple. You can do it on your own if you spin up in a sandbox environment, of course, spin up a code that has this and you just add in a header with the authentication and then just add a whole bunch of XA zeros at the end. It will spike up the CPU. If you do enough of this, then you can shut down the system by overwhelming them the CPU resources. So these are real attacks that people can run. And so what we propose as a solution is software composition analysis. And what software composition analysis or SCA is doing is it builds out an open source bill of materials where it says here are all the components you're using and then what are the vulnerabilities and licenses for those packages use. And the idea is not just to do it at one point in time. So don't just have it in the IDE or in a CLI where you're giving that feedback once to the developer and then whatever they decide to ignore just makes it all the way through to production. But it's having that feedback and those guardrails at different points in time to constantly be giving the developers feedback of, hey, early and often in the IDE or in your local environment, here are the vulnerable components you're using, here are the licenses you have. These are the ones that are violating our internal compliance. And then once you move to the repository, blocking the ones that don't meet a threshold. So there's a critical severity vulnerability in here. Don't let that make it into our repository. And again, check and make sure it doesn't make it into production. And then having that consistent policy across so that developers aren't surprised, hey, I wasn't told that this violated our license compliance. And I've already gone through and moved on to my next JIRA ticket, giving that feedback early, but also making it consistent. So the feedback they get in the IDE or in their local environment is the same feedback they're getting once it moves to production. And having that consistent layer of visibility for your security team. So they know the environment that they're running. They know that in runtime, the packages they're using that are vulnerable. And the benefits are that you are able to identify and update and remove vulnerable components. So if you're getting in that early feedback to developers, they're more likely to patch. It's much more expensive in the orders of tens of magnitude higher for you to patch in production because you need to take things down. Most of the time developers have moved on to a different process. And so it's just much faster, much cheaper to have it done early in the development process. And then it reduces the risk of violating open source licenses. If you give that feedback when you also have those alerts, so you know what you need to be giving attribution for. And then there's no surprises at any stage. So the developers aren't, I think they're good. They've got that green checkbox. They made it through all the repo scans, all the CI scans. And then all of a sudden they post to production and they're told that they can't use a component. That's just not a great experience for them. Or worse still, if they've been told that the post production, they need to go back to that code they've already moved on because of a security review reported a new vulnerability that they weren't told about before and it's been around for years. With that, I'm gonna throw it over to Ashley to kind of show how this works. Yeah, well, I'll endeavor too. It's interesting, it's not just us that are saying that it's more costly to fix things in production than it is in design or in development. NIST have come out with that. It's not just a case of going, well, anecdotally, we hear that or as DevOps teams, we kind of know that anyway. That's where we do want to automate these processes. We do want to bring these things out. So all of these things are, obviously Taylor and I work for Palo Alto Networks. We believe that product-wise we have the best in the market for various different things, but it's not about what Taylor's just taken you through there. Isn't about saying, oh, well then you have to use this product. But saying, look at and the recording will be available but look at those different steps and say, okay, well, these are all the opportunities I have to secure the development lifecycle. These are all the opportunities I have to have discussions. And it's all about being more carrot and less stick because as soon as you start bringing the big stick out and saying, right, well, we're gonna have security review this and put a guardrail here that's actually just a blocker. Then as Taylor says, we're trying to move fast. So as soon as something's fixed and goes into the automation, then we don't want to go back and revisit that. We need to have that information there and then. But absolutely I'm supposed to be doing a demo just now, not just telling you everything that Taylor just told you. So let's jump across here and go over to the same kind of console that we had. So I will kick off by just kicking off our build in Jenkins because then it can complete while I keep on wittering away about things. So we were having a look and we saw that we were, we want to have some guardrails in place. So despite all the, we've got a running application. We need to care about that. We need to feed and water how we get our vulnerabilities coming through, how we show people that within the IDE or within someone having it on their command line. We also need to be able to enable security to deal with, to be able to talk properly with developers and to enable security to contribute rather than just pull together a policy that says, thou shalt not do bad things. And I do remember when I was writing operating system policies at the time was getting securities policies. And the policy said you can't have any tools that could be used for development purposes. And you were great. Was so a shell, should I remove the shell from the, my VMs that I'm building? Okay, maybe I'm a little bit sour about that, but you can see how the policy doesn't necessarily translate. And that's why we want to enable security to be able to do that, have that ability to, to, you know, have merge requests, to analyze those merge requests to create their own pool requests, even to that code. But anyway, what we're going to look at here are vulnerabilities for an image. We could have been doing this for the, the code Drupal, you saw that from Taylor. And so I'm going to go in and I'm going to look at the rules that I've got in place just for, and the rules I have in place are really quite friendly. They are, we're going to alert everybody if there's a low vulnerability in there. I probably, or when I ran this as a customer, I wouldn't have had that at low. But anyway, let's say we're going to have it low. And then I could have some blocking in place. So for now, I have been building, this is my CI. So let's jump over to my containers here. I built this project. I think it was HelloPython, it was 29th and that's correct for my time. Now let's have a look at this build and we can see that it passed there. And we can see that we've got a report of the vulnerabilities that are in there. Okay, now let's jump over and say that we are now having to put some guardrails in. Unfortunately, as a security person, and I'll change my hat over, as a security person, as much as I love all the great work that's going on from my development teams, I can't have critical, in fact, I can't even have high vulnerabilities come through on the production platform. I'm really sorry, but I can't do that. So I'm going to save that rule off, come back over here. And of course I'm going to go back to the project and I'm going to schedule a build. And then while that's building, unfortunately I'm going to talk to you a little bit more. So I can jump back over here and I can say, right, I could have actually been a lot more friendly and put in some additional rules. Now, the reason why I bring this up, yes, I'm drilling through our product, but that's because these are very useful things that you would need to consider if you're rolling your own. And we produce, check off as an open source tool to allow you to do infrastructure as code analysis, for example. And that's something that you should definitely check out. You can cobble these things together with various point solutions. But some of the stuff you need to think about is making sure that vulnerability information is the best it can be. And then how that gets applied to the different rules. So we've got this blocking in place as we saw, well, actually I could be a lot nicer. I could say, well, I'm only interested if there's a vendor fix available. If there's no fix, then don't worry about it. And in fact, I could go further and probably would in a security realm. I would say unless this is maybe running in the DMZ, unless this is something that's exceedingly critical, I may just say you've got a grace period to fix these things. So once a vendor issues that patch and remember that lovely diagram that I showed you about the time it takes to go from a patch being released to applying that, if you need to go through certain gates, then we can change that. Let's say that we're gonna make that 60 days. So now my DevOps teams have a way of seeing that there's going to be a problem and knowing that yes, unfortunately, we do have to have that blocker in place. So I'm gonna cancel that out because I don't wanna mess around with what I've been doing. And lo and behold, I have suffered a build failure, which is really good. The demo gods are smiling. Now I could do the image vulnerabilities here as I showed you before when it was a working build, but let's jump through here and do it from a UI point of view. And the reason for this is I want to showcase that yes, you're going to have those scanning all the things we've talked about, but you need to make this information available both to the people who own the build and are able to control that. So Jenkins or pick your CI tooling of choice, but also for the people who are perhaps accountable for this. And so from a security realm, I want to be able to see, well, what's been going on in my CI process. So if I jumped to my CI process and then I'll jump to the last one that should have ran. We can see here that there's HelloPython. I can see that we've had, in fact, let's search for it, that's better because I've not got it in the time order. HelloPython and here we go. There we are. We've got it better for the 29th and the right times. So we've got the one beforehand, which succeeded. It was passed. My rules were good and we've got the one that failed and we can drill in and we can see that the same way as you saw before. What's the actual problem? Well, this is from the operating system. Here's the CDE and all that good information. So in this way, I've been able to control in a very simple way, exactly what's able to go through into production. Now, I could, of course, a bit or undo my rule before that starts breaking builds across the board. I'll switch off that failure threshold. We could have done that in a number of different ways and gone into more detail. But of course, the point of all of this as he switches back to the presentation is that we want to allow people to communicate. Patrick de Bois, who is one of the chaps who did some stuff around the DevOps movement and justifying DevOps, which is actually quite old now, believe it or not. But DevOps, he termed DevOps light as being when you take operations and development and mush them together. He viewed DevOps as something that's the whole organization working in an agile way to accomplish common goals. And I'd say that this is the tip of the iceberg. And I think this is where we're seeing real change now. Both with the last year's events, I think that's opened up people in business as nice to be able to see what we can achieve through technology. And perhaps those of us on here would have said we knew what we could achieve all along, but actually it's given people the chance to see what's possible, the art of the possible and seeing that change is the only constant. So here we're looking and saying, well, how can we have that communication? So I did the easy one. I did some vulnerabilities in the container. But what about those licenses like Taylor showed you? These are things where we put those guardrails in place. Is that the responsibility of your security team? Is that responsibility of legal? Perhaps audit needs to be in there. Maybe we'll be here talking about DevSec audit legal ops one day, hopefully not. But if we do, then I coined that phrase and we're gonna be there. But the whole reason for building engineering at the top here is because I come from engineering and so therefore we're best, but also because that's who's doing the work, right? We all stand on the shoulders of giants. We do need security. It's everybody's problem. I know that there was a number of credit card breaches where I got my credit card was breached as well. That number went away. Fortunately, I always make sure that there's no money available on that credit card so it doesn't matter if somebody steals it. It won't be worth it anyway. But find the engineering that common language. I'll be sensible again. Finding that way of doing it. So if you're rolling your own and you're building together all those different things to say we're going to have a shift left, we're going to do things in the IDE using open source check off, for example, or check off doing scans there at CLI or whatever you're going to be putting things in place, then you need to make sure it's all joined together. Now, I would of course say that Palo Alto Networks has the best platform for that, but a minute from a think about how you enable this communication. How do we feed back to engineering before they have to move on to the next business enabler, to the next georeticket, to whatever they've got to do, how do we do that in the best way? Create sensible policies. We're working together, right? If we have security turning around and saying, we block everything, everything, then that shows a misunderstanding about how software works and about how we're trying to actually do this for the benefit of the business or the overall organization, as opposed to just because we quite like doing stuff with computers. And the same way bringing legal in because these have real world consequences. Taylor was quite clear about saying the different, the different ways that this can impact. I was mentioning the licensing. You can see how we can create problems for our organizations without realizing it. We're engineers. We need these people to help us. And so once you've started doing this and you're starting to do that talking and enabling people to say, we speak the same language as somebody who's very interested in all the different licenses, I can let my developers work by just saying, you don't need to know what the letter acronyms are or the version of that. Just know that it's going to flag up and tell you, please don't use this license or we can't allow this to go through. And maybe it's a case because remember it's all about communication. Maybe it's a case of when that blocker comes and it has to at some point, when that comes, we say, no, we have an exception process for this. And so being able to build that in. And so how do we do this? How are you going to do this analysis? How are you going to do the software composition analysis and show benefit? Well, you need to show improvement over time. We need to treat these things exactly the same way we do any other feature or bug. And it might be that you need to have a separate burn down chart. It might be that this is something that because of, it's not the dev ops team themselves who are looking at this that actually we need to enable somebody else. That's fine, but communicate, collaborate and show that improvement over time. Show the time to fix. Maybe that's what's important to you that we understand there will always be critical vulnerabilities but actually our time to fix those has reduced significantly from before. We just want to show that continual improvement. Prioritize the issues. Have a good conversation with your teams and with the different parts of the teams with security teams. It can be easy for me to say this. I have gone through it but it is about talking to understand different people's point of view. I heard recently someone saying that they took like a high performing engineer out of the dev ops team and put them in the security team for a while or vice versa, taking someone from security and embedding them in a dev ops team. Not because we can scale that to every dev ops team but because that's how we can understand each other. So prioritize the issues, which is more important that these things are critical. This is a critical vulnerability that impacts stuff that's connected on the internet. Well, that's a caching ceremony. We don't connect that anywhere. I don't know, but have that visibility into the different ways. And then that last part there, the guardrails not gates is the nice way of putting things. We know that they've got to be gates at some point because we have that transfer of responsibility. We have that transfer of segregation of duties. We have those different things. The point is the guardrails mean we can see this early on and we can do this for all these different parts. We're talking about software composition analysis. And so just diving into that one part, this occurs throughout any type of cloud native security platform. You've got all those different areas. But actually in this case, let's have those guardrails. Let's have it so that when Taylor does something wrong yet again, at least we've told him early that he knew he was doing something wrong or rather we actually were encouraging. We're making it easy for somebody that actually make it easy for me to do the right thing as opposed to doing the perhaps the cutting a corner because I don't have the information because I'm under severe time pressure because of all these different reasons. Remove the stick, add more carrots and can't we all just get along? But that's the whole way of looking at that. So aggregate everything out, show all these different information and let's all communicate and make sure we get things done. We have, we've rattled through this pretty fast I think but I think that'll give us some time for questions, hopefully. I do have to shout out that we will be at KubeCon. I, KubeCon EU, I am very excited about it. It's fantastic. It's a shame that it's not in person. I love the sessions and I actually attend more sessions when it's remote like this because I can see them all and block them off and I don't need to worry about going between sessions but I really miss like the hallway conversations, you know, and being able to ask somebody at face to face, you know, what is it that you're doing? Tell me something, just what are you up to? Why are you here? And getting that information. It's very difficult when you're trying to do that over text and over a chat. But I was speaking to Cheryl Hung from CNCF and she said a really great thing. Everybody there, and I know this from all the KubeCons I've been to, they're very friendly, they want to help. Speak to people, reach out, say hello, swing by our booth. I am going to be there on Palo Alto Networks booth every so often. I'm going to be trying to catch as many things as I can but swing by our booth, come and speak to us. We're not, we don't want to be pushy or anything like that. So, you know, we want to learn what people are doing. Taylor, what do you think? If you've got anything to add, I'll put you on the spot. Yeah, no, it's great. And I love those conversations because it's really two ways that I learn just as much as people learn from me. At least I hope, I don't know if they're learning anything from me, maybe they're not learning anything, but at least I'm learning a lot from them. And when I have those conversations, whether it's virtual or in person, obviously the preference is in person. But for now the chat is a good, it's a good stop yet. And I'm looking forward to it. Good. So there's the Q and A there, if anybody wants to pop any questions in. One of the things that I kind of get asked about these things is, well, what happens if we're doing stuff when production? We're making changes in production. It's all very well, this shift left side of things, but how can we tally the two up? Now, I kind of have a leading one there because I know that you showed us the runtime there, but what's your answer to that, Taylor? To the, sorry, it broke up first. Oh, you were reading the Q and A I'll answer that one. The shift left is really, really important in seeing this particular one, a software composition analysis. The thing I was talking about there was around saying, it's not just about the shifting everything left. The production is of course where the risk is. If you speak to a CISO, that's where they get really upset about things. So it is about making sure that we analyze any drift that goes across, but it's equally important. We want to be able to see what's out there and have visibility of everything that's there. So I can see a question come in. Do you want to take either of those? Do you want me to take it? So I can take the first one. So Prisma compared to Blackduck. So Blackduck is a great piece of software. I know a lot of companies, a lot of our customers use it. And the comparison is so runtime, I would say Prisma Cloud, Blackduck doesn't have a runtime component. So Prisma Cloud is a great runtime component like Ashley alluded to with the CISOs preference, making sure things are secure in production. And for our SCA capabilities in the shift left, that's more our software is able to identify a lot of different vulnerabilities and packages and licenses similar to Blackduck. So I definitely recommend you take a look at the two of them. Blackduck's been around a lot longer. So you might see some things that are unique in Blackduck, but there are some comparisons for sure. Well done, yeah, if you've worked out how to do that. And then we've got a second question that's around the NIST requirements on CIS2D and how does software composition analysis help that? I'll be very open. The NIST requirements are not something that I'm talking about over here in the UK. It's much of a very good standard and they are a great standard. And I tell everyone that we should look at them. So the specifics as the reply to SCA is there. But the way I would say is that, regardless of what standards you're using, whether you're using the Australian standards, whether you're using NIST, whether you're using any of the ones, we've got a number that are out of the box. When it comes to SCA, it's still the same thing. Even if you're using your own custom standards, if that's what you want to do, it's about trying to do that as early on as possible. So about saying, here's the information that you need to know that this is acceptable, this is not acceptable, or this is acceptable, and this would be acceptable if you can provide a justification for that. I don't know if you wanted to add anything onto that, Taylor, or get the other question that's coming. No, I think that's good coverage. A lot of the NIST standards cover both runtime and build time. And the ones you can catch early and fix early, it's definitely valuable to do that. And just having that visibility all the way across for how you stand up against those requirements, I think it's just good to have that posture at every single stage. And then we have a question here about the hierarchical bomb. So the way we build it out is we build it at the first level. So just the dependencies that you have and going in and it's very reasonable to say why would I want to patch or why would I want to know about something I can't patch because it's actually a dependency of a dependency. So that's why we've started with just the first layer, what are the direct dependencies and what are the vulnerabilities in that that have been identified? I would tack onto that a little bit. Well, what we, for the bill of materials, absolutely. So I'm kind of, I'm straying off the question a little bit, but for you look at it from the wider view point of, well, what if there is something but there's no, that what I showed people, well, let's switch off if there's no fix available. There'll be a lot of environments where you don't want to do that. You actually want to see all those different things because you're viewing it as a risk. And you can then mitigate that risk however you choose to mitigate, whether that's, well, I patch, maybe for the thing that runs my nuclear reactor, I have to actually take some other action or whatever's there. So there are times, admittedly, in the particular question that we've got here, Taylor answered that perfectly, but there are times where you do want to have that visibility simply because it's a business risk to be managed. Yeah, and one of the ways I've seen of doing it is not blocking, alerting at all the levels and then blocking once there is a patch available because that is something that developers can control but letting some of the vulnerabilities that are unpatched go through but then adding a confidence standard control in the runtime. To be honest, this is where all of these things, these are all things that you as an organization will want to worry about, right? So what I would say is you don't want them to be trying to code around that. So if you're putting your effort into how do I make that possible? How do I make it so that, okay, well, if it's this, then that's allowed, but if it's this, then that's not allowed. I'm trying to join all that together. That's plumbing you don't need to be doing. And that's why I would say you reach out to a partner and have a partner work on that for you because you want to work on the business logic. We don't need to tell you which license you're going to want in your estate, that's up to you. But equally, you shouldn't be trying to code how you check for those licenses in your SCA. Yeah, absolutely. I've seen, yeah, you hear some of the horror stories of people trying to get around the blockers that they have. So adding, just making a slight change in the open source component. So it skips through and if you are too restrictive on what makes it into production, you find that developers are going to go through that path of least resistance. So if you make it too restrictive, they're going to find ways around instead of using it. And it's the same thing that we've been doing for any coding. It's that testing perimeter, testing triangle, whatever you want that you have those least costs that are running all the time, we're linting code because we want to, we know that it can be bad if we don't lint it. And it's the same thing here. It's about going, let's try and make it easy to do the right thing. It just seems a bit strange because we're doing it from a security point of view as opposed to a purely developer-driven point of view. But it's the same, right? We want to improve the quality of everything that we're building. And that's what we do. Yeah, absolutely. All right, well, Taylor, you can say, Chiro, I've already said about KubeCon, but you might want to mention it again. I hear Lori in the background poking me. Absolutely, the KubeCon, Delta Networks, we will be their Prisma Cloud, our cloud native security solution. We will have a lot of representations from representatives from that. And so come and join us, ask us any questions where we'd be happy to chat. Awesome, thank you both so much, Ashley and Taylor for your time today and thank you everyone for joining us. As a quick reminder, this recording will be posted to the Linux Foundation's YouTube page later today. Okay, thanks everyone. Have a wonderful day, bye-bye. Thanks everyone.