 So while folks are getting logged on, I'm looking for two scribes to take notes. Today we have a presentation. So the notes for today will be particularly useful for making sure that everyone in security has the context of what's going on. And as someone who is cloud person that works at Vintec, birds. All right, still don't have any new scribes. Hey, Dan Mark here. I'll try to do it today. Thank you, Mark. Appreciate it. All right, I need one more individual to help Mark out. And then I think we can get started. Have you run through this presentation? Do you have a sense of how much of the hour we have together I should be allocating? I plan on prioritizing. I've not run through them in a continuous manner. But it's fairly short. It's just 11 slides. So I don't know, 20 minutes with discussion should be fine, if that's OK. I can do it. You obviously never discuss with this crew. We will have a discussion. Awesome. So 10 minutes of presentation. I'm going to pad your estimate on discussion especially the interest. There are a number of us on the members here that are actually in FinServe and really interested in that. So we're also going to be very interested in that context sharing for non-SIG related interests. Perfect. All right, do we have someone supporting Mark as a scribe? I need one more scribe today. And then Michael Ducey is driving, so it cannot be Michael. I can scribe. Thank you, just appreciate it. Let's go ahead and get started. Because I do think that, like I was just saying, I think we're going to get into some interesting discussions. And then we have some ongoing efforts that I'd like to get check-ins to. But since we've been a bit sort of keeping the trains running and working on our work focused in the last three months, and we're beginning just to restart some of our presentations, I want to make sure we get that in at the time it deserves. All right. So we had our second follow-up with our TOC liaisons. Scheduled for today, unfortunately, Joe Beta is out this week. And we will be reconvening there in one week. So next week we'll have a little bit more news in the ongoing coordination and alignment with our TOC liaisons. Their top priority right now is normalizing the ingest process and how those things are flowing through the TOC. We're looking for alignment and further insight on the security assessment and security assessment prioritization process. But we've had expectations managed to us that that process is likely to be influenced by the outcomes of the rest of the effort. So that's something that I'm tracking closely. Hello, this is Emily Fox, National Security Agency. We talked yesterday about the SIG Security Day. I've updated the tickets with the notes from that meeting, as well as linked in the Trello board. So if anybody's interested in understanding where we're at and what things are going on, you could check out issue, I believe it's 209. Right now I'm waiting to hear back from Amy and Emily Ruff concerning website content for that event. That's about it. Excellent. Christian? RXM, we are just trying to make sure that we're in the loop when it comes to the developments with the SIG Security's work. We actually did read your, well, the white paper that you guys published was distributed internally. So we're going through reading and reviewing that. So I'm sitting in. Awesome. Christian, is that specifically the policy, the white paper that's in progress? Yes, yes. Awesome. Thank you. Thank you. Abhinav? Hi, guys, this is Abhinav. This is my first meeting. So yeah, I'm a VPN head of information security at Frames, Iowa, a New York City startup. We are just moving to Kubernetes. But we have been using Falco for quite some time. And I met Michael Dushy last week when he was in New York. He told me about this meeting. So that's why I joined. Excellent. Welcome. Thank you. Hey, Mark here. Nothing new to report. I wanted to mention briefly that the NIST Big Data Working Group, which is wrapping up their work, it's still in review, like it's on three of reviews at NIST before the official final report comes out. The leader there is interested in working on a framework that the University of Indiana, and I'll put this in notes for the other note taker. Don't try to catch this, to build a reusable set of APIs, which they're calling the Big Data Cloud Mesh kind of thing, which is what's interesting in the sponsor in having a set of use cases around analytics that would exploit this set of APIs. I'd like to hook them up with other people with that interest. So if anybody on this group is interested, I'll put them in touch with the professor at the University of Indiana who's working on this. There's a GitHub project around NIST with some of the artifacts in there that you can poke around and look at. But it's pretty much TBD to see where it's going to go from here. That's it for me. Thank you, Mark. Is the University of Indiana and Indiana University the same thing? Yes, they are, sir. OK. There are some previous Linux Foundation efforts that have been tied to that. And let me see if I can pull that up because that might connect some of the resources that are working on this, to that, and so driving that forward. You're right. IU is the normal way of referring to it. OK. Got it. Michael, which is permute. You're still muted, Michael, if you're talking about this. Did we lose Michael Ducey? I'll come back around. Yeah, I don't see him on the list anymore either. So come back around to Michael Ducey. If he shows up, call it out in chat. Justin. Yeah, so I've been mainly reading the Kubernetes Security Review, which is long and interesting, and trying to work out which bits of it are actually being implemented and so on. There's some of the... I was actually expecting the recommendations to be kind of... I mean, I was kind of expecting the recommendations to be to have CVEs and to be actioned, but actually they have internal code numbers and some of them have been actioned and some of them haven't, and it's kind of... But some of them are quite long-term things to fix and some of them are quite short-term things. So it's quite a mix. And I haven't finished reading all the supporting docs yet, either, so yeah, there's a lot of stuff there. Is it worth sharing out in, you know, carving out 10, 20 minutes in a meeting to share that context? We kind of had a small overview from the authors last week, I think, which was helpful, but I think that was just... That was just before it had been released, so there's a lot of it digest. So it may definitely make sense to... Yeah, and this would be much more our synthesis of security, more synthesis of this rather than what others think. So I'd like to... Yeah, I think it definitely makes sense. I think there's a lot of quite interesting things in it, and there's some discussion that some of us have been having about community threat models and things that I think, because there's a whole threat model document now and things that I think will be interesting to pass. Definitely give people a bit of time to read it all, because there's a lot of it. Right, I'll make a note that we're going to slot in that agenda item at some point in the future, and we'll just check back in when the right time, especially if we can get a couple different perspectives that have gone through and digested it all, that would be really nice. Craig? Hi, Craig Ingram from the Security Audit Working Group. So yeah, I definitely appreciate the feedback, Justin, and I've been enjoying watching the community response to a lot of the reports as it's come out and a lot of action being taken on issues that have been opened already, too, and things being closed out pretty quickly. So it's been cool to see folks kind of rally around that and fix some bugs. As far as the CVEs and stuff, yeah, totally get that, and that definitely makes sense. That was kind of left up to the PSC as far as making that decision. So the Product Security Council Committee, whatever their current acronym is. So they had, obviously, a preview beforehand of the report and the finding just to make sure, hey, do we need to embargo anything? And we ended up being, no, we can work on these out in the open. So if there are missing CVEs or things that seem CVE worthy, then I think that's totally up for making a request to Mitre and getting that designated for sure. Well, the one I particularly mentioned today was that there was a, I think, fix just got merged today, was for high-scuzzy passwords in logs, which is the sort of thing you'd expect a CVE for because it's a straightforward, you know, credential leak that people may need to be aware of to take action on. Some of them, yeah, less, but that one was a very, seemed a very clear-cut case for CVE. Yeah, and I think there's another similar one about, you know, things showing up in logs that shouldn't, that would probably fall in the same category. Sorry for the notes, this is related to the trail project, right? Yep, yeah, got it. Excellent, let's... Yeah, hi, my name's Lutz Pinker. I work for Figo as it's still called, name will change, and everything else I do, you'll see in a couple of minutes. Wei? Hello, everyone. So I'm from Alibaba, so I want to introduce myself first. We use Kubernetes a lot in our company, and we care a lot about the security. So this is the first meeting I'm joining, so I'm trying to follow your steps, and I'll appreciate if you can give me some guide, how to start my journey on the Kubernetes security. Yeah, thank you. Great. You know, at a high level, I recommend, you know, kind of watching the work stream, you know, maybe for a couple meetings, and then we have a few major work streams around security assessments, policy, and some other initiatives that we are always looking for support on. So, you know, listen for the, you know, call outs for needs and participation, and, you know, I would, you know, reach out and, you know, volunteer once you feel comfortable that there's an opportunity to align with your interests. I look, I think I have read some files that I looked through the GitHub issues. There is a label named Help Wanted, but I think the list is almost empty. So, yeah, I would like to help, but... Nice, nice. Well, we'll do some trios there. We, you know, after we got ratified and went through, you know, CubeCon Europe, we've doubled our regular attendance and, you know, have gotten a lot more help. So, great. The fact that our Help Wanted queue is getting burnt down is good news. Okay, okay. Great, well, nice to have you on board. Yeah, nice to meet you all. Julia? Hello. Hi, everyone. This is my first meeting as well. I'm working on implementation of security for Network Service Mesh, and I'm just curious what happens here, so I just want to listen. Welcome. Thank you. Is there anyone else who I've missed? I'd like to check in. If you're new and or don't want to check in, that's perfectly fine. I do invite you to sign in to our minutes, which I've just dropped into the chat. Hello, Dan. Hello, Dan. Hi, Yang. Yeah, yeah, yeah, I'm new to this group, and I'm working for Entrepreneurial. And, yeah, yeah, Entrepreneurial, we just want to improve the security of our infrastructure, and that's including committees issue and other cognitive components. So I'm just joining this group and just want to know what is the next step of the cognitive security, and want to keep each other up to date. Great. Welcome. Did Michael Ducey reconnect? Robert, great to see you. I'm going to transition from check-ins to kicking off our presentation with Lutz for the sake of time. So welcome. Anyone who's just joining, please do sign in. That way we can record your attendance. So today we have a presentation on fintech Kubernetes, and Lutz, you're welcome to take over. Are you familiar with the presenting via Zoom? I guess we'll find out. First, the document for the slides is in the chat, and now I will try to find the right window to share. Please give me a couple of seconds. Yeah, you should see just a single slide. Yeah, okay. Hi. I would like to, sorry. I would like to give you a quick insight into who we are, what we do with Kubernetes, and then some ideas of how we see the world as far as security is concerned, what we implement. And the major part on the last couple of slides will be something that we run into, some hurdles, some obstacles, and basically a wish list that in a perfect world, Kubernetes and the cloud-native landscape would provide for us in order to get more security, whatever that specifically means. We are a German fintech. We've been, we are actually in the process of moving the last customers to our Kubernetes-based platform, and we provide an API for banking as a service. That automatically means we are heavily regulated industry. So there's another things we can't do. We cannot use public cloud providers. It's possibly now, but it's very difficult because it's always a question of who gets to audit whom. Auditors in general are our biggest pain because they ask the same questions over and over again, slightly differently each time, and we have to find out what they actually are asking, not what the text of the question actually means. We are, we have customers that are banks themselves as well as other fintechs and mid-sized companies that simply use our license as a service. Because we are licensed, we can have them do financial transactions across our platform. We also serve some APIs to mainly mobile tools and thus interact with account holders and users directly. We're in Hamburg and Berlin and we're currently merging and that's what I said the name will probably change. So don't be surprised if I give you a different name of whom I work for in the next couple of weeks. As far as Kubernetes is concerned, we are pretty small compared to others. We just have 50 mid-sized nodes. The most specific thing is we do everything on bare metal running CoreOS and we've built a automatic deployment mechanism that takes all the applications directly from a Git repository and from configuration from a Git repository and the actual applications via Helm. Currently we do soft multi-tenancy because we deploy the same application in multiple namespaces to isolate but we are gearing up for hard multi-tenancy where partners and customers would actually get access to some form of Kubernetes API. How much and how filtered and how this is done is still a subject of research and discussion but the requirement is visible on the horizon and we are gearing up for that. As far as security goals and design principles is concerned, we do zero trust even though we think that nobody should be in our cluster, we still don't assume that. And we have a fairly straightforward sense of requirements because the thing that we most have to protect is the user credentials of the online customers. Then the other things are the usual stuff, it should work. What we're trying to achieve and this is mainly one of the things that I'll get into in my obstacles list is to never have a human actually working within our production cluster. There shouldn't be an admin. Everything should be via Git controls, via GitOps and that has been surprisingly hard to do mainly because we don't write everything ourselves where it would be simple to do so but we use a lot of third-party components and I'll get into that in a bit more detail. And we also try to do defensive in depth and so far we have been, I think we have been successful in that because there were CVEs that everybody got really up in arms about where we thought that it would not be as problematic for us. Okay, the next is just the usual stuff we do MTLS of course, because we aim for zero trust. We basically have everything encrypted addressed and what our secret sauce to a certain extent at this is that we don't create secrets by hand. They're all automatically by this deployment mechanism created from a hashacop vault and put into Kubernetes secrets and we are in the process of getting ready to do better workload at the station so that we can eliminate a lot of these secrets which are only there for one component identifying or authenticating to another. As I said, we do bare metal and then we do everything that Kubernetes provides to a certain extent more or less you see the usual acronyms there. In addition to that, we deploy an IDS from NeuVector which basically gives us an insight and a fairly nice UI to see whom is trying to talking to whom and we can intercept that if we want to but at the moment we use it more as a detection than as a policy enforcement tool. Okay, now the other part of our secret sauce is DeployD it's a solution written in-house that takes a configuration and deploys it based on a trigger. That is set or that is called by our CI pipeline and it only will take fixed white listed list of branches. If one of those is triggered by the event then it pulls the help charts and renders them out to the cluster. We do not use tiller and it will also automatically populate all the secrets from the HashiCorp vault. As I said, the goal here is to have no human intervention in the cluster. This is very helpful in having a development environment that looks very much like the production environment where the devs can have all the secrets they want. They can set them themselves, they can put them in the development vault fairly easy to work with but they will automatically be replaced with actual production values by DeployD. And therefore there is nothing that can be accidentally put into the source repo. There is nothing that a dev can leak. And we hope at one point to reach a point where even an admin that we still have to have for certain corner cases is not able to leak anything because they can't know. But now the next from here on in this is basically a laundry list of things that don't really work, that are hard to do. And I'm very aware of the fact that I'm probably barking up the wrong tree and I'm maybe even preaching to the choir here. And this is in no way to detract from the good work and very helpful work that has been done on security in Kubernetes. But some of these things are really hard to do for a small organization. We have to be very aware about developer productivity. For instance, using Spiffy makes it hard to work offline. It may not be impossible, but it makes it harder. And also we are working with banks and most of the banks are very conservative. And the most conservative of the representatives of these banks are their auditors because they see the world in a certain way. And if you come with new ideas, then they often understand things, as you can see from these quotes, that they're actual quotes that happened in discussions with auditors. See the world in a certain way. And if what you're doing does not fit this world, the answer is no. And it's hard to work around that. The biggest obstacle to more security for us is actually managing the supply chain, the software supply chain security, because we have an incredible complexity of direct and more indirect dependencies as we are not Google or other large organizations that can write or at least review everything, every single line of code that we put into our system. We don't, for that reason, we don't use signed images. I would love to do that. But what's the point? It would be just signing something that I cannot control completely because of the complexity of dependencies or the sheer number of dependencies. And this is even a problem with the IDS wheel, had a number of cases where an image, a base image was reported as containing a code that has a CVE. And after a lot of manual investigation, we found out that, yes, or not chorus, CentOS version XYZ has a CVE that's active against that, but only in a component or in a package that is not installed by default and definitely not in the stripped down version that was the base image for some tool that we're using. So any tooling that or any concerted effort or standard procedure that would allow us to easier identify who wrote what and what's the quality and the input to all these components, all these dependencies would go a long way toward improving supply chain security. The next thing is, as I said, we are trying to eliminate the admin, but sometimes that's fairly hard because components assume that there is an admin. They will even ask for money for their fantastic UI, which is nice to look at and it often gives good insights into what's going on, but also they require you to configure the system once it's running down to even closing ports or setting security controls. Now the network side isn't that bad if you run it in Kubernetes as it would be by running it straight into the internet or available to the internet, but there are a number of things, for instance, that in Elasticsearch are very hard to do in an upfront manner or in a declarative configuration way. Some components have that as a stated design goal. Ambassador is one example and not the only one, but one that's dear to me because we're using that quite a lot and I think it would be very helpful to identify CNCF landscape product or projects that have this design goal or this feature that they are completely configurable in a declarative manner. Even turning off or dumbing down the UI would be very helpful and I think this group could work to state such design goals that are conductive to security. Hopefully some projects will adopt them. The next thing is how do components authenticate to each other? It is for me and it is hard to define or show what the benefits of something like Spiffy compared to Kubernetes onboard secrets are, especially in an environment where I have to find a good reason for the effort that it would take to implement workload attestation. I seem to have been somewhat successful because we have that on the agenda now. The next really big pain point with all the MTLS is the certificate management. Every single component has its own or every single project has its own way of doing CERC management. It is not easy to find out what certificates are currently deployed and actually running in or being used and Kubernetes itself isn't any better. The root certificate rotation is painful. There is no easy way to find out what the exact certificate is and for instance, which certificates within the whole cluster should be rotated next or should be replaced next because there is no auto rotation. All that gets even harder if certificate management is one of the regulated areas because we have to do it in a certain way and not doing that is not an option. The next thing I should have, whatever. Overall, the security management is difficult to maintain in an ongoing manner. I have not yet found a tool or a process to generate the documents that the auditors would require. So having some standardized way of generating standardized documents would go a long way even if semi-manually but ideally automatically because we are a small company. This takes up a lot of manpower for jobs that are basically not fun, so it probably would help. There's been some efforts with the secured CNCF financial users group and we are an active in that as well. Not me personally, but a colleague of mine. So we hope to see some movement there. Okay, from now on there's my personal, wouldn't it be nice wish list? Some of this may not even be possible to solve, but as a user presentation, I thought I'd give you some of my pain points. The declarative configuration we covered. Actually, we covered that in totals, I'm sorry for that. But MTLS is not the standard or does not seem to be the standard and the normal way to do things with a number of components. Yes, they can be turned on, but it's some obscure, often badly documented configuration and the projects don't have a feeling for the complex certificate and key management issues and details that quickly arise if you use MTLS everywhere. The next is to have more security by default. That might increase the learning curve to start with Kubernetes, but the simple things as the non-secured API interface, that's the default, why? I know some of these points have been covered in the white paper and the security analysis. I can only agree fully heartedly. And more steps towards the fantasy land is please, let's have unmovable key support everywhere where I can keep my keys in an HSM or maybe even a hashicob vault that would be a start and general understanding that keys cannot be copied where you need them, but they have to be requested or their use has to be requested from somewhere else. Some components start with that, but it's really hard. And my last wish, and this is definitely something in the fantasy land with unicorns and everything would be a measurement of how many layers of defense are left. Somehow, even if I have to, if this is just a form of documentation or modeling or anything like that, together with a threat model, that tells me, well, if this barrier has been compromised by CVEX, then you have still, and more layers that protect your vital data, which are the customer credentials in our case. So at least we have the advantage of being able to identify what we want to protect. And if there is any research on doing such a defensive depth meter, I'd be very interested in that. And with that, I'm done. Thank you very much. Let's thank you. That was great. I'm sure I have tons of questions. I'm sure others do too. So let's see. You left such delicious candy there at the end. I wanna try to avoid rabbit-holing on the fantasy land. And let me scroll back to the previous slide where you tee up the interesting challenge of basically doing the organizational handshake between a vendor and a large organization. Do you have any potential strategies around exploring that? As a former vendor who now works at PayPal, large financial services company that tends to be a bit more progressive and works closely with vendors, I've seen that particular challenge from both sides of the aisle. And honestly, it's painful on both sides. And if there was a mechanism or a coalition to move that forward on the end user, the customer side of things, there would definitely be interest in aligning with that. Okay. It's interesting for me to understand that the paint, no, it's actually not that surprising, but I have to continuously make myself remember that, that it's a pain point on both sides. And I think, and this has been the, I think common theme with financial services user group as well is to have a common framework if only of documents or audit questions, procedures, things like that, that everybody can agree to. If you say, we do it like that or we do it like that, but differently in point A, B, C, it would go a long step forward to reducing the manual work of understanding and generating documents that will only be weighed but never read. So that would probably be helpful. The question then is who accepts that as a base? For instance, in Germany, we have had a federal agency generating documents like these for a long time. Of course, there are requirement or required to use for federal agencies, but other than that, it's a lot of that is yes, the normal things, lock the door kind of stuff, but it's a lot of paper and it's, I'm not sure if another framework like these will help, but we need something. So it's, I don't have the magic bullet there either, no. But having this agreed upon framework probably would help a lot. Even just by weight of community. Great. Hi, this is Abhinav. So one question, did you face any challenges when you deploy pod security policies or network security policies? So for example, network security policies, you need to know how your services are communicating, right? I mean, if you deploy blanket policies, they can understand the services or if you deploy overly broad policies that don't serve the purpose that they intend to serve. So how did, did you guys face any challenges around that? And if yes, how did you solve that? For understanding who talks to whom, the NeuVector IDS was very helpful because you can run it in a learning mode where it'll just list who talks to whom and we have this development environment that reflects the actual production environment to a sufficient degree. Other than that, especially network policies and pod security policies, it's just grunt work. We are moving to a point where we say, you can't communicate, if you want to change that, come to me and state exactly what you have. And if other than that, you can't, it's forbidden. Everything's forbidden and it's a discussion. It's an ongoing discussion and I think there's no real, there's no secure way around having this ongoing discussion. It's easier than old school firewall rules because there is not this, or there's not this context switch from components talking to each other to network numbers and port numbers, but rather I can describe it in a declarative manner of the lang, or of the names of the components that are talking to each other. So maybe we just got lucky with the way we designed our namespaces. So it's just grunt work. Go ahead, thanks. So it's Mark under here. So I also work in financial services. So we got several of us here that are mired in that space. I'm wondering if the Germany federal regulators accept any of your automated artifacts at all? I'm not sure is the honest, complete answer. But in the end, it's often generating documentation that makes them assume that you are doing it thoroughly, more than anything else, that you basically have a plan and follow that. There's also the BSI specifications that generally follow this idea that yes, there are certain simple controls, as I said, like lock the door and have a metal cage around your computers, but other than that, it's having a plan. And having a plan and automatically documenting that you're following it actually does help a lot. Last year, they wanted us to do some screenshots of some tool that controls some network component in order to document that we were following or we were doing something along the lines of the plan. For us, that's a lot or too much manual work to take screenshots. But if they accept screenshots, then the assumption is they'll accept automated reports any day. So just a placeholder for a future discussion, the OCC, who's the main regulator in the US, convened a meeting with our DevOps standard in IEEE in which they tried to talk about reverse engineering DevOps from the regulator's point of view, IEE deconstruct the artifacts that were coming out of DevOps so that they could consume them in a DevOps methodology as a regulator. Seems to me that's kind of where we need to get with the whole reg tech space in order to make this happen because it's not just the problem with the tool of Kubernetes or the things that are coming out of the open source community, it's broader than that and they need to be part of the solution in some specific ways. I couldn't agree more. Do you have any docs or standards that you can point me to? I've seen the... Sure, it was an abandoned conversation. We had five or six meetings with them. They seemed very interested and then they concluded it with no artifacts. So I don't know if that means they have a plan they're gonna announce to us or if somebody inside the OCC killed the project, I just don't know. But that would be under the DevOps IEEE umbrella, right? Right, it's the 2675 working group. I see. Up in the chat. Yep, cool. Any other topics that we have just a few more minutes? Any other topics that folks would like to jump into? Well, I just put on the agenda to just highlight the recent CVE cluster for Envoy which coincidentally was on our list of things we wanted to maybe reassess. And I think the underlying point I wanted to make was this notion that security audit is point-in-time artifact and that this notion that you can just say something has a security audit, that's not suitable. Clearly. The Envoy security issues are the same ones as the gay ones and therefore apply to everything building gay as well. They're the general HTTP2 vulnerabilities. So they apply to all HTTP implementations. So it also applies to Kubernetes and anything else that's using, potentially using HTTP2, you say? Well, got it. And Nginx has the same vulnerability as well. Most people who are talking HTTP are vulnerable. Nobody does that. Wow. That's quite the impact. Justin, is that something you expect to see? And Robert, excuse me. Is that something you expect to see more things pop up? Like this is just the beginning and, you know. I don't know, I think it looks to me like no one had looked really hard at the kind of resource allocation issues with HTTP2. We went through the whole thing with HTTP decades ago with Slowloris and there was a bunch of them around then about the same kind of attacks. And the HTTP2 spec wasn't very specific about how to deal with resource allocation issues. And so Netflix spent a bit of time on it recently. And hopefully they found most of the issues. I mean, I think they're relatively understandable. They were quite a few of them. But they, and they did a coordinated disclosure with all the major implementations that, so. Hopefully this is most of them, but yeah. People that, I mean, resource allocation issues are kind of rife through everything. It's just easy to make things leak resources in general because it's not a threat model people think about much. Right. And HTTP2 is a fundamental re-envisioning of, you know, resource, you know, the HTTP. Well, it's got more types of resource because it's got multiple channels. So you can leak channels or you can send things down multiple channels in small amounts and all the other kinds of types of thing because it's not just a single channel anymore. It's managed a few other pieces around header compression and things like that that are also resource allocation issues. And the groups using HTTP2 tend to be very T-shaped where like the one thing that you actually, you know, find that you're really needing HTTP2, you go really deep into it. And, you know, HTTP2 as a spec is much broader and in the capabilities it's introducing to the protocol. So, you know, one use case may differ in what it's tapping into. Well, also I think a lot of people have just opted into it without really realizing because software is just updating and supporting it and it just works. Yeah, yep, yep, and just works. Interesting, great. Well, Robert, thanks for highlighting that. Do you think that we need to carve out more time to dive in more deeply or does that sort of awareness balloon there cover the topic specifically? I just want to give you some feedback on the lifecycle PR that I've put up there and noting that it's still a work in progress but I thought I'd throw up what I had just to keep the momentum going and in line with these CDs. But I think, again, my meta point is that I think the security assessment shouldn't be thought of as a single point in time. It's a commitment. People are serious about getting a security assessment. It should be a commitment to ongoing resource and allocation of time and review. And I mean, that might be onerous, especially for a critical component like an envoy but I think those are table six. Right, yep. So trade off we have in the collective reliance on open source components, absolutely. So I did drop Robert's agenda item into the chat and it is specifically issue 152, right? Robert that you're looking for. Yeah, that's it. And that should be linked to the pull request as well. And PR is 1.5, great. All right, thanks for the heads up. That brings us to the end of today's meeting. If you have anything specifically that you'd like to tee up for the next August for the first meeting, please add them to the top of our meeting notes. Thanks everyone, have a good week. Thanks Dan. Thanks. Thank you. Have a good day.