DevOps Tools: Securing the Software Supply Chain

Hello everyone. And welcome to our equipping. A call Analyst webinar, DevOps tools securing the software supply chain. This webinar is supported by keeper security and the speakers today are Craig Lurie. Who's CEO of keeper security. And me Martin, I principle Analyst Analyst, before we start with our today's topic, some quick housekeeping information. So we are controlling audio. You muted centrally. You don't need to care about it.

We will do a Q and a session by the end, we are recording the webinar and we will provide the recording as well as the Slidex SLX for download to you relatively soon after that webinar. And we will do a few polls. And with these polls, we'll gather some, some information we it's relevant, and if time allows, we will, and also failure results of these polls during the Q and a session. So having set this, I'd like to have a first, a quick look at our agenda of today.

So the first part I'll give a sort of a high level overview about security along the software supply chain, which is an topic which gets gets more and more relevant and more, more and more discussed these days also in light of several of the supply chain attacks. So or software supply chain attacks, which became quite prominent, like say solo end in the second part. And Greg Lu will focus on a specific aspect within that. And I'll also touch this already, which will be the secrets management within software supply chain security.

So secrets of different types are a very sort of relevant element within the entire security topic and managing this well as of sort of speak upmost importance to, for, for software supply chain security. And as I've said already, then we will do our Q and a session. Before I start with my slides. I want to run the first poll. This is more about how many people do you have in your developing. So how many developers do you have? Is it more than 100 is more than 10 to 100 ranges below 10?

Or do, do you don't, you know, so I'm, we are just curious about that and looking forward to, to receive your responses, the more people participate, the, the more valuable the results will be. So take a little time, leave it all for out of 15 seconds or so, and provide your major about how this looks in your organization.

So second, five seconds or so we can close. Okay. Thank you. What are we talking about today? We are talking about software supply chain security or security along software supply chain to bring up a definition for that term software supply chain security or CS refers to the ability to secure the software development lifecycle. So still see very common term process throughout development, testing, deployment maintenance phases at every point, along the way, including along the whole C I C D pipeline.

So all the tools that are used and that, so it's at the end, it's about how can we protect everything from where code is created and held to build, and then finally bringing it to production and ensuring that this is really so what has been coded that it hasn't been altered and how can we do that across all the different tools? And one of the big challenges is there are many, many different tools from the development tools to the runtime environment, to the cetera. And there are a lot of different parties involved. This makes it quite complex.

So this is something which also usually can't be solved by one single solution, but it's a set of different technologies, which is required to solve that. But we see also some tendency to, to more of more and more vendors to focus on this field of software, supply chain security, or securing the software supply chain from different angles and what we did mainly my, my colleague, Richard, who is currently working on leadership compass, which gives really comprehensive market perspective on this, this segment, what are the key capabilities?

And I think this is important to understand for, for what we are talking about. So when we look at this, a broader theme of software supply chain security that it's at the end, a solution that combines a series of capabilities, which are today frequently isolated. And as I've said, it probably will not be that there's single tool that solves it all, but it usually will be a good combination of some product best of free products cue also to special specific capabilities.

It'll be interesting over to see over the next years how this is evolving because we see many organizations entering this field, many software renders in from different angles, as I've said, including some, some startups. And so it's, it's a market that is evolving. And so when I look at these eight key capabilities, the first one is source code integrity. So how can we avoid that source source code? Isn't attacked, isn't altered because really that is an interesting point of attack and interesting attack vector.

If, if an attacker manages to, to interest sort of what he wants to interest into the code, then it's sort of at a very source. So we need to enforce integrity. We need to first build integrity. So when source code is sort of built into I'm long enough, I would say compiled. So during the build process, we need to ensure that other that happens, what we expect to happen.

