Video: How Will Organizations Thrive Under New FedRAMP 20x Requirements | Duration: 3520s | Summary: How Will Organizations Thrive Under New FedRAMP 20x Requirements | Chapters: Introductions and Instructions (0s), Expert Panel Introduction (0s), FedRAMP 20x Overview (163.44s), Vulnerability Management Evolution (460.40504000000004s), Context-Driven Vulnerability Management (742.1650500000001s), Economics of CVE Management (828.4599700000001s), Securing Large Organizations (946.6100000000001s), Proactive Security Culture (1111.5351s), Hidden FedRAMP Costs (1302.175s), Reciprocity and Standardization (1802.43s), Secure Platform Development (2103.0499999999997s), Customer Success Stories (2298.64s), FIPS and FedRAMP (2478.6602s), FIPS Compliance Challenges (2550.4199999999996s), Trust and Reciprocity (2804.14s), Comparing Security Frameworks (3378.785s), Closing Remarks (3501.49s)
Transcript for "How Will Organizations Thrive Under New FedRAMP 20x Requirements":
Hey, everyone. My name is Aditya. I'm a product marketing manager here at Chainguard. I've been here about, a year or so. And over the last six ish months, I've probably spent, more time on FedRAMP 20 x than I care to admit, and I've been kinda closely following along in all the great work that the PMO has been doing. I'm really excited about the conversation that, we're bringing you today. We brought together experts across cybersecurity, FedRAMP, compliance, with kind of a wide variety of views on 20 x, where the PMO is headed with this program, what's, you know, what's been exciting, and and what there's left to learn. So I'll invite onto the stage Chris Hughes, CEO and founder of Papia, Donnie Haseltine, VP of Security of Second Run Systems, and Quincy Castro, CISO at Chainguard. We'll we'll we'll give Donnie a second to, join us on stage. Awesome. There we go. Donnie, maybe maybe I'll start with you. Can you give a little bit about your background, you know, how you ended up at SecondFront, what you do there, and then some of your experience with, FedRAMP? Yeah. Sure. Donnie Haseltine, VP of security at second front, formerly, CISO at Xenon Partners. And then before that, I was a Marine Corps officer for for a long time, probably too long. With FedRAMP, you know, they're they're basically both as a kind of user when I worked in the DOD, services and products, but more directly over the past three years, kind of running second front security team responsible for the accreditation for the game warden platform, running us through FedRAMP high, DOD IL five, and also working with our customers to get their authorizations, either on the DOD side or now the FedRAMP side. Awesome. Chris, I'll turn it over to you to do the same. Chris Hughes here, CEO and cofounder of Acquia. I've been in the, you know, public sector IT cybersecurity space for about twenty years, was active duty air force, a government civilian a couple of times, different agencies, including GSA that runs the FedRAMP program. I was one of the, GAAP representatives there during authorization board technical SMEs. I've been in and around FedRAMP from the commercial side, from the government side, you know, taking it through commercial solutions through the FedRAMP process, being on the other side evaluating solutions, working the DOD on impact levels and SRG and all those fun things in between. So long history in and around FedRAMP. Awesome. Over to you, Quincy. Hey. Quincy Castro, CISO over here at Chainguard. Previously at a CISO at Redis where we supported a number of, FedRAMP and public sector customers and then a bunch of other stuff going back to my days at NSA where I was certainly a consumer of, if not a practitioner around FedRAMP. So great to be here. Great. Well, we're gonna kick this off for the folks who just joined. If you have questions, please please throw them in the q and a section on the chat. We'll try to keep this a free point conversation, answer questions as we go or towards the end. Why don't we start with just a little bit of level set on FedRAMP 20 x? I think not everyone in in this, webinar may know what's been going on. So maybe, Chris, maybe I'll start with you. Give sort of your impression of what FedRAMP twenty x is, where we're at, and some of your kinda, like, first takes, spicy or not. Yeah. For sure. So, like I said, I've been in and around FedRAMP and and worked with it quite a bit over my career and been around government quite a long time. So when I see these big initiatives come along, I kinda roll my eyes. Like, you know, it's, like, not gonna make an impact. It'll never kind of accomplish what we hope it will. But FedRAMP 20 x honestly has been incredibly surprising so far in terms of their progress and the acceleration of what they're doing around authorizations. And it what it is is they're looking to revamp and modernize the program. FedRAMP's been around for over a decade. Despite having tens of thousands of commercial SaaS offerings out there, they only have about 350. Now the number, obviously, is much higher in the in the last year or so, but just a few 100 authorizations for, you know, commercial SaaS and and Cloud Clocks that the federal government can use underneath the FedRAMP program. So it was kind of having an adverse effect in terms of getting commercial innovation and cloud services into the federal mission owners, you know, DOD mission owners, etcetera, in terms of being able to use authorized services. So they've got to do this new approach of, you know, kind of a phase pilot approach of different phases. And some of the key things that they will be talking about, I'm sure, throughout the program is accelerating, authorizations, moving towards some achievable artifacts, modernizing how they do vulnerability management, leaning to more things around inheritance, reciprocity, these terms that you'll hear us throughout the throughout the conversation throughout there. But just revamping the program to be more effective and get more commercial innovation into the government's hands, honestly. Awesome. Quincy, same sort of question to you, but maybe focused a little bit more on your first impressions, what you've been surprised by, and and kinda how you're feeling about the program overall. Yeah. So look. You know, when I think about this goal of, like, how do we make it faster for government customers to adopt new tech, how do we make it cheaper for, you know, particularly SaaS platforms that haven't been able to sell on the FedRAMP prior to to come in? I think all of that is really, really great. Right? And when I go out and talk to, you know, other CSOs that are out there, people that have been through the FedRAMP process, I mean, the the incumbent approach has been really challenging, particularly in the SMB space. And so as an ex myself, I think anything that's gonna get more innovation into government agencies faster is is gonna be good. So really looking forward to seeing what happens here. I'll also say I really appreciate the transparency around what's going on. You know? And anybody can go to the public GitHub page and see, like, what are the various elements here? What are the timelines they're invited to comment? And I think that, again, that's really, really great because for a lot of us, again, I think, you know, founders and executives that are coming out of the the government space, right, there's still that sense of mission and purpose, and we're all trying to deliver something at the end of the day that moves that mission forward. Perfect. Yeah. And I just dropped the, GitHub link for those in there. I think highlighting the transparency that the PMO has been kinda putting forth here has been it's been great. Ty, last question from you guys for you. On the second front side, how how are you guys perceiving the new changes coming out? For you? I think, I think at the start point, I I have some of the same skepticism and cynicism as Chris. Right? When you say 20 x x, that could mean a long time from now. But I wanna say, like, just like, Chris, Quincy, and a lot of the industry said, very impressed with the transparency, very impressed with the rollout. The real question though as we move from phase one to phase two off the least ask into the moderate and high ranges because that's where the real meat is. And I think that's where most of our customers are really focused on is how do I get to this higher authorization so I can do business with more people. And that is a very challenging, kind of path, for smaller companies. I think we're, you know, second front, especially with with Chainguard is is getting images into low low CDs and then trying to get in on a platform where you can actually inherit most of those controls and kind of fast track that piece, because it's really challenging. SMBs right now, especially in the cyber AI, space, are really doing some incredibly innovative things, but that technology is not accessible to the government. So finding ways we can actually move that forward are really critical. And I think overall, the the major goals of 20 x x, I think, all security professionals are gonna agree on. Right? Can we reduce compliance burden costs? Can we shorten authorization timelines? And more importantly, can we improve security outcomes? Right? Because one of the big challenge we see is when you're focused on kind of point in time monthly compliance pieces, that's not real time security. It's kind of more of a theater aspect of it. So how do you shift to automation and moving to a point where not just your team, but your government customers and authorized officials can actually see the real life state of security and clients in your product? That's a that's a great segue into getting into a little bit more specifics about the 20 x program. I mean, one of the big changes announced and actually standardized is the new approach for vulnerability detection and response, with a shift away from remediation to triage and new terms like Internet reachability, exploitability, and impact level. Chris, would love to get your, kinda, like, view on what these new terms mean, how this new standard is kind of, being interpreted by folks in the industry. Yeah. First off, I wanna give a shout out to, Pete Waterman, who seems to be in the crowd here, who leads the program at FedRAMP. So it's amazing to have him listening in, and, hopefully, he doesn't hear us say something. Go ahead. I don't know what the hell they're talking about. But, you know, in terms of the vulnerability, you know, DER aspect of this, it's like, I've I wrote a book on vulnerability management about a year and a half ago or so, and I feel like the industry has slowly been moving towards, you know, modernizing how we do vulnerability management. For a long time, it was CVSS base scores, you know, critical critical, high, low, moderate, etcetera, and it had no context of the environment, whether it's Internet explodes, Internet reachable. Is it likely to be exploited? Is it known to be exploited? Is the amethyst a cav? You know, these kind of things were is it a business critical asset? What what kind of data is on the asset, etcetera? Like, these things weren't really, factored into the equation, And you had teams just drowning in vulnerability backlogs. Like, the numbers, you know, fluctuate depending on what researcher, you know, you go cite, but it's hundreds of thousands, even millions of of of vulnerability findings in teams, backlogs. You know, that means a lot of POA and churn. You know, capturing all these items, trying to track. It becomes more of a a laborious effort to track the findings than it is to just fix the findings, due to how it used to be. And now we're moving towards more context rich, insights around the vulnerabilities. Is it Internet reachable? Is it likely to be exploited? Is it known to be exploited? You know, Is the code actually reachable at run time? You know, these kind of things are now becoming part of the conversation, and I'm really glad to see this being done in government. And and, truly, I think, like, FedRAMP, you know, in terms of the public sector, is gonna be a a North Star or a great example that we'll see the DOD and others kind of follow when it comes to modernizing vulnerability management. So it's exciting, both for the the idea of efficiency and speed and cost reduction and so on, but also just real focus on risk mitigation versus just, you know, kind of compliance, rigmarole. Yeah. Chris, you brought up a lot of good points about, you know, this idea of context and and enriching data that typically comes from scanners that historically have used CVS scores to determine how to pursue vulnerability management. Quincy, I'd love to turn it over to you and have you share a little bit of Chainguard philosophy on this? I mean, we've we've built a business around providing minimal zero CV container images, specifically to target this problem. Yeah. So I'll I'll acknowledge, like, I like the approach that's being taken here at a conceptual level, right, which is let's move away from these sort of broad stroke compliancy kind of standards and instead focus on defending against things that pose real risk to the environment. I and so I wanna, well, say, like, hey. You know, that that's a very valid way to approach this. I think the challenge is when you get into the actual practice of doing this, right, particularly for smaller entities that don't have an overwhelming number of bodies and tech that they can just throw at these problems. And I'll say, like, when I think back to my time doing private sector threat research, right, where we're tracking a bunch of, like, nation state groups and kinda watching them operate and stuff like that, you'd see them pick up, like, a new vulnerability that had been released and turn around, and, like, hours later, they're throwing that thing against their targets. And so on the one hand, we've got this environment where there's, you know, either just this brute force sort of approach to compliance or, on the other hand, this, like, you know, kinda analytic based way of, like, well, is this exploitable? And and if you've ever worked with, like, vulnerability management with engineers and you've got, you know, the CSO team over here, like, hey. You need to fix this stuff. And, you know, your, you know, your SRE team or whatever to be like, well, that code's not really reachable in production for these reasons. Like, things that can seem very black and white at a conceptual level can get really nuanced and complicated at a detailed level. And so, you know, as Chainguard, right, what's our approach to this? We say, this just shouldn't even be a problem you're dealing with to begin with. Right? And so rather than having all of this reachability analysis and these debates back and forth about, like, well, is that code actually loaded into memory and this you know, it's, like, just start with a minimal to zero CVEs to begin with. Use that as the foundation. And so then when you actually do have to have those debates, you're talking about, you know, it's this vulnerability. It's this handful of vulnerabilities. Is this thing really as serious as we think it is? It's not, hey. There's a thousand criticals in here, and we're gonna try to winnow that down to some number that we can actually handle. Sorry. I was trying to unmute there. Yeah. I just wanted to to double tap on that, Quincy. I think one of the key things that we've seen is exactly you said. Right? We'll come in and start up with a with a customer, and you'll have a thousand vulnerabilities. Right? And sorting out the false positives, from the low impact ones in in sorting out is is really, really challenging. And when you have that mass, your your eyes naturally move towards the things that are red and orange, right, the crits and highs. And every CISO has had that issue where they've sat down with an assessor and said, like, I get that this is critical. But, like, for for that to be exploited, someone needs to have physical possession of an engineer's laptop and broken through six or seven other strings of authentication to be able to implement that. Whereas over here, this shows low, but it's being actively exploited and wild. I can look at what's on the system known exploitability, vulnerabilities database. I can see how that can get in, and that may be an actual small gap in our defenses that we didn't see. So being able to allow that focus, like, context driven instead of just SLAs, high critical in these timelines, focus in on the context, focus in on what's actually exploitable. And so being able to be smart about how we do it. If it's just fix everything now, nobody can do that, especially SMBs, and giving them tools where they can actually see what's important and why and articulate that, not just to their customers, but to assess and authorize officials, is really critical. So more we can move to that and having something like FedRAMP kinda drive the industry towards that piece is really emphasizing stuff that Cisco has been screaming about for many, many years. Yeah. Yeah. I was just gonna I was go ahead, Quincy. Go ahead, Chris. I was gonna add on to what I was gonna add on to what you said, which is, you know, talking about the cost of CVE management. And like you said, simple and and, like, and conceptually, you say, you know, likely exploited, known to be exploited, reachable, etcetera. But at scale, that's still problematic and still, costly to the organization. There's obviously, like, the risk management side of it, but there's just the economics of it, the time of the security team, the time of the engineering team. And I don't even work at Chainguard, but I've long been a proponent of minimally hardened containers. You know, it's the same concept of things like the OWASP open source software top 10, like minimizing unnecessary dependencies, minimizes the attack surface. It also has a minimization on the the churn between the security team and engineering team. You guys had published, like, a cost of a CVE report. It's incredibly to go look at there and see, like, what does this impact have on our organization, not even just from a cybersecurity perspective, but an economic perspective of how much time we spend just kind of arguing over these findings and and the the status of them and so on. Yeah. No. I mean, I think back to my time in kinda big industrials, right, where we'd have these monthly ops reviews going through, like, open pen test findings and vulnerabilities. And you had, like, GMs of, like, you know, 100,000,000 businesses in there kind of going through this stuff. And, you know, all of that is great. And at the time, I remember thinking as a a CSO, like, oh, this look at this. You know, we've got this great focus on dealing with these issues, and we're really in here tackling this stuff. But you think of, like, what does it cost to run that meeting? Right? Like, what is what is the what is the hourly rate of all of these people we pulled into this, and what is that due to the business and the opportunity cost of what all these attendees could be doing? Then you think of the attacker's perspective, and it's like, oh, you fixed that thing. Let me load a different module, and I'll just throw a different exploit. Right? It cost them absolutely nothing to move on to the next thing. And I think taking that adversary mindset and thinking about effective vulnerability management in that context, where as a defender, this is a place that's very costly to manage. As an attacker, it's a thing that is essentially cost free for them to adapt to. Yeah. Quincy, I like what you talked about about bringing in kind of the larger companies. Right? Because I think there's a tendency to focus on the SMBs, which I think is very important, like we said about the technology innovation. But whereas a smaller company is gonna have, like, resource constraints and probably expertise gaps that they have to deal with and manage. So using tool sets like second burner Chainguard really helps narrow that and accelerate that. Larger companies are also pretty negatively impacted here. Right? Because with those larger companies, there's an immense amount of scale and complexity. So when you're managing across a narrow SaaS platform versus a massive, massive, massive, set of code, really, really challenging. And most larger companies also have more legacy systems, which are harder to patch and harder to track. And then when you talk about that, now you have to not just fix all those things, but that meeting you just talked about. Right? The organizational inertia you already have, how do you adapt and make those processes, which are probably pretty steady in a larger company and get them to be more agile and focused on what the actual risk is? Yeah. It's funny in cyber, we have these, you know, kinda cheesy catch phrases that we all know is, like, you know, secure by design or or, security is a business enabler. Right? Like, these things that we say, they're kinda trite. But when when we talk about, like, minimally hardened images starting with secure a foundation, like, minimizing unnecessary dependencies, like, that's a tangible example of secure by design. It's a tangible exam example of empowering the business to focus on their core competencies, which are not vulnerability management, by the way. It's like delivering value and outcomes for customers. Yeah. I love I think back to my time in government and that concept of, like, supported functions and supporting functions. And I talk about this a lot with my own CSO teams. Right? Like, we are a supporting function. We are here to help other people be successful. And when we forget that dynamic and and the service that we're supposed to be providing and we think, well, you know, I'm important. The vulnerability management's important. People ain't take this seriously. You know? Like, hey. Are we here to patch vulnerabilities, or are we here to deliver a great product that supports this mission and, like, helps people go out and do something useful in the world? Yeah. I think that's that's exactly the right thing to think about, Quincy, because, like, especially with SMBs, with smaller security teams. Right? They're laser focused on the product market fit, delivering that for government customers and getting that innovation out there. And, you know, when a lot of times the security team comes in and becomes this department of no, Not even because they want to. It's because they're getting told they have to do that. They have to check these boxes. Right? And the more you go to that, you start moving away into that checkbox mentality, that compliance theater and away from real time security. You know, I like to always say that, like, compliance does not cause pretty good security, but good security should be get good compliance. Right? So shifting that mindset and finding a way to be really tied to those product teams and where you're showing how security can be a benefactor to protect those customers, protect those teams, and give them the freedom to just execute that mission of delivering that product. Connie, I think you said something really interesting just at the end there, which is that compliance is not, the end goal. It's it's sort of like a byproduct, right, of building the right best practices. I mean, Quincy, having been a CISO for many years now, like, how do you try to set that culture? Because I think that's something that isn't natural, maybe, to a lot of companies who, more often than not, are reactively responding to compliance mandates? Yeah. I think first and foremost, it's starting with a really clear thesis of why you exist. Right? And, DTE, you've heard me say this at Chainguard. Right? What's our team's mission? It's to make life rough for bad guys and make it easy for everybody else. Right? And I think starting from that position of, like, we are here to frustrate adversaries. We are here to make their lives difficult, but we also acknowledge we want it to be as simple as possible for everyone else to do what they wanna do. Because at the end of the day, if what we've done is secured the system by making it borderline inoperable, that doesn't that might serve my personal interest in terms of keeping my job. It doesn't serve the interest of the organization in terms of, like, delivering a great product or a great service for folks. And I'll I'll say one other thing on this, which is there's a there's an interview with an initial access broker that was put out a couple of years ago. And in it, you know, they're they're asking him about just, like, what his life is like as a cyber criminal and this and that. He has this great quote where he's like, if you put everyone on you put all the criminals on defense and you put all of the defenders on cybercrime, cybercrime would stop that day. Right? Because and I'm paraphrasing here. Like, attackers think in terms of graphs. They think in terms of possibilities. You know, they're acting like someone playing a board game, and defenders think in terms of checklists and compliance and, like, oh, do I have the right crypto algorithm selected for this thing and not, like, what is possible in here? How could somebody come in here and disrupt this environment? And I think too frequently, as CSOs, as security practitioners, we get hung up on the certifications and the checklists and, you know, what's the what's the min spec I need to engineer this to to pass this qualification as opposed to how does somebody come in here and do damage to this environment? Yeah. Quincy, what I always like to say is, you know, security is like a rheostat where one side is convenience, one side is totally secure. You can make everything totally secure, and it's totally unusable. Right? That goes for your internal things and your actual external product too. So how are you constantly dialing that? And are you, as a security team, tied in with your teams, your engineers, your product teams, and your customers to know what the right piece to that is? But, yeah, I love that what you said about flipping flipping mentality from attack to defense. Yeah. And we often you know, like, attackers, you know, to his point, like, they're thinking graphs and not list like a defenders. And they also are, you know, creatures of efficiency. Like, we might look at the latest headline around AI and, you know, zero to the exploitation and all these kind of things. And it's like, if you have, you know, containers that are full of, known exploited vulnerabilities, thousands of findings in your environment, you're just grabbing things off the open Internet. Like, you're just facilitating their job, making their life easier for them. So starting with a secure foundation. And then again, going back to the FedRAMP piece, like, focusing on real risks that are known to be exploited, reachable, etcetera, all the things we talked about, like, you're making their life more difficult for them and kind of increasing the cost, on their end, basically. I think you guys have all brought up actually, like, this interesting idea, which is people pursue FedRAMP accreditation for a reason, right, which is to unlock customers, sell their product, align end users, and ultimately build revenue. And often when we talk about the cost of FedRAMP accreditation, we're talking about auditors. But we don't see the hidden cost of what is the work it takes internally to actually get to your your environment to the state that's ready for ATO. I would love maybe, Donnie, for you to start. Like, let's put second friend Chainguard to side. Like, what is the typical picture you see at customers who are trying to get an ATO and the hidden costs that they're taking on? Yeah. I think, yeah, I think that's a really important point. Right? Is is there's a tendency to focus on the audit cost but not realize how much more expensive it is to actually have your system adequately protected in the background. You know, I will say anyone who's been through an audit does learn a ton about them themselves. The system that was the same for second front. Right? We went through it. There were things that, like, we thought we were doing that we weren't probably doing that we're able to fix. And that piece, there's some benefits there. But, again, that's cost, resources, and money. Like, there's cases where, okay, to do to fix that, I need an FTE or a contractor or a new tool set, and then what's the right one to bring in? And then you have this weird thing where you're very quickly, like, there's the one that I think is gonna work and there's the one that's gonna pass the test I'm about to take. Right? So you have this case thing where, like Quincy said, you're focused on product delivery. Okay. What are you gonna pick? Well, usually, the business case is, like, what's the least expensive resource that's gonna meet the requirements that's gonna allow me to sell my product? That is not always the best the best one for security. Right? So that puts, security teams, which are usually cost centers in the business, in a very awkward piece when you're trying to walk that middle ground there and balance it out. I think that for for smaller, and simpler SaaS, it's easier to do. But for more complex organizations, it's very, very challenging to know what are all the things I need. I mean, sure you can nail them the basics. Okay. I've got MFA. Okay. I've got scanning. I've got things like that. But, you know, when you get into, like, super, super niche aspects and some of those 853 controls, Do you have the expertise to know what that controls are really asking for? Do you have the background and ties the industry to fair on what tool set or what person you need to kind of fix that? And then what's the best way to get that achieved in a way that's supposed to secure but meets the requirements so you can sell the product to the government? Yeah. I was gonna call a couple of things out in relation to the Fed rep conversation too and security is, like, one, if they they've introduced this concept of key security indicators, you know, focusing on this subset of controls and and not even controls, but, you know, kind of activities and practices and methodologies that drive security outcomes for some of the things that we know the cloud service providers are overwhelmingly doing for all the SaaS providers that are building on top of them. Right? You know, you know you're inheriting a a large portion of the controls, for example, tied to media protection or, physical access control, you know, those kind of things. And then, also, I talked about how FedRAMP had been around for over a decade and had just a few 100 authorizations not long ago. Many of those authorizations or or things that were not authorized included security products. So now, like, people building, you know, they're building things in the cloud trying to get to the federal market, and they're actually prohibited from using more innovative, you know, capable security solutions that simply couldn't go through the FedRAMP process because it was too costly, too cumbersome, too time consuming, and so on. So it actually put a a lot of people in a situation where they had to use a subpar security product or solution, because it simply wasn't FedRAMP off like, the the more innovative and capable solution wasn't FedRAMP authorized. So that's another aspect of this is getting more so security solutions, security products and vendors and so on through the process too. So they they can be used by not just the agencies, but people building in cloud and going through FedRAMP more broadly. Yeah. Quickly, over to you too on sort of the hidden costs and specifically how Chainguard has helped many, you know, almost 50 plus FedRAMP customers now eliminate many of those. Yeah. I mean, it it seems sort of self evident, but I think anytime you're getting away from spending time on delivering a great product and doing the things that will practically defend it and towards, you know, again, kind of the compliance paperwork y sort of piece of it, you know, that's probably not a great use of time. And I I talk about this, you know, as a seesaw where I say, I wanna spend the most amount of time possible building and assuring our defenses, and I wanna spend the least amount of time possible describing them to people, right, and explaining what we're doing. And I think so frequently, we see that that dynamic upside down. And so, again, I come back to, like, you know, historically looking back at all of these kinda old school ways of doing vulnerability management at various places I've been CSOs. And then I look at what we're delivering in terms of, you know, images, you know, getting into libraries and things like that and all of that. You know, the sort of trusted software component piece of this is, look. This is a bunch of work that somebody used to have to do or some team used to have to do, and now it's, you know, a minimal fraction of what was there before, and all of that time and headache and resourcing can go into other more productive things that are in there, you know, making that environment more resilient, giving yourself more tripwires in the environment to look for what bad guys are up to, making lateral movement difficult, right, by taking away vulnerabilities that you might have, you know, said, well, you know, that's not really gonna be my threshold. We're gonna get to that later. Hey. That's still an opportunity for somebody to move laterally in the environment, and now you're denying them that access. So I think, overall, to me, this is just the better, faster, cheaper kind of way of doing things that frees you up to be more productive, more efficient, more innovative than you could have been before. Yeah. I I just wanna add, like, I don't work at either SecondFront or Chainguard, but I know of both of your organizations for the very, concepts that you both are talking about. Right? A company comes to do business with the government. Their core competency is not, you know, minimally hard and secure based images or, you know, a a secure platform that meets all the, you know, FedRAMP and this, SRG, DOE or SRG requirements and so on, Let allowing them to inherit controls, inherit these, provided, you know, mag services and so on, you know, inheriting these secure based container images that lets them focus on their core competency, which is trying to provide value to the government, the stakeholders, the citizens, the war fighters, you name it, whomever is gonna be using the service, which, you know, many of these companies are not experts in FedRAMP and DISA and DODSRG and all these kind of things. So let them, you know, use these innovative services and get faster speed to market, more cost efficient, more effective, and it just reduces, you know, distraction for them, basically, and let them focus on what they're doing best. Awesome. I I think, you know, one of the things that we all highlighted at the beginning of this webinar is, you know, the impressive pace that twenty x has been moving at, especially maybe from what we've come to expect from some of these government programs. And I just wanna level set with the with sort of the audience that, you know, FedRAMP twenty x is actually kicking off their phase two pilot, at the beginning of next year, which is incredibly quick. And that phase two pilot will be focused on sort of the first set of closed data moderate authorizations. But I would love to just chat for a moment about, like, hey. What are the things that are still left to be worked out? What are the sticky issues? And we can go sort of one by one, but maybe let's just start with, you know, moderate authorizations versus high operations where a large percentage of sort of market value is still left to be captured. Chris, we'll maybe open with you. I was hoping you'd call someone else while I thought about the hardest things remain to be fixed, but I'll go ahead and go first. No. It's a great call out. It's like, you know, obviously, at least high unaddressed. Right? But, you know, I'd love the iterative approach that, Pete and the team are taking there. First, it's, you know, kind of like in the in the vein of actual software development. They're going, you know, kind of phase by phase, seeing what works, what doesn't work, where if we make improvements. They're having open dialogue with the community, having reciprocal conversations. Everything is out there that at the as they talked about earlier. You can go to GitHub. You can go to repos. You can go to the FedRAMP website. It's all publicly available. They're changing policy and process procedure at the speed that I've never really seen in government. You know, it's it's typically very heavy handed and cumbersome. But there is the fact that, like, high is, you know, kind of yet to be addressed. Right? But I think jumping to high would have never let them make the efficiency gains and improvements they did with some of the kind of low hanging fruit of life as or low and then now moderate, which moderate, if I'm not mistaken, is still the overwhelming majority of, south SaaS and, FedRAMP authorizations. So it does tackle the biggest kind of piece of the market in that regard or or the marketplace from a FedRAMP perspective. But I think it's gonna be interesting to see what what can they build on from, phase one, phase two, and then go into the high authorizations and things like that. And, yeah, I'd be curious to hear what other folks think on the call here too. Yeah. I'll jump in there, Chris. I think you're spot on right. I mean, I think that that's the right approach, right, from an MVP iterative standpoint. Second of all, everything we're talking about is based off in this 08/1953. Right? So if you come in, there's low, and then you have to do additional controls, get to medium, get to high. Yeah. The CNS is I 12 v three, trial four, five, and six. So getting the baseline stuff first and kind of building on multiple foundations is is absolutely right. But I think that there's a, you know, a big jump from mod to high. Right? And even though there's a small set of controls jumping from high to aisle five or aisle four, Aisle six. Right? Those are not in in insignificant controls. Right? And I think that's one of the bigger pieces which is probably outside of the bounds of what FedRAMP 20 x x can do is working on the reciprocity. And second problem, we deal with a lot of more cases. We have customers that have DOD, customers and also other agency mission owners out there that that are using FedRAMP. So outside of that initial, like, FedRAMP mod to I l two define reciprocity because the controls overlap. When you're stepping into those other pieces, it gets really, really challenging. And then you get into very awkward pieces because if you bring in, like, Nara and Kui. Right? And FedRAMP can absolutely hold Kui, but it can't hold DOD IO five Kui. But what's the line on what control? It gets really, really challenging to explain that to customers and determine, like, what do you need to do to meet that requirement. And the promise really of veteran 20 x x, which I'm a 100% behind for, is like the do once, use many times. I mean, that's the same thing we try to do at second front. You come in, you use our platform, we can get you to multiple authorizations through that one kinda initial, tranche of work. But the DOD really stymies that when they take very different perspectives on that. So finding a way to look at the CSI twelve fifty three controls and look at those other pieces and find out how they how they go through and how that we can work that reciprocity and increase that across the entire federal government, I think we unlock a lot of market value and, just looking at Pete's, Pete's comment. And I think he's right. He's right on that. Like, I mean, what like we said, moderate is the key piece. I think with with with second problem, we probably deal with that 15% he's talking about where we're in that weird high high l five category. Yeah. And I've heard this anecdotally from other CISOs who have taken their companies through this that, you know, okay. It was good to get to moderate, but we really only felt like we gotta return our investment once we got to FedRAMP high and we're able to get IL five. And I think the challenge of that and, you know, both of you highlighted this, so I don't wanna repeat it too much. But, you know, in a marketplace that becomes more fragmented, it becomes a lot harder, particularly in the, you know, kinda start up y SMB space to be able to do, like, agency by agency approvals. And, you know, hey. This crypto is approved over here, but these people won't accept it. And so now we're doing something else. And I think that starts to incentivize exactly the opposite of why we have this entire FedRAMP structure to begin with. You know? And to the extent that now companies are being, you know, kind of forced to customize one off solutions for agencies or departments, Like, that takes us back to, you know, if you work for the federal government, which you which you kinda hated about commercial software there in the first place, which was it was some bizarrely tailored thing just for your agency or your team, and, you know, now it's not compatible with something else or it works slightly differently. And so I think anything we can do to help streamline things, do all of the stuff that FedRAMP 20 x is supposed to do in terms of bringing more entrance into the platform and getting more new tech in front of, agency buyers while at the same time trying to, as broadly as possible, standardize that that marketplace and those requirements such that it becomes a really attractive place for innovative players to come sell. I I think that's that's both, you know, good for industry, and it's certainly good for the public as well and the taxpayer. Yeah. It's a great call out by Quincy because I've been on the other side of it as a government, you know, employee at at different points in my career. And, like, you see something come out, like, oh, it's it's not moderate yet, or, oh, it's not high yet, or, oh, it doesn't, you know, IO whatever, right, you know, quite yet. And you got these innovative, you know, solutions. And a lot of times, I was looking at security services and things that I wanted to use, and I simply couldn't because it hadn't met the compliance requirements quite yet. So I think anything we can do, as he said, to accelerate that, you know, get these capabilities into government's hands and kind of minimize, the bifurcation between commercial innovation innovative solutions and what the government can use, the better. Right? You know, because it's just gonna improve everyone's experience overall. Awesome. One thing I I wanted to highlight, and we talked about a little bit earlier, but it's like this idea of, you know, supporting functions versus supported functions. And I think often people think of tools like SecondFront or Chainguard as, like, security or compliance tools. But really the primary users of these technologies are engineers, platform engineers, DevOps folks, application developers. Like, maybe, Donnie, we'll start with you first. Like, have you guys oriented the product you've built to be as easy to use as possible so that the compliance piece is is a byproduct of just, like, let's make deploying your application easy. Yeah. I mean, I think that's the key thing is, like, what we try to do is kinda set the platform towards those target environments we talked about. So even at, like, the higher levels like FedRAMP higher or l five, when you bring those containers in and you start setting your artifacts and pulling it in and kinda building out your software, on our platform, it's gonna kinda drive you towards a specific opinionation that's gonna make you more secure and meet those cases. What was just talked about by Chris and Quincy is really critical. Right? What you don't wanna have as a software, developer is multiple versions. Right? Okay. I've got this version for commercial, this version for government, but at IL five, these ingress and egress doors are closed, so I need to find another way to rearchitect my product to meet those control pieces. We try to drive it in a way that makes it easy. It's probably initial frustrating at at first. Right? Because you have to do do some refactoring and change in there, But you're saying in a way that, you know, hey. If you get through this pipeline, you can deploy that on any regulated market with with Purdease. And I think that's the key thing that even FedRAMP is getting to. If you get through these controls and you get in the marketplace, you should be able to penetrate multiple, markets. You're able to now take that back and kinda sell that on the other side. The other piece you hit on, Aditya, was was was exactly right. It's like, take the engineers who don't have the security background and wanna focus on building product and give them the tools or giving their security teams the tools to have insight on what they need to focus on and prioritize and triaging what's really critical from the government perspective. So you're not kind of going playing whack a mole in the background. That's, like, why we love working with Chainguard is putting in Chainguard images by some of these other images that are out there because it lowers the number of things that, engineers and security teams need to look at. It helps us kinda coach them through and be able to get them in a position where they can more rapidly penetrate, multiple markets either for federal government or other, regulated spaces. Quincy, same sort of question to you about Chainguard philosophy to building technology that's fundamentally easy for developers to use. Yeah. I mean, it's funny because it's it's so sort of, what, unsexy in a way to just be kind of behind the scenes working and doing what you're supposed to be doing. But I think that's what any great product does, right, is liberate people to be creative, to do their best work, to go off and do things that are important and are differentiated. And, that's a that's a space I'm more than happy to to sit in, and, I think it's a it's a it feels good to sort of be under the hood of all of these really innovative products. Yeah. I think, we've talked a lot about compliance and security, but when you look at what, you know, both these teams are enabling here, it's like, you know, a modern, you know, best practices in a lot of context around change management, configuration management, especially in the second front sense. As he said, it's an opinionated platform that kinda moves people in the right direction, where they're just kinda meeting security controls as a byproduct of using the platform and doing things the way the the platform is conducted is to and set up. And it often you know, it abstracts away. As you said, they're not you know, may maybe the users are not security people, and it's because it's, you know, both for ChainGuard and second front, it's kind of abstracting away. Like, these folks don't wanna understand NIST 800, you know, a c dash seven. Like, they just wanna you they just wanna do what they're doing, develop their products, get them out to to, excited end users, and abstracts a lot of that away from them, which makes them both excited and thankful, I'm sure. Awesome. Well, the the sort of, like, last sort of topic that I want to focus on is, a little bit of, like, customer stories. I mean, Donnie, I'd love to give you the floor first. Like, feel free to talk about, you know, a recent customer interaction you've had where, second premise may wanna make a real difference in their FedRAMP ATO and accreditation process. I'm sure the audience would really appreciate it. Yeah. Let me I'll just call out what Kyle just put in the chat there at TrackVIA. I mean, it's been a a huge process getting them, as they came in board and were able to use both the the second front platform and Chainguard in in concert really to drive the point home where they can get prepared. And right now, they're working through their final kind of FedRAMP pieces with their auditors and kinda getting, getting up to to get in the marketplace hopefully soon. When you think about trying to do that from scratch, finding your order, building all your documentation, making sure your, software's compliant, it's incredibly difficult. And I think the other piece, for some of the customers we've had is we had customers that have had a a pretty compelling, foothold, say, in the federal market, but then wanna move in the DOD or vice versa. Right? And crossing that that divide can be very, very challenging. So being able to take customers, and get them into those DOD aisle five and in some cases even classified aisle six spaces and being able to have them maintain, parity between their commercial product, their FedRAMP product, and their classified product, it is a huge, huge piece. Because if not, you're just adding more and more and more engineers. And I'd say we've had, we've actually had some customers come in too where they did it themselves and then still came over and utilized us and utilized Chainguard because it just saved them an immense amount of time, and FTEs they would need to build and maintain this piece to make sure they're retaining the compliance, the security, and remaining competitive to, compete in the federal market. Same question to you, Quincy. Yeah. You know, I think what's, what's been fun for me is getting on some of these calls with prospective customers. And I think as as he says and, like, security practitioners, you know, we're so conditioned around things like posture management and scanning and risk management. And, you know, you got on a call and maybe, like, one person is familiar with the product. They brought a team along with them. And so, you know, the team's like like okay. Right. So, like, how does this work exactly? And, like, you know, where where how do we see the results? And we're like, woah. No. No. No. This isn't, like, scanning for vulnerabilities. Like, literally, we give you a thing that doesn't have vulnerabilities in it, and then you just go build on it and and go to town. Right? And, you know, I've been surprised at the number of times I've had that conversation where folks realize, oh, you're solving the problem for us so we don't have to figure that out. And it's like this light bulb moment, and that sounds so silly. And yet I think as you know, in the security space, like, we should be demanding more. Like, we should be demanding solutions to problems, not better ways to widow down the problem to, like, its worst, you know, sort of extraction. Awesome. Before we kinda turn it over to q and a, which folks should jump into the chat to leave questions that we can answer at the end here. I actually realized we didn't talk about really the f word, FIPS, which is four letter words, and its relation to some of, you know, FedRAMP's biggest kind of requirements. Having spent a lot of time over the last few months, I haven't seen anything about FIPS, as it relates to 20 x, but I wanted to open the floor to you guys. Like, FIPS often tends to be one of the biggest reasons that customers go looking for tools like Chainguard or SecondFront, and it's one of the bigger obstacles. So maybe, Chris, I'll I'll start with you and and your perspective on cryptography, challenges people face, and kind of solutions they pursue. Yeah. It's long been a sticking point in the context of FedRAMP and getting into the market. And, you know, it'd be one of the leading complaints among folks trying to grapple with these compliance frameworks. And I I don't know if I've actually seen and and I and, you know, maybe Pete will be upset, but I don't know if I've seen it be directly addressed, in the FedRAMP 20 x x guidance and things that I looked at quite yet, but I may have missed it. So I'd actually be curious to hear from Quincy and Danny, like, as you all are interacting with customers and thinking about FedRev 20 x and kind of the paradigm shift, like, what are you guys seeing? Like, where where do you think it's gonna change? Yeah. I can jump in there. I think I I haven't seen much, requests or requirements for the FedRAMP or customers, but I haven't seen from DISA, right, where, DISA PAE is usually a boiler plate language now that require a transition to to rev five by early next year and FIPS one forty dot three, by fall of next year. And I think, while rev five should be self evident for anyone going for FedRAMP, that's what you should be focused on right now. The the, the FIPS one forty is, tech three is a little more challenging. Right? Because very few people are running their own custom encryption or their own pieces there. They're inheriting using those tool sets, from major cloud providers and other pieces like that. And if they're not moving through that process, and most of them are, but just it it's not easy to run through that CVMP process with NSA and get the official check marks and say we've met the new things. That becomes really challenging where you have providers being held to a new standard by the government, but the folks that they're using to provide that encryption is also going through a parallel process with the government and not quite, getting there. There's not much you can do about those requirements. I think the other call out I would make to to folks who are going on this journey, though, is make sure you understand where you need that FIPS cryptography. Make sure it's turned on right. Because I think there's sometimes a mentality of, like, oh, I just clicked FIPS enabled to my OS. That doesn't mean you're on the right encryption, and it's not just, like, the basic check the box, I'm done. Are you using FEMPEST validate, cryptography in your service mesh? Are you using your VPN components? Are you using the other parts of your network? It is all over a modern SaaS, or PaaS platform, and system. So you gotta be able to know, like, where am I actually using encryption? Have I gone out and made that list? Which federal requires, make the list, pull up the CDMP data, and and verify it. But do you know where that encryption is? Do you know where it's coming from? Do you know that it's met the standard? Do you know what that standard provider's, status is in the process of transitioning from one tech one forty tech two to one forty tech three. And I'm gonna say sort of selfishly here that I love being in the position to just solve this problem for folks. And so if you look at the FIPS validated images we have and, you know, our entropy sources and all of this, like, being able to just ship this to people and say, you know what? This is super complicated. Not a ton of people understand it well. You don't have to understand it well. Pick this up and use it, and it is it is yours to to mess up. Right? And then just to add on that, like, you know, since we luckily have Pete in the audience here, he did drop a note that, you know, since it you know, he said crypto apply crypto policies apply universally, but Lo doesn't contain sensitive data. So it wasn't essentially, wasn't part of kind of phase one pilot. So I think we'll see it be addressed here in the near future, as we move forward. I was just gonna say one of the perks of having the PMO, fact check you in real time is that everyone gets to learn, at the same pace. Thank you, Pete. Great. Well, we we have about ten, fifteen minutes here. I'm gonna open it up to the audience for q and a. And while folks are putting questions in the chat, I'll just start with kind of the first one. So a question from Alfred, is, you know, are there operational characteristics or lack thereof that will alert you on concerns prior to partnering with organizations? And maybe if I'm, interpreting Albert's question Alfred's question a little bit is, like, what are the key red flags that you might come across in someone's environment, their security posture that would give you pause, in sort of adopting their solution? That's definitely a broad one, but I'll just jump in quickly. And and, you know, Donnie and and Quincy, I'm sure, think about this quite a bit given that they're out there, you know, interacting with customers and hearing what the customers are looking for and and maybe, you know, getting concerned about. But for me, it would be like, you know, those that haven't lived it and done it. Like, you know, these teams that we're talking to both, you know, teams on the call today have a long track record of now doing this at, yeah, at scale across, you know, organizations of all different shapes and sizes. And they're also, you know, kinda dogfooding their own solutions, using it internally among their own teams, things of that nature. So those are things that I think about. And, obviously, there's a a many different, you know, kind of gaps or gap gaps around, you know, security controls and rigor and things like that you can, you know, focus on. But I'd be curious, Quincy and Danny, what comes up a lot with customers. Yeah. I'll I'll just say, I think what you said about dog food is spot on. If it's, if you're not using your own products, that's a sign to to be concerned of. Right? I think the other pieces to look at is just, where do you see those product being used? Like, as example, like, you I think you also mentioned earlier, Chris, is, you know, if I'm using other tool sets, are the do those have FedRAMP or other, accreditations, and can I use those? So where else where can you get a proof source to determine that? So a lot of times, it's very difficult to nail down the specific operational characteristics from just a slick seat or a demo. It's getting in there, and I'd say on the Cisco side, what I find is usually before a Cisco brings in any product, to the platform or partners of the organization, they go talk to other Cisco's through kind of, like, private Slack groups and meetings to get their direct experience. So I think it's really critical to have approved source in the security, organization or industry who knows that product and kind of articulate kind of some of those key things back to you. Yeah. I I find this is this is tough. Right? Because I as a side note, just have, like, a major issue with the way we do third party risk today and, you know, this idea that, well, maybe if we just have longer questionnaires and we ask more questions and, you know, we dig into stuff like this, we'll be able to sort of assess, like, how mature and risky is this organization or not. And the fact of the matter is, like, if we, as, you know, security practitioners, we're great at doing that. We can all just, like, go start an insurance company and sell cyber insurance because we would know who was gonna get compromised and who wasn't. The fact of the matter is, like, you're just not gonna figure that out. But I do think there are some indicators around maturity in terms of how organizations go through these kinds of processes, whether it's sort of the commercial TPRM assessment process, whether it's something more more rigorous like what we're talking about here. And I think when you encounter organizations where, you know, you're you're asking for evidence, you're asking for audit materials, or you're, you know, trying to understand things, and everything is, like, ready to go. And it's like, here's a zip file. This has all our policies in it. This has our pen test results. This has, you know, commentary on the findings in the pen test results. Blah blah blah blah blah blah blah. And you think, oh, one, this is an organization that clearly has done this before, which means that somebody else out there has also, you know, sort of invested in, in evaluating them. Two, there's nothing to hide here. And I think even if there are issues, right, and we we all have issues, like, we all have places we could do better. So finding something that looks too good to be true, like, frequently is. But to the extent people are willing to acknowledge that, put that in front of you and say, yeah. You know? Hey. There were the a couple of these mediums on this pentest, but, you know, here's what we did about them. You think, okay. Like, this is a credible program that operates in a way I would recognize as a security practitioner is being done properly. And so I think you know, I hate to say vibes is the answer here, but there's a little bit of, like, interpretive vibiness going on with how you assess kinda trustworthiness and maturity. Yeah. It's definitely more art than science. But, you know, to your point, I think you raised some great things there. It's like having information readily available. It shows that other folks have likely trusted them, been through this exercise with them. The very things we're talking about on the call here, having FedRAMP authorizations, having, you know, DODSRG, as authorizations as kind of a signal of trust, having a robust trust center. And then the the concepts that we've talked about throughout the call is, like, we talked about questionnaires. We all hate questionnaires. But, you know, things like machine readable artifacts, real on time or real time continuous monitoring and insights and telemetry of the environment. Like, those things are gonna be the future of how we can signal trust, I think, to customers. I'm glad you call it the machine readable artifacts because, honestly, I think that, you know, we I think again, I go back to my my govvy time. Right? It was always like, oh, you wouldn't have to deal with this in private industry. Oh, private industries, blah blah blah blah. And then I look at stuff like machine readable artifacts, you know, and, like, control assurance, you know, kinda continuous control assurance and stuff like that. And I think, yeah, that's where private industry should be. Right? I would love to see this kind of stuff from the vendors that I deal with. And I think if you walk into a 100 companies and are like, I need machine readable artifacts that show your controls are operating effectively. Like, I'd be amazed if even one of those organizations had that, like, available for you. And so it's cool, you know, again, kind of being, like, a proud ex Govee, like, to see the US federal government out leading on some of these things and pushing stuff that I think will be more broadly valuable to private industry in the future. Awesome. Another another question from the chat. I think, maybe we should have hit this more explicitly, but Jacob asked the question between, you know, what's the difference between FedRAMP moderate and the FedRAMP 20 x moderate authorization? But the context being the Department of War's, memo, which essentially doesn't recognize 20 x yet. So maybe, Chris or Donnie, whichever one of you wanna define just, like, this idea of reciprocity, what it actually means, and and the context for FedRAMP 20 x today. Actually, I would love to hear Donnie on this because, like, I know you spent so much time in in DoW. Let me make sure I get it right. But DoW, when it comes to, you know, things like this in terms of reciprocity, the FedRAMP, moderate equivalent conversation has put such a hot topic lately. So I'm I'm really curious what you say on this. I think one of the things to understand, as if if I'm understanding this correctly. Right? One of the FedRAMP equivalency gets brought out a lot. Right? In reality, like, virtually no one does that. And And and the reason for that is is federal equivalency is focused on really your ability to meet CMMC in this eight hundred one seven one requirements. Right? It's saying, hey. If you have FedRAMP moderate product and you wanna hold COE in there, then you meet these other requirements, so we'll give you that equivalency. The challenge is is that's for companies that do not have, like, a sponsor. And where that becomes nuance and challenging is the reason why we're able to do these things, these authorizations, is because you're taking a very detailed review of your product and getting it in front of a government. And I think that's really critical. So you might have, hey, this is a miss or this is a low finding. I can pull in that. I can work on that. If your agency looks at that and says, okay. Understand. Kinda like we talked about about triage and contacts, someone in the government can look at that and say, okay. I understand that's still a finding. It's still a hit on one of your controls. However, understand you've got a plan to get it or you've got mitigating controls, ruling accept and move on and accept that risk. What that equivalency memorandum says is, okay. You're a better moderate. We'll just take that, and move forward with it. The challenge though is that you can't have anything POAM. You still have to pass, pass a three p o audit. So you have to pay the large fee for the audit. You still have to go through and meet all those controls, but you have to have a 100% compliance for all those controls, which virtually no companies really have. There's always something that's POAM or something that's caught or something you you complied with on the last audit, but on your renewal audit, you missed because you dropped the ball somewhere. So being able to go through and have it go through all that process, pay the audit, and getting it to be perfect is a really, really, really high bar. And the reason the government does that is, like, because no one from the government is looking your platform and formally accepting risk for the government. But that piece is really not useful except in that CMMC kind of phase, and I think that's probably changing quite a bit with the the new CMMC rules as well. So you should be very careful because DOD memorandums are not very clearly worded. You get that out and say, oh, I think I can meet this. It doesn't always mean what you think it means there. I think the other piece that was talking about was federal moderate and 20 x moderate authorizations. And I don't think there's a difference if you have a federal moderate historical legacy authorization or you have a 20 x x, moderate authorization the way phase two is intended because you're meeting the same controls. It's just, streamlined authorization, more machine readable documents, real time security compliance by just that point in time con mon piece. So I I think Pete or someone else can chat in there and jump if I'm misinterpreting that. No. I think you're spot on. I also love that you called out the, the the concept of no POAMs. Like, Quincy talked about this. Like, if you're having a conversation with a vendor and they say, hey. We have no findings from any pen test, any vulnerability scan, any it's like, I'm calling BS right away. We all know that well, like, as we said throughout the conversation, we're in the the business of risk management, not risk elimination. Like, it's nearly impossible in any environment of any scale to kind of eliminate all possible risks. The key is being transparent and communicating with the, you know, the customer, the partner, whomever. Hey. Here are the risks. Here's the compensating and mitigating controls we've taken. You know, here's when we plan to fix x y z. That's a much more realistic scenario. Awesome. I think, we'll we'll set up for one more question. And, it's related to this idea of, you know, CMMC, for those who are not familiar, like another government standard certification versus 20 x. And Tarex asked if kind of, you know, it will be acceptable for FCMC translate to 20 x or SOC two will be the preferred prerequisite. I'm not sure, we'll have the answer to the question exactly, but maybe it's worth addressing the overlap between CMMC, 20 x, FedRAMP, and and some of these other frameworks. I can jump. Oh, good. Go ahead, Rajan. Okay. I just wanna say there was another question in there. One other question in the audience was, like, do you think we'll see reciprocity? I heard I have FedRAMP may twenty twenty x may recognize other security frameworks and not force them to kinda comply with this a 53. Is that true? I can't speak for FedRAMP and Pete and the team, but I will say I as I saw that question come in, I went and looked. I wrote an article on literally in June 2021. The executive order back then talked about the concept of reciprocity with FedRAMP and, you know, the the alphabet soup of HIPAA, HITRUST, SOC two, ISO, you name it. Like, I'm curious if we'll see that come into play. And then just real quick to the question there about, you know, CMMC being a prereq or, you know, preferred, certification for for entering the FedRAMP 20 x. I don't know if the two are aligned. One's aimed at defense industrial base. One's aimed at, you know, cloud service providers, cloud service offerings, etcetera. SOC two tends to be more of a common commercial, earlier pathway, right, you know, for organizations as they mature from SOC two to FedRAMP into the federal and regulated industries like government. Anyways, just a little bit of a rant for me. Go ahead, Donnie. Sorry. Yeah. No. No. Perfect. And and totally agree. Yeah. I think there there has been some discussions and some of the GitHub things I remember about, hey. Like, if you're ISO twenty seven zero one compliant, will that equivalent to a certain FedRAMP level? I don't think a decision has been made on that. I think there is increased interest in how do we align these frameworks in a way where they talk to each other and you're not doing this kinda crazy lineup of, like, do I comply with x or y? But one point I really wanna kinda foot stomp on the CMMC thing, because this is a commonly misunderstood piece, is you gotta think of, like, the FedRAMP, and the 853 process on how do you secure your product to handle sense of government information for government mission owners. Right? That's a government that's using your product, so they wanna make sure that the information that's transmitted, stored, processed in your product is safe. CMMC looks at it very differently. CMMC is really focused on the eight hundred one seven one controls. Eight hundred one seven one is drawn from 853, which is the broader piece that FedRAMP, LOWMOD, and I use. However, it's more focused on your internal controls. Right? So if I think about second front, we have a FedRAMP authorization and a DISA IL five PA on the Game Warden product. However, we are CMMC level two for our internal corporate controls. And that's really like, how do I handle CUI within my organization? Like, the government needs to email me something that's sensitive. How do I handle it from a business standpoint? That's different than how you're handling sensitive information in your product. So you're probably not gonna see a direct transfer on those two things because you're looking at two different things. CMC is how do you handle it internally and FedRAMP and 800 p three is how do you handle it externally in that product for government, mission owners. Awesome. Thanks, Donnie. I think, we're at time here. Really appreciate everyone, on the panel, everyone in the audience making time to join, listen to the panel that we had on today. And, yeah, hope you guys all have a great rest of the week. Thank you so much. Thanks, everyone.