 All right. Well, thank you, everyone, for joining us here today. I'm so excited to be talking about DevOps and security and how that all comes together. Awesome to be here with my friend, Sean and no far. And I think we'll have a lively conversation on the topic. And we look forward to your questions. So please do submit those questions down into that Q&A panel. That'll always make this a lot more fun. So without any further ado, I think it's worth getting in and celebrating the progress that we've all made on DevOps, right? Whether that's just in your organization, you're feeling the velocity happening and it's going so much better. Or whether we look at like how we've come as an industry over the last 10 or 15 years where we've moved from releasing once or twice a year to like continuous delivery and getting things out the door every couple weeks, every week, every day more than that. We've got a lot of great reasons to celebrate. And I love it. At the same time, yeah, we've got the party crashers, right, Sean? Who are coming in from security and they're like, if we should go on this fast, you guys look like you're having a little too much fun here, and maybe not being the responsible grown up adults that y'all should be. And yeah, I think when you start getting the departments of no, like security showing up and kind of spoiling all your success of deploying to production 12 times a day, it can feel bad. But there's a reason these folks are here. And so Sean, like, why are these dudes here? Well, you know, in some ways, it's kind of apparent. I mean, security, you know, much like sales, you know, you've probably heard the expression, you know, whose responsibility or whose job is, is sales in a company. And the answer is everyone, everybody has some part in that. And I think, you know, security absolutely follows this the same kind of model that we all need to be security minded. You know, every developer that I've ever spoken with in recent years understands this. And yet, it's no small feat, you know, Eric, like you said, to build a working and successful DevOps model with, you know, all of the right tooling and resources and, you know, people, I think, ultimately, you know, there's a huge cultural change that needs to happen. And so, once you've kind of achieved that level, I mean, sure, you're accomplishing things, you know, whether it's release frequency or efficiency or, you know, you know, all these metrics that you've kind of blown past in very good ways. And yet, security is very much top of mind, but many organizations are kind of trailing the level of security and sort of the processes and, you know, also cultural are required to really keep up and to keep this, this whole software development and deployment model intact. And so, what does the cyber threat landscape look like today from the application or from the, you know, development environment point of view you know, we're moving at incredible velocity and many code bases. In fact, you know, you can see here statistically, more than 80% of code bases have vulnerabilities that are introduced through the use of open source components. So not only are we just building faster, we're using all of these incredible and widely available building blocks to create the applications that we have today and so that really opens things up for you know, yeah, there's there's a risk exposure there that clearly organizations, you know, in the security and compliance department are watching this and going well, you know, how are we going to, how are we going to protect ourselves from this. There's a significant risk out there. And so, you've probably heard a lot of talk about supply chain and open source components and other software artifacts being just a piece of that whole software supply chain. The other artifacts of it are, you know, some of the build platforms that these artifacts are, are built on and it's everything that actually touches a software application as it's being built and deployed and so you can kind of imagine that in many cases this is a very complex kind of attack surface to try to defend. And so 20% of organizations, according to Gartner will have experienced a supply chain attack by 2025 and we're just at the end of 2023 so that that that is very significant security comes crashing in, you know, whether it's in a kind of moderate way or you know, an alarmist way and that could really rattle the, you know, software development departments and DevOps and I think there's generally a good awareness that security is a top priority and that it needs to be inserted into DevOps and it's really hard to put the sec in DevSecOps which is, you know, the model that you kind of need to keep everything as it is going forward and there are some clear trade-offs and impact of trying to shoehorn in security processes and technologies in the whole DevOps model. There is good reason to figure out how to do that in fast because, you know, many of you, you know, as you kind of scan the slide here you recognize these logos and some of the major security incidents that they represent. SolarWinds, for example, you know, you probably know the name SolarWinds and, you know, their IT management software. There was, that was targeted in a way that as an update to that software was distributed to all of its customers, there was a vulnerability there in a back door through which malware was introduced and, you know, you can look at this type of attack vector is like it's a huge force multiplier in terms of the, you know, compliance and legal risk and damage that it can cause to brand and, you know, CodeCub, Log4J, 3CX. These all follow the same, you know, they use kind of different approaches, you know, different tactics but the idea is that you compromise one piece of that software supply chain and it multiplies through all of the users and, you know, the customers of that piece of software. So, you know, security as an imperative, you know, we're all trying to figure out, you know, how do we do this and how do we avoid some of the common trade-offs that introducing security abruptly into the DevOps model will cause. So, you know, handing it back to Eric and Nofar to talk through that and, you know, if you're a developer, you're probably going, oh, yeah, this means a lot more work and, you know, meant to load for me. And that is a very significant problem. That's a lot of what we're going to discuss in the subsequent material here. Yeah, Sean, I was enjoying the party. Thanks for reminding us. Well, why this is so serious? And what I think is interesting is with issues like SolarWinds, right, which compromise significant infrastructure across the US government. The US government got really interested in this topic real fast. And so there's a great white paper that we link to here. We should probably throw that into the chat as well. Coming out of the cybersecurity and infrastructure group in the US as well as the National Security Agency. We like to hack people themselves. And they really break it down as five areas that really are areas of concern when we look at DevOps platforms and how we deliver our software, these areas of vulnerability that we need to be in good control of. So first, you can always write insecure code, right, and you should check for that. You can also be consuming vulnerable artifacts. Sean was talking about log for J. Most common Java logging library has major security vulnerability that allows arbitrary code execution, which is remarkable for a logging library. But everybody suddenly is vulnerable to arbitrary code execution. It was awful, right? So that's one angle that you can have problems. But you could also have an issue where your pipeline, right, how you deliver code, how you get it built and deployed, that becomes poisoned and compromised and someone's got access to it. So you could have insecurity on that pipeline leading to that. But you could also have insufficient pipeline access controls, right? If anybody who's in your network could change the configuration of your deployment pipelines, then anybody could say, oh, let's grab some random artifact and I don't know where my camera went. You could grab some random artifact and deploy it on your production servers, which is obviously a security risk. And then, you know, finally, I think when we're looking at this, as you could look into your infrastructure issues, right, if how you're creating infrastructure is problematic, then we could be in a situation where that's getting spun up and it's not appropriately locked down. It's easy to just break into your servers and that's not great either. So there are a lot of opportunities when we look across DevOps to mess things up. And so we need a fairly thorough approach to keep this secure and tidy across all of this attack surface. And Sean, why don't you take us through some of that in more detail? Sure. So, you know, these are the, I think at this point, you know, these are very common objectives of DevSecOps. What does good look like in the world of DevSecOps? And a lot of times, I mean, this is not a trivial problem to solve when you have, you know, three really critical stakeholders of like very different types of functions come together and figure out how to operate together to achieve the result of having a secure delivery platform of being able to test for any and all known software vulnerabilities and create a means for developers to effortlessly remediate those vulnerabilities to harden their code. And also preventing the release of insecure code means knowing, and this also ties to number five, really knowing what ingredients you're building your code with, knowing where those artifacts have been built. They have a provenance, you know, which is a kind of an interesting term. But we'll get into the meaning of that and in the discussion around the salsa framework, but everything that you would need to do to ensure the integrity of your software goes well beyond just testing your own code for vulnerabilities, but involves really knowing where all of your software artifacts come from and being able to ensure their integrity as you deliver your final piece of software or your application whether it's an internal user or an external customer, if that's what your business is based on. So yeah, this is all great, but how can you possibly achieve that? And we see a lot of different approaches, you know, to my knowledge today that there are no de facto standards in place on how directly to achieve this, you see a lot of very different and sometimes innovative approaches. Other times it's like, you know, you're trying to shoehorn some kind of security measure into the whole DevOps model and it kind of, you know, if you've ever seen the show nailed it, you know, somebody tries to do something very elaborate and sophisticated, but the end result is just sort of like a barely passable, you know, barely passable results. Right. That's a start, but what we're going to talk about next is really centered around, you know, what are the things that you can do just sort of beyond the obvious measures that don't necessarily get you to that level of success. So, you know, we'll look at different approaches and kind of the considerations that that you would need in order to create a successful model for this because all this really just translates to your DevOps processes and your entire program working the way it should, but in a much more secure manner. Yeah, so, okay, trying to think through what we need to do. People tend to panic right when they get through government saying we're all insecure and you look at this, we got to lock everything down. And so the initial reaction that I see out there a lot is to say, okay, we need to make sure that only the right people can edit our CI CD pipeline so we got to lock that down really strictly like team leads only. Maybe even we need a central team who will define this for everybody. So it has to be done really correctly. And if any of this pipeline code is sitting out in something like get while we're going to need pull reviews and maybe we'll need pull reviews from 12 different people on pipeline changes to be really good and secure. And certainly before we go to production. We got to be careful, right because anything bad could have happened we should have a big meeting. With a lot of smart people. Let's bring back our change advisory board or cab and have a big meeting to do this and really big approval at the end to make sure everything was done right. And then we'll take everything offline every week and make sure it's all good and secure and patched. And I think there's good and noble things here. At the same time, if it goes overboard. This is why we were all scared when we saw the security guys knocking at the door at the start right we can grind things to a halt really easily. And I think this talks a lot about the the infrastructure, but we can go over the edge on the checks in security scans as well right Sean. Yeah, absolutely. You know, building on what Eric was talking about. You know, the terms like continuous integration and continuous delivery are are they're in almost every piece that you read about software development today. And I think it stands to reason that you know security needs to be continuous as well. I've seen, you know, some material out there some some thought leadership kind of refer to continuous security and really this translates to a lot of the processes that you would put in place in alignment with your CI CD pipelines and in a way that makes it easy for developers to deal with and so here what you know what we're showing you know in the simple pipeline as some of the sort of, you know, one on one level approach to DevSecOps. A lot of time security is really back loaded meaning like you've done all of your, or the majority of your development work and then you're going to run all of these security scans you're going to test your code and the security team is going to generate all of these results, taking the output of their scanners. And they're going to go up, you know, we found 360 vulnerabilities. Let's just give this back to our development team and you know they'll sort through it and fix it and that's kind of what happens you as a developer you get a spreadsheet. If you're lucky. And then you're sort of left to figure out alright well which ones of these are critical. And, hey, wait a second I'm going through this list. And frankly, I'm spending a lot of time on this, I'm spending a lot of time not coding I'm just going through this listing, you know duplicates of vulnerabilities because there's so many different scanners available in each in each category. You may get duplicate results and so waiting too long and having that delay in that information coming back to you that that doesn't work that's not really continuous that sort of security at one point, and then a long pause and then maybe you repeat that cycle and so the recommended methodology here is, you know, to do to basically start from the drawing board and introduce an approach to security and your pipelines that that solves two and one, you surface as many vulnerabilities as you can but you do it in a way that you can actually, you're not pulling your developers away from the work that they are paid to do. And you're not creating massive headaches and I think, you know, no far like you can go into like a lot more detail sort of like, what are we seeing out there in terms of like what does it take to be able to achieve that. What, you know, what's sort of the impact, you know, to developers there. All right, thanks, John. So yeah, I mean, both Sean and Eric, you know, kind of gave an overview of what we've seen, you know, businesses doing in the past right how their security teams work. So a lot of organization out there, you know, have, you know, realize right that doesn't work well this approach of generating, you know, finding decisions late in the game and getting goldies vulnerability and then excel to the developer that it just, you know, increases the friction and delays right mediation and you know of these issues. So what we've started seeing customers doing in this industry is shift left and I'm sure everybody probably on the call have heard about shift left right it's not a new concept. But shift left has its own challenges right so what we have seen first of all you know it is it is a big cultural change right now saying okay we want to shift left. That means that now we have to run these scans as early as possible. So maybe in your CI solution you're already running static, you know, scans right, or container scanning before we even you know packaging artifact right so the idea is to pull all these tests as early as you can in the game. But that brings you know a new set of changes. Okay, so who owns this work right now. So let's say you're the, you know, I'm a developer which I was in, you know, ancient history and now I told okay. Now you need to go and put all these security measures in your pipeline so before you go and push your through container with your code to you know the other half you have to make sure that this can probably. So now I have to figure out you know what's next right so maybe I'm going to go and look at some open source solutions that I'm out there for container scanning maybe or for dependency scanning or for whatever scan that I may need to incorporate in my pipeline right. So now that means that now the load is on me so now I'm a developer that's not really an expert in security need to figure out how to find the right tools out to integrate them in my pipeline and the most difficult task what to do with these results right so now okay so I've done the work and now I have all these security scans in my pipeline and I get results and then what what does it actually mean to me. How do I know which one I need to prioritize which ones can actually go to production right because maybe they're not that severe. And then there might be a back and forth in Slack with someone from security teams or something like that right or not to figure out what I should fix. So, so shift is great, but what we want to do what we're offering and harness is that you know ability or what good looks like right is the ability to shift left the information and not a workflow right so this is what we feel is the ideal scenario. How do you pack this information in a way that is meaningful meaningful meaningful for the developers that they know what to do with that information. So they don't have to go and be experts on security and they don't need to necessarily figure out how to build it on the integrations themselves and they're an easy way to understand, you know, what's important and what's not. It's an easy way to work with the developer team because shifting left the workload right without shifting the data time and putting all these load basically all these efforts in the developers hand does the opposite. So sure you might be checking for security issues early on, but now you have developers that rather than actually crafting code creating innovation. And sometimes security and it slows that every down and it makes developers less happy, which of course, you know, everybody was a developer to be happy and just degrades right the overall developer experience. So the question is, you know, how do we put the, you know, security in software delivery without killing the developer, you know, experience and slowing them down. And for that, there are multiple approaches, multiple principles that we can take. So first of all, we need to empower each team to do the right things to do what they are good at. If a developer needs to now go and implement their own security scans. It's a waste of time. There are people in the company that are experts in security, and they can go in and set the policies right, say, okay, these are the security scanners that we are working with this is what you need to run in your CIS this is what you need to run this city space, encapsulate that into usable templates right so everybody can just use it so no one needs to reinvent the wheel. And, and also, let's say they did it. Okay, so the security team are awesome, and they've created the best templates and now all the developers theoretically might use these templates. You also need to make sure to make sure you have a way to ensure that they're using these templates right and this is where another challenge comes in with these policies. So how do you how do you do that without slowing down developers so let's say now I'm a developer and I want my autonomy right and I want to be able to do my work create my pipelines. How will I even know that there's a template that is there for me to use. And how do you make sure that I'm actually using that. So if you have a good you know policies in place that will help you out right so developers for example we try to push an image to docker hub. An engine engine can detect okay right the preliminary step for pushing an image to docker hub is to run these templates for scanning. Now go ahead and do that before you can move forward right so if you have something like that in place then you have basically autonomy with God rest right you can make sure the processes are done properly. So the developers are focused on what they know how to do best they write on code they're not expected to become security experts and the security teams know how to put the policy policies in place and the templates in place in order to enable the developer to do to do their work. And this way basically, you know we make it easy and like to do the right things and make it hard to do the wrong things if you have policies in place someone really really rich you really need to work very hard right. You know to do the system. So they just basically takes the developers down the path of best practices and what you know and do the right things and make it very hard for someone to do the wrong thing. And I think another another thing that we see from from some of our customers, especially those that have already done that's right already shifted left and she left properly and they have the policies and they have the templates. They want to take it even a step further to make it risk bait bait a bit for risk based this decision making so because once you have something like that in place. You can really play with the level of security that is really needed in each step of the way. So maybe you have a documentation site and developer hub. And that's, you know, while of course this is super super important. I mean, the risk might be slower, you know, to that site compared to something that is in the core, you know, in the heart of your business maybe your hotel and you have a booking system and now you take you know people's, you know, information and credit card right and this is something with a risk profile that is much larger. So, so this base decision making basically means you don't have to set the same scans and the same policies and the same, you know, approve us for everything right, but as long as you have these building blocks in place you can make the right decision of which case which standards to comply with in each of your application in each of them use cases. So with that I'll pass it over to Sean to dive dive a little bit deeper into how we do it right. So far, I think that was just excellent perspective so you shared, you know, two really great insights and the guiding principles, you know, what you what what you shift left ultimately matters and you know shifting a whole workload left that that will break your DevSecOps model. And, you know, making it easy to do the right things and hard to do the wrong things I mean like great principle. And more from the security side of things how do how do you make those two, you know, how do you enable those two principles to play out in how you operate in your DevSecOps framework and I think, you know, automation is such a big part of that. And so, you know, when you do look at, you know, how am I going to build my security pipeline how do I want it to operate in accordance with with those two principles, you know, having guardrails but also like what what you shift left and let's say even how often you do it. You know should be the function of a really thoughtful automation so I, you know, taking taking that concept and sort of laying it out in terms of, you know, again, you know, here's your basic software development pipeline. What you're seeing here you know the blue logos are, you know, the different categories of tests and where, you know, just kind of a general suggestion where where you would run these. And so, you've got all kinds of different security scanners, you know, static application security testing dynamic application security testing container scanning. You know, you can go on it and there are a myriad of options in each category. One of the things that, you know, we often talk to, you know, customers and and and folks in the industry about is like, you know, what what and you know, or I should say which ones and how many, you know, different independent security scanners are using be they open source or commercially available and so there is such an abundance of what you can use and there's freedom of choice which is all ultimately good but sometimes you get a little too far over your skis and you've just got too many tools to manage so taking more of a platform approach. That's something that we see a lot of preference for, particularly in much larger kind of DevOps practices so being able to execute security scans but also that the governance piece is really key here and again, a very important piece of automation to create and using a policy as code approach with the open policy agent, you know, for those of you that are well versed in the cloud native computing foundation ecosystem. You know, OPA was a hugely successful project. It's got, you know, millions and millions of downloads, huge global community around it. It's such an important. It's such an important piece of technology because you can apply policy as code to all these different areas of your stack and in this particular use case. We're using it to govern the, you know, if you want to call it the passage, you know, moving a piece of software onto the next phase, you know, pending that it passes whatever security checks that you have in place that that's one where we typically use it and so it's really valuable in making sure that you're not deploying insecure code. And so, you know, as, as you run all these scans and tests through your pipeline, you stand a very good chance of really nailing down vulnerabilities early and then remediating them. So in this situation, you know, for the sake of your developers, you would provide them with not only a duplicated and prioritized list of vulnerabilities but, you know, ai is, is, you know, is so incredibly hot now the use case in in in this particular model is to to create guidance on how to remediate vulnerabilities and so what does that mean for the developer well it's just it's dead simple you have security running continuously and you have you're doing it as, as kind of like far to the left is as you possibly can to close that feedback loop. And so a developer can easily get a list of vulnerabilities they can work on and not have to spend too much time figuring out how to do it, it's it's more more of a turnkey process so this is a really great model to to try and achieve and that's really, you know, for the code that you're building in your organization. So, you know, we talked to earlier on in the webinar about supply chain security and so like if you kind of, if you go up to, you know, the 10 or 15,000 foot view, and you're looking at your own code but all of the components that go into producing your end piece of software your end application. The supply chain is very much in focus and again this is really the this is the attack surface that you need to be able to defend the brand reputation legal and compliance risk I mean this all kind of hangs in the balance of that. Many of you may be familiar a couple years ago and this is actually pretty recent. The President had issued an executive order it's executive order 14028. And the purpose of that was really to strengthen the nation cyber security posture. But when you dig into the details of what's required and how that ultimately could be achieved. There are there are two components to this here that I'm calling out because you know these have major repercussions for software producers the first is the software bill of materials. You know essentially it's, it's your very detailed and incredibly long in fact you know this is like a machine readable list of all of the components included in a particular software artifact. The dependencies third party libraries and everything that goes into a piece of software should be detailed in the software bill of materials, and that's something that I think in government organizations and are required to get this from the producers of the software that they use. And that means of, of, of really making sure that they're, they're getting, you know, something that that's, they're getting a known piece of software for which the integrity can be can be a tested. And on that note, there's also salsa, which is supply chain levels for software artifacts this is a whole detailed standard for what are the controls that you need to have in place to prevent tampering and just ensure the integrity and the provenance of the software that that you're producing and clearly for the building blocks that you're using to build your own software. So, I did actually covered it in the previous slide but just, you know, showing you in a little more detail, you know, this is ultimately what what salsa is aimed at there, there are currently three levels. As you go up and level, you're, you're going into like very fine detail as to, you know, where was a particular software artifact built, you know what what branch was it built. There could be, there could be information required about which individuals worked on it. So, this is very fine tuned kind of information as to like where a piece of software comes from, and the whole, the purpose of using this framework is really to reduce your security and compliance risk because you know going back to some of the supply chain that we talked about earlier. In a lot of cases you don't really have the visibility into the open source components you're building your code with. And that's a huge blind spot that following the salsa compliance framework can help solve. So, when you look at securing the software supply chain and again using the same kind of guiding principles that no far talked about, you know, guard rails in place having a level of automation and making sure that you know none of this just falls on on the developer kind of making their flow and taking them away from what they need to be doing ultimately, which is coding and building innovative new components or applications but but here you can see how we kind of laid out in the red shields, what you would do at these specific stages so in building your software artifact you definitely want to be able to attest the provenance of a particular software artifact, meaning that you would kind of look at where is this coming from what version is it you know what what branch of the of the software development, did it come from, and other details and so you can also generate your own salsa provenance and you are attesting that you know this this piece of code again built according to you know, similar details right. And then you can generate and attest a software bill of materials so again, building a complete listing in detail of everything that's in your particular software and so this process of either generating or verifying salsa provenance. I mean that that's that's hugely impactful in being able to say that you delivered a piece of software that is like high integrity and and really the blind spots are eliminated by by doing that. One thing you'd want to be able to do as well as is let's say there's a zero day vulnerability that is discovered and this is not something your scanners are going to pick up for obvious reasons I mean those will will surface known vulnerabilities but you can have the ability or at least a game plan and the tooling to be able to go back and say well okay given that this vulnerability was found in some open source piece of software. We need to trace this back to the impacted components in in our application and so being able to do that is a huge advantage that that is an all hands on deck. I mean, it's a huge size in many cases but this is kind of what you would do and again you can you can look to use policy as code as a means of really making sure that these steps are followed throughout your pipeline. There's a lot that goes into this obviously. But again, like I think a lot of the guidance here in in how to build this dev sec ops model but you know in a way that you're not only achieving your security goals but you're really being mindful of your developers and the, you know, ultimately their experience I mean, almost every company out there is a software company, and this is the lifeblood of organizations today so if you if you've got a core of software developers that are just, you know, they're rocking and rolling and they're, you know, ultimately focused on innovating coding and not being pulled in a million different directions because of security incidents and they've got a working model where they can work with it operations and security to keep this this whole flow going. That's, that's what success looks like it's hard to get there but I think you know one of the interesting things about this particular industry segment is that you know we're kind of building this as we go and we're continuously improving how we do this. And with that. I'm going to pass it over to Eric to just wrap things. Yeah, or Q&A. No, like, like 15 minutes ago I was willing to grind everything to a halt and lock everything down so that we could be super duper secure. But thank you Nefar and Sean for walking me through it because now I get it. And that idea of the zero day vulnerability kind of points out that the ability to go fast. Right to make a change today. Like awesome for innovation clearly and what I love but that's also critical if you want to respond to a zero day right we've got to be able to go oh no log for J. Where do we have it where's the new version let's get it swapped in there tested validated out the door into production in a secure fast way. Everything is locked down and slow we can't do it right like speed is important for being secure, not just for innovation. So this makes sense like we need to have an appropriately controlled DevOps platform people shouldn't be able to hack into it easily okay that that we can do up front that makes sense. It goes to the security testing or sassed or dast all of those things you were talking about. Right, we can't have developers spent all day like fine tuning security stuff it's not what they're best at it's not best for security it's not best for innovation. Let the security teams set up the right tools let them set up everything but make sure that the pipeline executes at all. It's nice and fast, and we get feedback to our developers in a really clean way. And while we empower them to control their own pipelines, we do build some policies in place right you mentioned OPA as a good way to do it. And then some policies so they can't like say oh I don't like the security stuff let's remove it right like has to happen, but otherwise they're in good control. When the pipeline runs we let our developers get the security information back to them ways that are easy to manage and fast. Cool, I get that. Ddupe it prioritize it make it actionable. Okay. And then yeah let's make sure that we're generating our response complying with salsa all of that the pipelines can do that. We should be able to automate all that stuff to. So yeah I see how we can go fast. While having the security guys part of the party. So they might not be dressed to party but I think they can hang out with us I get it. So, I think life is good again. I was pretty worried 20 minutes ago. All right. So thanks so much for for walking us through that. We're going to shift to Q&A here. And I want to thank everybody for attending as we move into that. There is a Q&A panel I believe at the bottom of your zoom screen if you want to ask more questions we already have a few coming in. So we are harness, we are software delivery platform, we do work hard to keep it secure and make all this security testing and supply chain governance really really easy. No big surprise I'm sure. But yeah, I think there's a couple of questions. I have a question Eric about. So I'll read the question first I'm not sure if you'll consider or not. But the question was how to find balance between security scans integration and CI CD pipeline processing speed. As for big project security scan can significantly increase the build time and for big teams with multiple branches we can get huge build queues and decrease in team performance. So that's an excellent question before we talk specifically about the scanning and how long the take. I think the first thing that came to, you know, immediately jumped to me that you have queues. Build queues so regardless of what you're running in your builds. I think that would be the first thing to look at because one of the requirements in my opinion for a good CI CD solution for a good DevOps platform is that it can scale with organization needs and, you know, engineering time is very precious. And if the engineers need to spend time, sitting, you know, waiting in queues for the bills to run I think this is not a great situation to be in and developer in my past, you know, it's very frustrating from a developer's perspective. But let's talk now about the core, you know, the core of the question. What can we do basically to avoid it. So, so I think there are a few things that you can do first of all decide when to run the scans. So developer teams of course they you know each developer if I need to fix about something that I would open, you know, feature branch and I'm going to work on my branch. And if you do have a very lengthy, you know, testing maybe you don't security scan, maybe you don't want to run it necessarily on each commit. And for your own company specifically the writing would be to have some trigger conditions and maybe only run certain security scans only for PR pull request like for the main branch for example right. So depending on the risk depending on the scope of what you're testing on the branch right using triggers and trigger conditions you can basically make decisions. Of what's the one where, and also in in runtime, you know, itself right at the part of the pipeline, you might want to have some condition if the target branch for example is not main, then you can maybe skip a certain stage or a second, certain you know, process. And that's not specific for security scan. I mean that's any time you have you know, I mean for example it can be relevant for integration testing it can be relevant for any you know, for other types of testing for any test that takes along the portion of the time. I mean I would also look at places where it can be optimized I mean I wouldn't revisit, you know what kind of security scans you're running and in one, you know, in which scenarios. And the few things that I would look out for how to optimize the test making sure you're writing that you know making that making sure you're running the light security scans or it really needed and make sense to run them. And I would definitely look at this build queue things and see how I can know scale up my system so I'm not slowed down by that. I hope that helps. That's a really great question actually. There's one more here which, which is also very interesting. You know what one of our attendees is asking, you know, can we talk about some of the mechanisms or tools that would allow for giving developers autonomy with guardrails. For example, how do you prevent dev teams from turning off security steps. That's interesting. I'm, you know, I'll offer up just one perspective sort of from the DevSecOps process side of things. I think, you know, that may be, I think the answer to that, I'm going to defer to you Eric, but that may lie on, you know, some of the security mechanisms in your platform. But I think that there are cases where you may have an exception. Where there's a vulnerability that would otherwise cause your pipeline to break. But for maybe good reason, you can create a security exemption. In which case, you know, that would be something that you would do with your security team and that could be managed in a way so that it's not, you know, holding up your deployment. So that that's something that you may want to have as a capability or at least a process in your pipeline to handle security exemptions because they do they do come up. But I think what you're asking, it probably the answer to that lies in some of the security mechanisms of your platform. Yeah, so I think there's, there's a couple elements here I think one that idea of, hey, let's, let's make sure the software is getting better. Right overall so we might have a lot of security issues in our software today and we start scanning. And we don't want to say we'll never ship to production until we have zero right that's not realistic. So we do want to clue in on things like. What's new. Now on this one like how do I make sure that my development teams can manage their own pipelines, but they can't turn off the security steps. What we're seeing is a move towards separating edit permissions on the pipeline and the enforcement of policies about the configuration of that pipeline or you can't go to production unless the pipeline meets some criteria and so evaluating those things separately. And so, Sean was talking earlier about the idea of the open policy agent OPA right and that's one way of expressing a policy. In order to deploy to production, my pipeline must have executed these sorts of security steps and they must have passed to some sort of level. And so we've separated the policy from the pipeline rules themselves. And that allows you to let people edit the pipeline more freely. So at harness and our technology we use OPA we're big fans of it. I think the other major technology that I've seen banging around in the space is Kyverno, which is straight Kubernetes. There's probably a couple more out there but this idea of find a policy agent and layer it over your pipeline allows you to make that kind of read that needle. Like, I don't let people edit but not turn things off because if you can edit you can turn it off right like no you have a policy outside of the pipeline that solves that. I think that makes sense. I guess I was talking a bit about how we do have the edit but guardrails we use OPA. Sean, there's some questions here that are essentially how the deduplication works what our approach to that and harnesses. Do you want to talk to that a little bit. Yeah, sure. So one of the things that that we offer with our DevSecOps solution so that that's based on on two different modules, there's security testing orchestration and then another module dedicated to software supply chain assurance. You basically with STO, for example, you know that that is what gives you the ability to orchestrate security tests throughout the pipeline and your flexibility to integrate whichever open source or commercial scanners that you want to use and and invariably, you know, you're going to use combinations of scanners at different points. Perhaps like just different scanners of a specific type but the deduplication is something that we automate under the hood. And when you get your scanner output instead of, like in the classic, sort of like taking those first steps of, hey, we, you know, we've identified these vulnerabilities and then you have no mechanism of resolving that list into a manageable process for for your developers. What this does is this, you know, if you're in the harness platform, you'll you'll see a categorization, you know, they're basically four levels of vulnerabilities and this critical high medium and low, you know, which I think is pretty common but but all of that is presented in a way that's just easy to, you know, we've triaged it for you and then it'll identify which ones are duplicates. You know, they may come from two different scans from the same scanner or they may come from two different scanners entirely but but that's something that that we do under the hood. And then, you know, companion to that is really the remediation guidance so just offering up a few easy steps and some context around, you know, what does this vulnerability really mean, and what are the recommended approaches for for resolving it so those are two things that we do and we can present back to developers, you know, post scan. If I, if I may add to that show me just a question. I think the key here is also how simple you make it right because theoretically I can take, you know, other, you know, different type of city solution different type of platform and I'm sure there are a lot of things they could do in like hack and script and create these policies and and try to build this process that but the key really lies in how easy it is and and you've mentioned that in a few words right what we do is at Harness is we we talked about you know shifting information and not like the processes and the workload right so the developer really from the developers perspective, just gets a dedicated list of prioritized issues that they should care about. They can easily see what what security vulnerabilities were in the baseline versus you know what was introduced in their own code right so don't know maybe you know you don't want to introduce anything new but maybe something was there before and it's okay. If there are some violations right you have a built in extension process right so you don't have to go to slack and emails and something right to talk to the security things. So, so really the key is how easy we met you know we make it or your CIT platform makes it for you to implement these processes, for example you know policies right. Some people might think you know policies oh my oh my god this is, you know I need to learn another thing and this is another, you know, language but you know we make it super simple right because you can just use AI policies and in a natural language that's what you want the policy to do when boom you have a policy created for you right. And if you have security vulnerabilities I mean again we use AI for example for you know to suggest fixes and how to remediate that right so you don't have to be a security expert. So, you know there are a lot of things it's not just the end result it's how easy it is to get to this state in the product. Awesome. Well, I think we are running out of time here so if anyone wants to learn more about harness you can go to harness IO I've also dropped links in the chat to how we approach DevSecOps, as well as a wonderful study about a customer who's doing this sort of stuff and saw a lot of success. So with that, I want to thank everyone for joining us and pass it back to Candace with the Linux Foundation to wrap up. Thank you so much Eric, no far and Sean for your time today and thank you everyone for joining us as a reminder this recording will be on the Linux Foundation's YouTube page later today, we hope you join us for future webinars have a wonderful day. Thank you.