Nothing is fraudulently done here, malicious code injected, whatever we need to understand the vulnerability of code and other built and deployment artifacts, because beyond the code, we also have all this infrastructure, everything is code, which is generated. So it's, it's more than code we need to look at. So is it vulnerable? What are the artifacts? Where can attackers take? We need to automate or along the chain, and also at intelligence for, for analyzes. So understanding where are the risks? Where are things going wrong? Where are the anomalies? And automation is?

I think key is the more complex environment is the more we need to automate. Cause especially when we, you know, we, we think agile development, that means it is about continuous change. And I have a strong belief that, that we can't handle things that are changing continuously with mainly manual administration. This doesn't fit to each other. So we need automation which understands what needs to be done based on policies. Cetera. What we also need is broad support for wide range of different technologies in source management, CICD tools, cetera.

And so, so if you're not the developer, but more security person and to talk with developers and then they bring up, we use that and that, and that, and that, and that, then there's usually quite a long list of different tools and it's also frequently changing list of tools. So what is popular today might be very different from what it has been popular or popular three years ago, or probably it's different from what will be popular in three years from now, we need visibility.

So applying security controls, measuring understanding what is the current state we need standard supports wherever standards exist already. And we need secrets managements because at the end of the day, a lot of what's happening in security in this space is about secrets. It's about keys and certificates, passwords sometimes even good, old ugly passwords, not good, honestly, old and ugly. This is one of the key elements here, and we need to do that well or different types of credentials. They can't be dynamic. They changed.

They are, can be hard, coded and batted. And we need to get a CRI on that because it's a, it's a in, in the term already, secrets are what we need to protect because surely techers are after the secrets. We're seeing quite a lot of innovation in this space. And when I look at some of the key innovative areas or innovation areas, fields of innovation, then we also have quite a list of that. So I picked the ones which have a, sort of a high priority in the research we are doing well. That is so does, does everything as code security. So how do we secure that?

How do we secure infrastructures code, etc. Are all the declarations because they're ful exploited, they can be attacked. How do you identify proprietary code code that have been in, in certain manner, which is sort of, for instance, that code that is in standard libraries, how can we automatically remediate vulnerabilities? How do we bring all this information together into graphs, into showing how all these syncs fit together and how, how information is flowing and connected. Can we use machine learning for software supply chain security auditing?

Do we have software dependency, crafts understanding what is in the software still, even today, still a lot of organizations struggle with understanding, do I have issues with the Lockford tray or not? And this is out for quite a while. And when it came out, I spoke with quite a number of, I, I spoke with quite a number of vendors and they said, okay, we, we are currently working hard just on understanding where it's used. And I think a software should know honestly, to understand. So having some software composition Analyst showing it, and then we have the secrets part to manage secrets.

What do we need to do? We need to scan. We need to find them. We need to put them under management. So this entire secrets part is a key thing for a reasons center of this slide. We need to manage the DevOps life cycle and the API life cycles as well. So API is managing API security important. You need to check the security of containers. We need to have things like chat off support.

So, so how can we support people in, in doing these things right? Also developers need support. Post-deployment monitoring. What happens when we have it out? Is it still unaltered? It's still the same stuff. So there are a lot of things which are happening here, but one of these things really is to my perspective. And that's also clearly valid. W because I come from the identity and security side, the secrets part for me is one of the essentials within securing the software supply chain. It's not the only thing to do it's, but it's a very important part.

And what is it when we are talking about secrets that we must trade well, that we must not share it is we need to keep them secret. And it's so big and specialized as capability that we also need to, to run this, something of its own.

So what, what are the four aspects I see here primarily the one is finding secrets. So scanning for passwords, keys, tokens, whatever encode, or other artifacts, where is the stuff? What we don't know, what we can't get under control a problem, and we need them to get it under control. So we need to enable that we can manage them that can require sometimes changes, but it's also, how can we get control about things which are there without requiring for instance, change to code or stuff like that.

