Name: Your Mission-Critical Dev Tools Have No Backup. Your Dev Velocity and Your Business Pays the Price.
Uploaded: 2026-10-21T10:39:09.524Z
Duration: 1 h 20 min 8 s
Description: Your Mission-Critical Dev Tools Have No Backup. Your Dev Velocity and Your Business Pays the Price.

Transcript for "Your Mission-Critical Dev Tools Have No Backup. Your Dev Velocity and Your Business Pays the Price.": Hi, everyone. Welcome. Thank you so much for, joining us today. I'm Anurud Dubey. I work on product marketing for Rubrik's DevOps protection solutions. So as you can imagine, I spend most of my time thinking about the code, the pipelines, and all the automation that your engineering teams live in and your business increasingly depends on every day. And hey, everyone. I'm, Irshad Alana. I lead our SaaS data protection, product team here at Rubrik, including the Atlassian side, so Jira and Confluence. So we're only focused on the code. I think about everything around the code, how the work gets planned, documented, and shipped. And, that splits kind of the point of the discussion today. Yeah. It really is. So before we get into any of it, I would like to ask all of you in the audience today a quick thing. Just think about your own environment for a second. You almost certainly have a mature tested backup strategy for your VMs, your databases. It's essentially your soft problem, and Rubrik was the one who probably solved it for you. Now ask yourself the same question about your SaaS applications. Specifically, let's look at the SaaS solutions which support your company's entire technology development life cycle, your GitHub, Azure DevOps, Jira, and Confluence. Do you have the same enterprise grade protection there? For most organizations that we typically talk to, the honest answer is a simple no. And that gap is really what the whole session today is about. And we'll talk through why your entire developer workflow has quietly become one of the most critical and, in most cases, least protected systems, that you own, what threats, are hitting these, this developer workflow, and also new risks coming to the forefront with, AI. So, let's get into it. Absolutely. So let me start where the industry started. About ten, fifteen years ago, most of us thought of GitHub or Azure DevOps as mere developer tools, place where engineers checked in their code at the end of a sprint. That mental model is completely out of date today. In the modern enterprise and specifically modern IT, these platforms are the operational code of how software gets delivered. And not just the code, but the CICD pipelines that build and release all of this to the cloud as well as increasingly the infrastructure escort that provisions your, cloud automatically. That also is basically saved by many of the companies in these platforms. That's exactly why, it hurts when this data isn't there because of any reason. The moment GitHub or Azure DevOps goes down, you cannot merge any change. You cannot run a pipeline. You can't even ship a feature or push a security patch if you really need it. And because your infrastructure itself is now defined by the code that is being used inside these platforms, you may not be able to rebuild your cloud, infrastructure dynamically. You won't be able to provision new VMs or databases if you need them, for any reason. The entire delivery engine essentially stalls, and you can imagine your most expensive workforce, essentially, your developers are sitting idle while the business waits for everything to get, back up and running. I think that's exactly right, but I'd also zoom out a bit more. Right? Because code and pipelines are really one part of the bigger picture, and modern software doesn't really get built in a single tool. Right? It kinda moves through this, life cycle where you're planning the work, you're designing it, you're documenting it, you're developing it, you're coding it, you build it, test it, release it, deploy it. And then, of course, you're monitoring in production and then, you know, some of the changes flow right back into your next change that you're planning. So, really, as people are functioning in this DevOps continuous loop, they're not operating necessarily in a single tool. Right? Of course, all the coding happens in platforms like a GitHub or an Azure DevOps, but they're using things like Jira for planning, for work tracking. They're using confluence where a lot of the architecture and the designs are living, shared knowledge spaces. Right? So all of those things are also surrounding kind of some of the core things, used for deployment like, GitHub and Azure DevOps. So, really, what we should be talking about is how do we protect this entire workflow that is a chain of all of these different specialized platforms. Yeah. That's fair. I think... Though let me bring it back to our engineers and the code for a second because those planning and knowledge tools aren't just a side, concern for my engineers. They are what makes that entire development work possible. The requirements and the context in Jira are what tells, a developer what to build, and the runbooks and architecture, docs and confluence are what they open to build and update correctly or essentially stand up a service, again. The tickets flowing through Jira are essentially the work itself. So if that knowledge disappears, our engineers don't just lose a Wiki. They lose the very essential context. They need to write even a single line of code with confidence. And that alone is a severe hit to, the developer productivity. And that's... And 100% agree with you, Ani. The the place that I would push, that thought is even a bit further. Because, really, what these platforms are, it's a connective tissue not just within engineering, but to the rest of the business as well. Right? And if you think about, for example, let's say your customer support teams or your solutions engineering team. Right? The the place where where they're going to get that technical product information from is very often a place like Confluence, a place where they're managing, tickets that are coming in from customers, right, is very often living, in Jira. Right? So your support teams, your, technical product management teams, your marketing teams, your legal, teams, your security review teams for the features that you're building, All of these kind of downstream teams also start to get impacted if the data that's living within this, knowledge layer, and other platforms also contributing to that developer workflow all of a sudden go down. So it's not just the engineers, but really the impact of it is developers plus support plus field plus all of those downstream, teams that rely on this critical information to make that developer workflow work as well as everything that comes after. You know, I I think you're right, and I probably hadn't been framing it that far wide. And what I can add from the code side, is the proof that this is very far, reaching impact also works there. So to our customer engagements, what we have been able to do is map out the blast radius of, code and pipelines being, unavailable. It transformed, yes, for sure, stalled updates to cloud infrastructure itself. But because that infrastructure and those applications, all of that eventually is powering the customer experience in terms of the customer facing applications. So if this information is... This data is unavailable, all those fixes, updates are basically getting paused, and your customer experience is getting impacted right off the bat. So put your point together with us, I think Jira and Confluence carry an equal level of impact, not just through the technology stack, but to the business users and basically through them to the experience that our customers or any of our audience members' customers are basically having through their their own build technology. And two more things that makes it even more concrete. First is that this knowledge and planning part is not even as clean that Atlassian plans and Git is meant for coding. Even GitHub and Azure DevOps increasingly carry their own planning, collaboration, and, knowledge layers. On the GitHub side, you have issues, projects, pull requests, and Wiki. Azure DevOps also comes with their boards, work item, and Wiki. These layers show up across all these platforms, which means that any companies right now running a combination of these, tools depending on, some legacy reasons, tooling maturity, or even leadership preferences. So there is no single, standard stack, and most customers are probably using a mix of all these different services that we've been talking about. The other thing I I want to, talk about is how ubiquitous this has become increasingly, and it has... It's no longer niche. So Gartner essentially said that 80% of the organization will rely on DevOps platforms by the year 2027, and that's coming next year itself. And, GitHub, has already been passed, four twenty million repositories a couple of years ago. That's a huge, huge jump, and it's only getting, increased with all the AI action that you are seeing in the market. And, on the Atlassian side, 83% of the Fortune 500, companies are using this product across 300 plus organizations. So that workflow that we've been talking about and trying to articulate has become that foundation that now whole business in in some capacity is, depending on. So the mental model that I want our audience to have for the rest of this talk is this entire workflow. Plan, know, build, ship across all... I've just essentially spread across all these platform. This workflow is the real unit of resilience. And, the uncomfortable and unfortunate part for many many people in the audience may be that it was... This, unit of resilience has never been considered for protection with the same regard as probably we've been doing with our VMs, our cloud, our on prem data. And therefore, it has essentially become the the weakest link, and this is the link probably we'll spend, talking more about in in in today's talk. So let me first start, with the code layer, because that's where we see some of the most dramatic attacks happening, in the in the recent times. And and the pattern that I want people to notice is that attackers in the space aren't just stealing the data. They're actively destroying this. They are wiping repositories, overriding histories, deleting releases. And a couple of real examples as you can probably see on the slide, one of the one of the things is called the Git locker campaign where a single phished credential was enough for an attacker to wipe out five entire GitHub organizations. One again and five orgs are completely gone. That's a massive loss for any any company involved. And this... And and the second, attack, in this in this in this thread is the three d supply chain attack. A group of group of attackers basically held, long lived, these tokens and used them to delete one seventy eight legitimate software releases. And this not only impacted the software delivery of the company involved, but also many of, the mainstream customers who were depending on their repos to use them in their own development. So it has a wider blast radius involving the company's customers as we had described earlier. Yeah. And it's it's it's, you know, significant impact, Dan. It's worth kind of double click... Clicking on the thread, running through those those two two scenarios that happen, that attackers are not hacking in. They're logging in. Right? That's become the most, common attack pattern that we see today. Phishing, credential stuffing, MFA bypass, all of those things are things that attackers basically are using to get get legitimate access and credentials to your system. And once they have that, they're not tripping or triggering any sort of security alarms, but they have access then to all of the data whether it is in your core repositories or whether it's in some of these other adjoining SaaS applications like your Atlassian tenant. And then they can... Once they're in with those legitimate admin credentials, they can start to delete data, corrupt data, exfiltrate data, all of it without triggering anything because it starts to seem like, hey, it's just normal usage. And so that's the that's the important thing for the audience to kind of keep in mind is is this new attack pattern around that identity compromise of users, logging in and not not, hacking in. Yeah. And that makes complete sense. And that's, again, still the attack side of the things. Right? Running Ryan alongside is a second big problem, which is just plain service disruption. So across DevOps platforms, there have been close to 500, significant incidents in a single year, and we're talking about the year 2025. That's the last year. And it's not just the coding tools. It spans Atlassian side too. So GitHub, Azure DevOps, Jira, all in the same, picture adding up to nearly a thousand hours of major disruptions. GitHub alone suffered close to, eight major outages in just the two months of February and March of this year. And on the Atlassian side, the the same report has outlined that Jira incidents jumped to jumped 44% in a single year to more than twenty one hundred hours of degraded, performance. That's equivalent to over two fifty working days lost for any company that's using it. And there's now a whole line of reporting on how... On what this really cost and the hidden cost of DevOps and SaaS, SaaS downtime, for cloud business, cloud businesses. And because when these workflows do stall, the bill shows up in every place as we've been talking about. It's not just engineering. It's your support. It's your field, and eventually, it's also your customers. So this is a pretty pretty grim, picture overall. Significant risk to these workflows from all corners. Do you think, on average, are customers aware of this threat? Are they thinking about, resolving it? So, so when I... When we've raised this question, to some of our customers, so a good chunk of the customers have not really thought about this, problem, but there are, some people among us, maybe even today, who are somewhere, somewhat aware of this risk. But the common answer that we typically get is that, hey. We don't need any backups. We have Git history. At least in case of code, we have Git history. But let me show you why that's such a dangerous assumption when you think, and we can take example of a real case here, specifically something called the force push history override. So this example is of the glass one force memo campaign, which exposed exactly, why the version history is not enough. So in this case, the attackers, followed a similar identity based attack pattern as we talked about, stealing credentials, during an earlier breach compromising hundreds of DevOps, developer GitHub accounts. And then, they did... They didn't just inject the malicious code. They basically rebase legitimate commits on the default branches and post push the malicious changes back into their repositories. And here's what the... That force push actually does. It overrides the repository entire commit history. So the version history that folks believe that they can depend on is basically their safety net. Unfortunately, because it's... Lives in the same security domain as the production data, so the... When the attacker who has compromised the admin credential cannot only delete your repositories now, they can also delete the history alongside it with a single command, the git push force. Got it. So if I understand correctly, then what you're saying is what people assume their safety net is, really dies with the same keystroke as the code, basically. Exactly. And then version history can also be rendered use... Useless in some of... Some other cases. So let's say if you... If they force push junk over the code or run garbage collection or even encrypt the data in place, GitHub probably cannot support, in you getting back that data because all of that happened to legitimate credentials within the within the confines of the platform. And across the platform, there also have artifacts which which go outside of the repos in the pipeline, and that's also what we've talked about, the work items, pull request wikis. Once these items are deleted, there are, there is no way for, them to be recovered natively at all because there is, again, there is no version history, in in in in case of these artifacts. Yeah. Yeah. And I think that points to something that comes up a lot, on SaaS applications, which is basically the assumption underlying it all that is the shared responsibility model. Most organizations, I think almost more than a third of organizations, still believe that if something happens with their data, whoever their SaaS provider is will come to their rescue and is responsible for that data protection, which is completely untrue. The SaaS provider, all they're responsible for is maintaining platform uptime and main... Making sure that the service is running. That is all that their responsibility is. The data within the system and within the application itself is not their responsibility. Right? So this is a misnomer that is spread across so many companies that don't realize the importance of protecting that SaaS data and why some of the tools that these platforms allow for are more conveniences. Like, a recycle bin is a convenience. It's not really a backup strategy, and that's important for people to realize. So when you're hit with an attack, maybe recycle bin can help with small scale recoveries. But, really, to get real resilience, you cannot rely on things that were built for convenience like your recycle bin. So that's an important thing for folks to take away from here. 100%. And I think that native resiliency assumption, I guess, is is shows up on both side of the house. Definitely on the code side, but maybe increasingly so on the rest of the workflow, doesn't it? Absolutely. So so let let... If we talk about Atlassian for a second and some of the capabilities that are available, let's talk about, like, Jira and Confluence. So today, you have Jira issues. Now if a Jira issue is deleted, there's no actual way to get it back. There is no trash. There's nothing for it. So it's gone completely. Right? So that's immediate data loss. So there's important things that are captured for, let's say, a customer conversation on that. You just cannot get it back. Right? And other things are, like, confluence spaces, Jira projects, those kinds of things. Yes. There's a recycle bin for, sixty days. But if you think about the scenario we talked about earlier is, let's say, your admin credentials took, Atlassian are compromised. Someone could come in there and completely hard delete everything. So it might not even be there for the sixty days anymore. Someone comes and maliciously wants to impact your organization. So, again, some of these tools by the native providers are great, and they're built for convenience, but they're not providing you true resilience. They're not a real backup. And then depending on the circumstance you're kind of encountered by, like, if you have to do a really large scale restore, there's no way to use these native tools because you gotta go one by one by one by one to restore things. That is just not feasible in a larger scenario. And, again, the tools are very, like, rudimentary. So if you wanna do something basic, like, hey. I just wanna compare what this look like, in my live environment to what it look like, let's say, seven days ago, ten days ago, over sixty days ago. You just cannot do that. Like, the tools are not available. So you're kind of flying blind, have minimal tooling, and, again, you're starting to kind of hack together these things that to, you know, make it seem like you have a resilient strategy, but really, really, that's not what it is. Yeah. And I think this recovery at scale problem is actually very relevant for the code side of the house as well because even if you want to depend on version history, the recovery will happen through complex manual CLI command that you have to run within GitHub. It will not be as as simple as clicking and recovering all your repos across board at scale. So, I I think the problem is definitely common across this entire workflow. So now if if we step back a little, it's really... All of it is really one problem, wearing three different hats. So right on the on the top, you, basically have the shared responsibility model that leaves the responsibility of your data to yourself. The second is the compromised identity attack pattern, which lets the attackers simply log in and wreak havoc to your data. And lastly, the native tools or burden history that sometime are, almost, assumed as in safety net, were never a real backup to begin with. And every one of these, these these gaps are basically getting bigger, because the the favorite word for all of us, in today's day and age, AI is now, completely revamping or, like, changing this entire workflow. So let me get... Set the scale first because, it is in fact staggering. So close to 97% of developers today have used, some sort of AI code, coding tools at their work today. Nearly half of the code in production today was written with some sort of AI assistance. Companies, like Google and Microsoft who've been, the the biggest tech tech tech shops, in the world have, said that their 20 to 35% of new code is now AI generated. And that volume shows up in, GitHub as well because they are increasingly seeing hundreds and millions of commits, in a week. That's tremendous productivity, but, fundamentally, it also changes the risk equation in two major ways. And what what are those, two ways? So, the the first is, something what we call the volume quality paradox. When developers essentially go ahead generate 5,000 lines of code in an afternoon, the human review essentially, breaks down. We do have stats where... Which shows that once, the the code crosses about a thousand lines, the human def... Detection, defect detection, detection drops to under 30%. So, essentially, what you are doing is you are shipping, more, more code, but you are reviewing it less. And, what happens with the AI, coding is that it will definitely give you the right syntax. It will trade those shallow problems of the syntax, but it will, probably introduce more deeper architectural, flaws which cannot be evaluated properly and therefore requires, an increasing need for frequent rollbacks, from a known correct state of the code. The second, bigger shift that's happening is just the sheer adoption of these AI assistant who can suggest code, but now they also have autonomous, agents that can act, on your code. They can essentially read, stage, commit, and push the entire thing. I'm sure we have... Even in, in Rubrik, we are adopting things like Cloud Code, Copilot agents. So allowing us to, to become more productive, at the same time giving them more, more access and more permissions on the code base itself. Got it. So so direct right access, there's no human necessarily staging the commit, and then that part essentially is what's changing the threat model. Right? Precisely. And that access itself opens up a broader attack surface. So, which essentially didn't even exist eighteen eighteen months ago. We are all... Already tracking, like, three attack vectors, which essentially, mean that we have moved from a five step human driven, kind of attach completely agent take no human in the loop attaching. And some of the examples that we have listed here, one is the stolen agent, token where, essentially, the teams hand, agents, like, broad, personal access tokens patch, when one leaks in a CI logger malware, and then attackers then uses that, agent's credential to strip branch protection and then delete repo at essentially machine speed. The second is, tool poisoning. Essentially, an agent call, calls what it thinks is a harmless formatting tool, but there's a hidden instruction that force pushes and destroys branch history in the background. And third is prompt injection. Again, an attacker opens, an innocent, looking pull request, with hidden instruction, but it, buried deep inside the the description. And then, essentially, agent reaches and just follows it, deleting the branches, corrupting the code. So as I was saying, attackers never had to be involved or, touch the environment. They were able to, like, execute such level of, through the code repo without even being, in the loop at all. Got it. Yep. That makes a lot of sense. And, again, to expand kind of the the aperture, once more, AI is, of course, expediting the speed at which the code is being written, which introduces a lot of potential, a new kind of threat vector. At It's basically the newest thread and the fastest growing one, but it's still the one thread in, in a much, much bigger picture. So putting it all together, you have cyberattacks, compromised credentials, outages, human error, and now AI. And all of that lands in the same place. That this data across your entire developer workflow is genuinely and increasing the address. And almost nobody today has a real plan to get it get it back, which is why the question that we have, we have started to post to the leaders and the customer that we talk to is one of the hardest one, which is if you were to lose this data tonight, your repos, your pipelines, boards, your runbooks, and your history, what exactly are you gonna restore all of this data from when the need arises? And nine times out of 10, the question is met with the silence because the honest answer is nothing we'd actually trust. And that's the gap we want to spend the rest of our time on, because it's completely solvable. And you essentially don't need a separate tool for every corner of this workflow, and you don't have to accept that this data can actually be unrecoverable. So what you need is a single strategy that treats this entire workflow, code, pipelines, planning, and knowledge as exactly what it is. Business critical data that has to be recoverable no matter what hits it. And that's exactly, what we have built with this Rubrik DevOps protection offer. Ishad, given your, product expertise, I would love if you could walk us through, how it actually works today. Absolutely. Happy to. So the the first and most important piece of this really, it it it comes down to three main pillars. And the first one is about cyber resilience, where we're taking your data out of the blast radius that could be impacted by all of these different attack vectors we've talked about today. Backups that are immutable and logically air gapped, so it has a separation from the domain of where your your main and primary data is is, is stored. And this is backups for your entire DevOps workflows that are hosted and managed entirely by Rubrik. So, again, even if an attacker compromises your GitHub or your Jira admin or if an agent goes rogue inside, your your tenant starts modifying things, deleting things, you always have a backup and backup and recovery solution available because they cannot touch, encrypt, or delete, Rubrik's backups because of this logically air gapped immutable, architecture that we have built our, solution on. That makes sense. And that air gap is the whole difference, which is... Also allows us to differentiate ourselves from any kind of version history because, this this is exactly why an attacker will essentially never be able to reach, the backup, making this a true backup to to, rely on. 100%. And sec... And and second pillar that I'll talk about here is around automated protection. And what we hear from a lot of our customers is they're trying to hack around this problem because there's no good solution in their native environment. So some of them will have home... Homegrown scripts in order to, back some of their data up. But scripts are brittle by nature. They're difficult to maintain. Really, so what we've built a solution that's automated so that we're constantly discovering new data that's coming into your system and will automatically protect it. So as more data comes online, you don't have to worry about, hey. Is it included in the script or not? You can just rest assured that the data will be covered by the policy that that you have set up, in Rubrik. And that takes me to the other point, which is this SLA driven policy engine that we've set up, which, again, we're talking about it today in the context of, DevOps workflow and SaaS applications. But, really, this is the same engine that's built across the entire Rubrik product portfolio. So whether you're protecting on prem workloads, you're protecting cloud workloads or other SaaS workloads, it's really one standardized, platform and one standardized mechanism for you to be able to, dictate, hey. How frequently do I wanna take backups? How how off... How long do I want to retain it for? So that also removes a lot of the operational burden that you have put on your teams where you don't want six different tools or seven different tools or 10 different tools with its own different unique way of setting up, SLAs. It really simplifies that process, quite significantly. So really helpful from a scale standpoint as well. That makes sense. And this automation actually comes with scale. We are able to manage close to 50,000 repos at scale from a core standpoint and 12,000 projects scale from a Jira a Jira standpoint. Essentially, it is true enterprise grade and enterprise scale, and it kills any need for having those script which requires the maintenance headache on top of once you have implemented those. Absolutely. And then, of course, we're we're backing up the data. It's immutable, so no one can edit it. But, of course, you wanna make sure the data can be recovered, and it adjusts to the use cases that you see most frequently. So, really, what we've built are very flexible recovery, platform and functionality, which you have one click restores. And then also you can dig into the level of granularity that you need for your recovery purposes. So whether it's a repo, it's a project, it's an org, it's a page, it's a space, it's a Jira issue, configurations or metadata associated to Jira, All of those things can be recovered at a granular level. So you precisely get you... Get what you need, and you don't need to, you know, override everything that's in your, in your environment, which is what, unfortunately, some of the native tools, have today. So that's something that I think is is super critical, differentiates us. And, of course, I I know there's... On the code side, we also recently launched the ability to do cross platform recovery so you can restore your code from one platform to another, which, again, is additional protection that you get. And a lot of these applications that we're protecting today, it's not just a single record, but, really, it's a record that has a bunch of downstream relationships. So it's important to keep in mind that when when we're building these recovery tools and and enabling you with this recovery, we're maintaining all of those relationships as well to make sure that when we restore it, it's being restored with the permissions that previously were there. It's being restored with the downstream relationship, so you don't end up with a bunch of broken links when you're restoring. So a lot of flexibility and granularity has been taught through and built in the recovery flow as well. Yeah. And what what ties all of these three pillars together is that same underlying architecture that Rubrik has provided across board... Across SaaS applications cloud. And that's the same auth onboarding, same auto discovery, the immutable air gap storage, and the SLA based protection. No matter it's GitHub, Azure, DevOps, Jira, or Confluence is available, for all these platform. And that's what makes this truly differentiated because it's just... It's it's... It isn't just that we protect this entire software development life cycle in one place. It's that this sits right alongside the rest of your estate, your cloud data, your SaaS application, your on prem, all in one platform. And it's built on that foundation we've been hardening for years delivered via the Rubrik Security Cloud, which brings in the enterprise controls, which many of our large organizations and large enterprises require, which is, granular, role based access control, quorum authorization, and then the audit reporting that can satisfy frameworks like like Dora. It's just one one unified platform delivering all of this goodness, for you. So making it that one platform, one place for you to, prove that you can recover this entire workflow when required. Yeah. And I'll I'll just restress that point again that all of this is not a pie in the sky. It's in production today. Jira, GitHub, Azure DevOps, all have been generally available for multiple quarters now. We have customers, successfully running, on them as we speak, and we'll cover some of those, stories, in moment here. And Confluence is also coming fast and lands in September. Yeah. And on the code side also, we are not, standing still. Beyond the original support for repos and pipelines, we are progressively bringing in the the support for the planning and collaboration artifacts in GitHub and Azure DevOps, including your work items, wikis, and the rest. And this will be, again, under the same backup policy, progressively rolled, over the months of August and September. So the the coverage of your whole workflow keeps getting deeper, quarter over quarter. So let me make those examples on the customer stories a bit real. One well known public example that's... That we have put out in in in the recent time is Siemens. So their engineering organizations, treated their source code as, in their own words, their most important asset. Before Rubrik, their backups were manual, developer and scripts. The kind of... The artisan approach that we've, we've talked about, today as well. After they moved to the policy driven automated protection that Rubrik could provide them and ability to run a controlled recovery test, their recovery time, had dropped from a day to, mere mere minutes. And that's the difference between having a script and having a protection strategy for this workflow. Yeah. And I think that's one of the pattern we're seeing with a lot of larger enterprises is it really becomes a unification, story like I kinda talked about earlier. One manufacturer that we work with, I'll I'll keep them anonymous, but they had a really mature air gap resilience model for their, on prem and cloud estate that usually gets more, focused when it comes to resilience. But, really, you know, once we talk to them, they realize the importance of protecting their DevOps environment, as well. So, you know, the same the same console that they've already been accustomed to, the same weight, the same policy engine like I talked about, same controls over... That they've had over the backup. So it's... The learning curve was not really there for them because they already knew how to work on that movement platform. So you don't need to stand up another own island in order to protect any one of these workloads. It really unifies it, under a single pane of glass. A 100%. And maybe one more proof point. The cheeky one I get that I would want to, mention is that we've been running these products ourselves as well. We've been dogfooding our products. Rubrik protects our own Jira with this product. We've been running, our core backups or GitHub backups internally as well. So we're not asking anything, asking, anyone in the audience to do anything that we haven't already done and tested, on ourselves first. Yeah. So so maybe maybe three quick, things to take away from, our our chat today. First is, you know, the developer workflow is really a tier zero system. Right? It's more than just code like we talked about. It's the plan, the knowledge, the operations, the code, and all the ways that it comes together since a lot of these applications is really the connective tissue for the functioning of your rest of your organization. So really important to think about the entire developer workflow together. Second is the threat landscape is evolving. Right? You you, of course, have things like accidental deletions, malicious actors, outages, and, honestly, malicious actors is something we've seen. It feels like it's uncommon, but it's actually... We've heard it quite a few number of times, even internal malicious actors. And they can really hit all levels of your, workflow that we've talked about. Now the new threat vector with, introduction of AI really accelerates all of that, both on the coding side as well as the planning side, which is why it's important to think about data protection holistically. And the last thing I'll say is you really... You don't need, four, five, six, seven tools in order to be able to, you know, get that holistic protection that would actually significantly increase your operational overhead and burden. But, really, one platform that can provide you that end to end coverage for the workflow along with the rest of your, your data estate. So, hopefully, we've been able to prove to you those those three things are, are important and something that should be top of mind for you. Yeah. So that's, a close. If anything we have walked through today sounds like your environment. And for most organization, at least parts... Portion of it will. The best next step here would be to get a clear picture of your, DevOps platform and and the the gaps that exist today in their protection. And, we'd love for you to, to do, book a DevOps workflow risk assessment. You can simply reach out to your, Rubrik account executive to help set this one up for you. In the meantime, if you wish to go deeper on your own, you can explore the interactive demos on the screen. You can either, send a QR codes or just follow along on the links to the resources on the side. Thank you, Irshad, for joining me for this amazing, conversation. And, thank you everybody in the audience for joining us today. If you have had any questions, we'll definitely, probably would have answered them already. If not, we'll definitely like to, to get back to you, over email, on the flip side. Thanks, everyone. Thanks, Anurag.