And then we need a life cycle for that, and we need to do that across the entire life cycle of secrets. So looking at the sort of regular changes, so updating secrets, retiring secrets that aren't used anymore, all that stuff is something we need to do. And we need also to deliver visibility and reporting in the end, it's about providing insight into what is happening here to deliver it as a security control, to understand where are things going well, where do we still have issues? Do we have secrets that are, are not well managed?

Are, do we have unmanaged secrets? We have identified. So specifically when we start really scanning for secrets as it's the same with, with many things.

Once we, when we do the first analysis, a lot of alarms show up and we, so we have a, usually also great success in the initial, in the early stages of a project because we get quite a number under control, but then it gets interesting because like in the parade rule, the 80% are definitely way easier than the last 20%, but we need to get better there. So this is what we need to do here.

And this is trust my intro into this scene on why I believe we should care for software sub and security in a holistic manner, why we need specialized capabilities and why secrets management is one of these key capabilities we need for increasing security for our software supply chain. Before I hand over to Greg, I just quickly wanna launch the second pole for today.

And, and I'm we just curious about how do you handle software supply chain security today? So is it a centralized approach across the organization, or do you have a couple of point solutions in place or is it only partially addressed, but you know that you have gaps and issues? Or is it just, you don't know again, we appreciate your participation and these polls and I give you another 15 seconds. So a few seconds, please enter your response. Okay.

Witham, thank you very much for participating in this poll. And with that, I hand over to Greg and Greg, right? I will talk about main points of infrastructure, secrets management. Thank you, Martin.

That was, that was great. So my name is Craig leery. I'm the CTO and co-founder of, of keeper security.

So I'll, I I'd like to, I'd like to leave some, an opportunity to go through some of the product demonstration and, you know, also for questions. So I'll go through just a quick overview of that, basically that last aspect of what Martin was describing, which was the secrets management piece. And how is that managed, you know, from a practical standpoint and the tools that are used by developers and DevOps to manage secrets and also to prevent data breaches.

So what, what is secrets management access into critical infrastructure? So this is tools and services and accounts that developers and DevOps are using to access infrastructure. And this could be database passwords. This could be direct access into software and systems that control data.

Now, one of the things I, I just will just kinda show on the screen here is that some recent news that was just announced, you know, there was some talk about this large data breach that took place in China. And there was a direct, direct correlation to what we're talking about today, which is that there was a huge data breach. And this data breach was caused specifically by a leak in source code where the, where the credentials for a particular database, in this case, an elastic search database was coded straight into source. And then this source was leaked.

So this provided someone with direct access into a database. And so this is really a perfect example of what our product prevents and what generally secrets management would, would prevent in this type of, in that type of, of leak. So what our secrets, it could be just basically a login at a password.

So, so, you know, if you're using a service that requires just a basic login, a typical example would be like a, like a, an API key for, let's say, Twilio for sending mail or for another service for sending SMS messages. So a very common application key would be again, using using third party services to transmit information. And if those got leaked, those could be abused by an attacker.

Also, of course, SSH keys and other access keys that would provide an attacker with direct access to infrastructure there's digital certificates, private keys. So oftentimes when you're deploying a piece of software, you, you need to have a private key for securing that connection for securing that server and those private keys have to be kept somewhere, where are they kept? They could be stored on a developer's workstation. They could be stored, or, you know, directly onto a file system. That's not encrypted or a shared drive.

You know, so these private keys are really critical because they could be used to perform man in the middle attacks on, on applications. And also another secret could be a one time, a one time password. So T OTP tokens, anything that's, that's typically used by a engineer to be able to access infrastructure, where are those one time passwords stored? So of course, like I just showed with this, this hack that just occurred in, in China secrets management is really critical because credentials are used for nearly all of these major data breaches.

And so it's typically privileged accounts and these privileged accounts provide direct access to either databases or infrastructure or provide access into backend systems that can be abused. And one of the things that we do as a product is that we focus on protecting any credentials, any sort of data, API keys, any secrets that need to be encrypted. That is what we focus on.

And we allow these developers to, and our customers to remove hard coded credentials, remove the pains of, of dealing with credentials that are replicated in different environments and sitting on developers, workstations and those type of situations. So the core end user for our product is typically DevOps teams, which are using our product for deployment. So one of the things that I'll show is, is how we integrate with things like GitHub actions. So DevOps teams will typically integrate our secrets into their pipelines and use that to deploy software.

It admins typical use case for those customers would be things like active directory, service accounts, or other privileged accounts that are, that are used in their day to day work. So they may not necessarily be people who are deploying software, but they are definitely people who are managing software and managing those privileged accounts. And then of course, software engineers. So software engineers are, are typically not provided production access, right?

So they're going to be provided with their own set of secrets that are gonna be used for accessing, let's say their development environment, their QA environment, maybe a staging environment. And these, these are the people who are typically the ones that are, are, are hard, coding, credentials into code, and, you know, they need a, they need a system for which to, to deploy their software through the pipeline and remove those hard coded credentials and make it easy for them.

And, and also to prevent them from checking things into source code, sorry, here. So what is the, the core components of our platform, which I'll, which I'll show just a kind of quick visual demo of it is that we've got SDKs in every language possible.

So, so we provide customer with SDKs in, you know, Java, javascripts.net, Python, everything, and that allows them to directly integrate into any programming environment and also direct integrations into popular C, C D tools. So that could be Jenkins, give up actions, on-prem cloud, any sort of third party pipeline tools, and also a CLI.

And the CLI has some really special capabilities for doing things around, not just accessing through CLI, but also for protecting scripts and wrapping applications that, that weren't originally developed to, to include secrets and to hook into third party secrets tools. So we can replace environmental variables and things like that. So I'll jump into the, the product and it'll be a little clearer just to kind of see how, how the users go through that experience. So I'll close this out and open up demo environment. So this is our secrets manager homepage.

There's a, there's a video with some demonstrations and things like that, but I'll just jump into the, the product, the core product. So we are, are a zero knowledge fault, which means that all of the encryption and decryption of user's data takes place on the device. So the secrets that are stored in our product are only encrypted and decrypted on the user's device or on the target system that is executing our APIs. So we do not have the ability to decrypt the data.

We, we only store cipher text in our data centers. So the user, now I'm talking about just the human that's going to manage the information is going to typically log in to their vault using identity provider. In this case, I'm using Microsoft Azure with a hardware based UV key. So I authenticate into my, into my vault using my identity provider. And then my information is decrypted locally in this vault. So this vault is, is really the way to think that, think about this in regards to secrets is that you have to have of course, humans or admins that are managing the information.

And then from there we provide access into applications. So as one example, I have this folder within my vault, and this is a folder called connection manager secrets. I have another folder called development secrets. And so things that you would store in these folders, an example would be like an API key, or it could be a, it could be a, a credit card that's used for making a payment, or it could be, let's say a pager duty account or a database. So you have different types of content that you can store in the vault and everything is encrypted locally on the device.

I'll go up a little bit to this other folder that I had started with this connection manager secrets folder. So this may be used for different things like here's a, here's a database. So I have a database connection. I also have a different database connection, SSH keys, windows, server, credentials. And so really this could be a combination of, of information that developers or DevOps would use for automation. And it can also be secrets that can be used for establishing connections into those remote systems. So now that I've got this folder filled with secrets, look over here on the right.

And I see the different types of people that are going to have access to this. So I can define teams.

Here's a, here's a team called secrets managers, and this team has the ability to manage records. And I've got some additional users that have specific access into this folder. Now these are the, the administrators who can go in and modify and have access to the actual credentials. Then I also have applications. And so an application can be, as we discussed, it could be something like a Jenkins pipeline, or it can be a GitHub action or something like that. So we have the ability to assign applications.

And the way this is done is I would go into our secrets manager tool and there's a bunch of secrets applications here. So I have one called GitHub actions. I have one for Jenkins and so on. So I have different applications and these applications can be assigned to folders within the vault and an application can also have specific devices. So I'm gonna go to this, to this app, this secrets manager application here, it has access to two folders, and then I've got a bunch of devices that have access into these specific records.

So if I wanted to add a new device, I can just add one, call it for example, demo environment. And I can lock down access to this application to a specific IP in addition to using certificates and our encryption model for, for authentication. So I'll generate an access token. We call this a one time access token. This can be used then to transfer over to a target environment where I need to be able to access those secrets. So for example, I have a, a terminal and I'll show kind of like how the CLI is used to access information.

I just simply initialize my secrets manager target, and I can say KSM profile in it with a particular token. And now this secrets manager endpoint has been initialized. And I can simply say KSM secret list to give me a list of the available secrets. So this is kind of like the CLI interface of, of how you would utilize this tool. For example, I can say KSM secret get, and let's say, I want to get this S3 bucket access key so I can retrieve that. And this gives me the access key, the secret key.

And if I wanted to unask that I can supply some additional information to unmask if I wanna actually retrieve that. So there's other, a lot of tools that are used to gain access to the information, but at the end of the day, what this is doing is, is demonstrating how a client device, in this case, a, a secrets manager CLI is able to retrieve secrets directly from the vault without having to deal with storage and without having to worry about deploying any sort of vaults anywhere in en environment.

So it's a direct communication between the target system and the vault, but it's using full encryption. And so all the information is decrypted locally on this device. So this is just an example of a CLI another example of this, which is very relevant to what Martin discussed and also to the, this recent, this recent attack in China was regarding source code. So as you can see here, I'm gonna show kind of a before after of, of perfect example of how you would utilize this in code. So a typical program, this is just actually just a program that reached what connects to my SQL database.

And it retrieves some information. In this case, it just runs a SQL query and prints out the result. So you can see here in this code, this is what would happen before using keeper. So this is what, what a developer might do. And this is very similar to that, to that leak of that database in China. But this here is showing, you know, user connecting to database, and they're gonna hard code some password. They're gonna hard code the user information. They're gonna hard code this, this address. And so they would execute this and they would maybe check this into source code.

So this is really where the, the awful things happen is because this gets leaked eventually. And then someone gains access now to that database.

Now, when you integrate with keeper secrets manager, you simply replace the, in your source code, you're going to actually replace the query. So instead of using hard coded information in the script, you're going to just directly initialize secrets manager. In this case, I had a token that was initialized, but this token is only used one time. Hence the name one time access token. And after the access token is used one time, it is, it can be removed. And now from a source code standpoint, I'm able to retrieve secrets directly from my vault.

In this case, you see it references what we call a device U ID, and this is not a secret. This is a public U I D that represents a record in the vault. So if I go over to my vault and I can just search on this and you'll see that this represents a, my SQL database with a particular host name, a login, and a, and a password. And so from the source code standpoint, I'm just retrieving a secret from this record identifier, it's pulling out the host name, the username, and the password, and then it's establishing a connection to the target environment and executing the query.

So when this is run, you'll see that it executes the query. It generates the results from the database, and no secrets were exposed in the source code. This can be safely checked into a repository, and there's no danger of that. And so also one of the key aspects of this integration from a management standpoint is that if, for example, the database password changes or needs to be rotated, you simply as the user, as the human who's administrating, the system can simply go in and rotate that password as needed, execute a rotation and, you know, make the changes, save it.

And it immediately takes effect. So you don't have to update 20 million systems to retrieve the correct password. It will always retrieve it in real time from the source of truth, which in this case is the fault. So that's the keeper vault. That's an example of using passwords and secrets directly from the vault in third party tools. Now this is our secrets manager documentation, and, and like we discussed there's many different SDKs available for integration. I just showed you the, the Python DK, but we have available the Java JavaScript, python.net go, and also PowerShell SDKs.

So PowerShell plugins provide all of the functionality of being able to retrieve secrets, push secrets, update, rotate, passwords, things like that. So you've got these developer SDKs, and you also have direct integrations into, for example, Ansible systems or a very popular one would be like GitHub actions to be able to push secrets directly through pipelines. Also things like Terraform, which is very popular. So the ability of course, to have Terraform scripts that are building and, and deploying infrastructure, to be able to retrieve passwords, to be able to create secrets on the fly.

So, for example, if you're going to, with a Terraform build, go and, and create some environment of a VPC with a database and an application server, you can actually generate passwords, strong passwords and secrets with our Terraform integration so that you don't have to hard, hard code that to scripts. So a lot of tools available, and we are always adding new integrations all the time. Now from an admin and management standpoint, the user or the administrator will sign into the keeper admin console.

And in the admin console, this is where rights and privileges are provided to different team members to be able to store secrets or to manage the, the use of secrets. So in our admin console among O other things you can, you know, you can provision users and you can set up role policies and things like that. But we have this secrets manager management dashboard built into the admin tool, which allows you to understand the utilization of your users.

The number of, of API calls that are being made, the applications that are being used to access the system and specific events that are taking place. So with our auditing and reporting tools, you have the ability to analyze all of the event based actions that are taking place. So for example, here's me just a moment ago, accessing my secret directly from some Python code, from a certain location, an IP address with a very specific activity. So KSM device Mac demo has accessed secrets from this application. So as you see here, this application is a, also a public identifier.

So within the admin console, within these event reports, it never decrypts data and it never discloses secrets, but it provides metadata around what action took place. Where did it take place from what specific application device and so on. So you have very detailed logs that are taking place here, and you can take these logs and you can actually export them straight into a SIM solution. So if you're using something like Azure Sentinel, you can deploy those directly into those target SIM solutions. So Sentinel or, or Splunk or syslog or things like that. You can also set alerts.

So if I want to be alerted anytime, for example, that a new secrets manager application has been used, or if I wanted to know anytime that a record has been updated within a secrets manager app, I have the ability to set alerts and get notifications on any secret spaced actions that are taking place within the platform. And likewise, we also, because this is integrated into our, our password vault, and it's a fully integrated solution.

You have the ability to also track things like breach watch events, which are specifically actions and events that deal with whether a secret or a password has been found in a dark web data breach. So our breach watch tool will analyze and hash and look at these specific password fields or secret fields and notify users. If any of those secrets have appeared in dark web data breaches. So we handle and process that through our breach watch tool. So that's an overview of the, of the platform. I know I went through a lot of different functionality.

I understand we have gonna leave some time here for Q and a, and thank you very much. Thank you, Craig. You very well illustrated the complexity of this world. So we are not talking about one secret or, or a few secrets, but we are talking about huge amounts of secrets for a huge number of developers in very different places and getting a CRI. This is truly one of the things we, we need to manage, because as I've said, we've learned in the past few years that things can go horribly wrong when tech risk manage to, to gain access into gain access to the website.

And so to, to the software software development cycle. So I have a few questions already here and, and maybe we, we get some more or the next couple of minutes. So the one question is if I set up KSM, so you keep a secrets manager with my build system, what happens if we cannot connect to keeper, do my builds fail. So what is the risk of things failing it? Automation? Sure. So one of the great things about the SDKs and we definitely considered that when we built this is that all of our SDKs have an offline mode.

So if, if for whatever reason, the application and the, the integration is not able to communicate to our system, whether it's on your side or our side, it will revert back to a cashed local encrypted secret. So it'll, it'll basically pull the last set of information from a cash and decrypted locally, and then it'll use those secrets for subsequent queries. Yep. Okay.

So, so you, you ensure that when you have a very highly automated build process, which is quite common these days, that it will not fail due to whichever connectivity issue might arise in this area. Yeah.

You know, there's, you know, with, with tools, let's say in the past, people were using hasp vault for this, and, you know, it's a different type of situation where you have to deploy some piece of software in your environment. And so you're depending on that to be running, and you're sort of operating that in our model, it's directly from that integration, let's say that pipeline, that GitHub action pipeline, it communicates directly through our SDK to our cloud to, you know, to authorize the request, retrieve the CEX and then decrypt it.

So it's a slightly different model, but it also handles that offline scenario. And so that is the first thing that, that everyone asked us.

So, and also, you know, we have, we, we do have a very high uptime, you know, 99.9, 9%. And we do track all that with our, with, you know, online, but in the case that something is not accessible, the offline cash is absolutely built into every integration. Okay. Another question we have here is I'm already using AWS key management for secrets, so that's, you're still using replace it.

So, so one of the things we've done is that we've built an integration directly with, with AWS, PA you know, key vault and Azure key vault. So what you can do is, is you can transition where you actually can synchronize the data between the two. So you can use keeper secrets manager, and you can, you can hook up the AWS or Azure vaults as a, as a data store or as a synchronization. So we have a plugin directly for that. So that is another common question too. So you can go direct to AWS, or you can just use our integration, which keeps the two in sync. Okay. Got it.

And for, for now, maybe more questions coming in, another question, which is here is how do I set this up with different environments, like development test for Q and a and production? Yeah. So that's a, that's a perfect example of, of our use of secret to manager applications. So what we do is is you, as the DevOps engineer would define different applications, you would call one, let's say development and you'd call one QA and one staging and one production, and then you would assign rights and generates device applications, device endpoints for each of the target users.

So if it's for the QA environment, the QA people can only access and those specific folders and those specific secrets. And if it's a dev environment, you only provide access into those secrets and those applications. So you segment based on the environment. And the nice thing about that from an encryption standpoint is that it's, it's not leaking information, it's not over allocating access, so you can target access to just specific environments and just specific folders in the vault.

So how do you see CTO, your, your, you think a lot about this, how do you see this entire area evolving over the next two to three years? Well, I see that, that, you know, tighter controls over this environment and enforcing these policies is important.

So, so most, most development organizations have migrated to pipelines such as dev you know, GitHub actions and that platform is evolving rapidly. And then you also have, you know, so there's a migration taking place between on-prem pipeline tools and cloud based tools. And so if they haven't already migrated, they're in the process of migrating or thinking about migrating.

So, so I think that's really the, the, you know, over the next couple years, that's where the, the focus is of these dev teams is if they haven't migrated, they're, they're working on that process and it's not, it's not fast, right? You have to actually re rewrite your, your scripts and you have to completely redo your, your build process. So I think that's really a, a big part of it and then securing that pipeline.

So we get a lot of questions around deploying infrastructure and the complexities around that, and how secrets are handled because DevOps tools to produce code and to, to ship code into production is one thing. But then also shipping infrastructure through things like Terraform is, is another. And that's just, it's just as dangerous in terms of the ability to manage the secrets that are used by those, by those tools. And so really the evolution is securing the pipelines with, with, with secrets management on those DevOps developer pipeline tools for publishing code.

And then also, secondly, they're the focusing on automating infrastructure and making sure that those infrastructure scripts and the API keys used to, to build those scripts and to publish those scripts and to execute those, those access keys, those that are actually used to execute those Terraform scripts have to be protected. And the, the, the secrets within those, those build scripts and those infrastructure scripts have to be really thought through and protected.

And so, okay. Yeah. So I really see that's where the that's where a lot of focus is being spent. Okay. Thank you very much for this insights and is that we are at the end of today's webinar. So thank you very much for everyone, for listening to our call Analyst webinar. Thank you very much to keep our security for supporting this webinar and thank you very much, Craig, for all the insights you've provided. Thank you. Thank you.