 Hey everyone, we're still early, so let's wait a little bit. Hey Brandon, is somebody copying over the template? I think this is the template for today, right? Zero to 17, did I miss something? Either, wait, Emily, did I miss something? No, I got my dates mixed up. I was thinking it was next week already. Oh, thank God it isn't. What are you guys talking about? No, we had some calendar troubles as usual. I like four different calendars because it's hard to see. Yeah, Emily is having calendar troubles, that's the problem. Like, wait, we need a good tool for seeing for nice calendars. What's a SIG without problems with calendars? Like, I don't know, it's like every single one of it, I could never sync it up. I mean, it's a calendar. I feel like I should say. If a calendar causes the problem with calendars. All right, I will give it a couple more minutes. Do you guys know if Andrew's a little bit droning or if he had like, bad accident? I don't know, I know that he has been active in Slack. Peace, he's here. That's good. All right, I'm gonna paste a meeting note in the end just because she doesn't show. Yeah, I feel polite. I'm sure I've been attending this meeting for a while. I know the year was crazy. Lots of stuff. I hope I'm gonna be able to share my screen later. I updated my Mac and there's like a ton of permission things that come up, so we'll see. Okay, I think let's get started. So kind of as usual, this meeting is recorded and as part of the CNCF, just keep to CNCF guidelines and be nice and friendly. So today we have two topics. We are looking for scribes. So if anyone can help scribe for today's meeting, that would be good. So we'll be going through kind of updates on just going around today and then we have two main issues that we will talk about. If you have not already done so, I'm gonna paste in the meeting link again for those that just joined. Please go in, put in your name and the attendance and if you have any updates just put a message or if you're new to the group, put a message and then we will get around to introductions. Cool. Thanks to Tay for signing up to scribe. All right, so let's get started. Let's see, no updates. Well, Marky, you didn't have an update but you had a short question about blockchain. What's that? Sure, I'll keep this short. So we, because of some recent uptick and interest in cryptocurrency stuff, I just wondered if we had any open PRs or threads on blockchain here, either from like, there's a distributed identity foundation is working on the identity side. They have, I think a storage section that worries about that stuff but I don't know that it's come up here, has it? Not that I've seen and the issues at least. So I'll think about a way to maybe introduce it for a cloud native audience that might be relevant and I'll put into the chat a, and I'll sell in the notes here so don't worry about copying it over for the scribe. A list of the IEEE standards body groups that are working on a blockchain is pretty amazing. They've got a lot of stuff going on. A lot of it doesn't end up being a standard but just the diversity of interest there is kind of interesting. So that's it, I'll put the rest in the chat. There's also a lot of blockchain related stuff happening in the Common Financial Computing Consortium. The focus there being it's more energy efficient to perform blockchain like calculations inside a trusted execution on environment rather than on general purpose compute. So stuff happening over there, I don't know if there's interest in bringing folks in but I'm happy to connect if there is. Well, we should be interested for moral reasons, right? Yeah, that's an interesting thought. I feel like that's kind of content that we usually think about anything that runs within some kind of security hardware to be sour. So that's the trade off that. So that should be an interesting discussion. Maybe we can make it one of the topics next time. Okay, that's going down. So Emily has an update that's already on the agenda. Andreas, did you have a- You skipped me. Oh, sorry. That's all right, yeah. I just wanted to do a quick update from the TOC meeting on Tuesday which I attended where they talked about renaming the SIGs. So they are proposing calling our group a technical advisory group or a TAG. So there is an open issue on GitHub where the TOC is voting on a new name for our group. So I thought everybody might be interested. So I'll put the GitHub issue in the notes but it's also on the CNCF slash TOC. And then also more substantively, the Liz Rice is the chair of the TOC brought up the idea of actually having as part of the graduation criteria that projects would have a process for security things like that for people to submit security issues and have that documented process. And that's one of the things that we look through in the assessments. It's also part of the CII badge but this would be calling it out and I propose that this happen at Incubation which was roundly seconded so that projects at Incubation would all they have to do is say this is what you do when you find a security issue. So people felt that was a low bar. I did say that it might be people were worried that there might be projects that are already in Incubation that might not know how to do this. So I wanted to see if there's anybody who might volunteer to help audit the projects that are incubated and graduated to see if there are ones that like to provide data to the TOC to say, oh, 90% of them have it, whatever. I'd suspect that most projects have it but I don't know for sure. So Sarah, is this kind of like seeing that they have a process to handle these things? Yeah, I mean, for most projects like it's in the read me do this if you have a security issue but in the assessments we've found some projects that don't have that well documented. Yeah, I remember we had like a section in the assessments that's like what are the security response? Or at least we were discussing this initially when we're talking about assessments that wasn't really a benchmark to compare that against. Is that already an issue open for this? No, I can open an issue and then anybody who wants to help with it could chime in. So would that be like, because any of the incubated projects that I've seen kind of have like a security audit kind of line, right? Would that be just here's the process that was engaged by, you know, during the graduation process and then there's a link to stats or something like that? No, it's totally different topic. So this is somebody who's a user of the project finds a security issue or believes they have. What do they do? So there's a reporting security vulnerabilities as well, right? So you can, you know, if there is anything then that's part of the, but it's basically somebody has to is it an external person validating that? I'm just trying to understand. No, no, it's just that there is a process for reporting and then communicating the ones that are security vulnerabilities. So there are a lot of projects that aren't security focused, right? And they're like, you know, they might not have come up for them because they think, oh, we don't have anything to do with security. They don't have the insight, they're less mature. They might have people, you're like, at incubation, you don't need a lot of users, right? You just need to be, you know, there's a bunch of criteria. And so it could still be experimental in some way, but it has nothing to do with security and they just don't have security experts on their team and they don't foresee it happening. But of course, as we all know. Just documenting a process, how they can get in. Okay, got it. It makes it complete. It's actually a very, very good idea. Yeah. So yeah, I'll write that up as a GitHub issue. Would love to have some help doing that. Now, it is for CII best practices, a requirement to have a documented vulnerability reporting process. And it is required for a process to move from sandbox to incubation to have to attain a best practices batch of passing. Yes. And that is the self-assertion on behalf of the project. So this would be validating it from the TOC perspective. So yeah, I guess if it is a, I didn't realize it was an incubation thing. So maybe they all have it already because they've all done the bench. Yeah, I was just again validating with our project and I'm like, yeah, we have that. So that's all. I was just trying to understand what the difference is. It basically is because there's no documented, like is it more of a communication thing or it's just validating? That's the part I'm not getting. It's validating that it actually is. Got it. Got it. Okay. And I guess also to kind of like ask a bit more questions on that regard, right? If they've had any incidents before, how did they handle it? And what was the speed of the execution and things like that? Yeah, where there was some discussion that they're not gonna insist to incubation any particular speed in responsiveness, but just making sure that groups have thought about it. Which yeah, you're right. If the CIA best practices badges required for incubation, then they should have already, but this is just kind of raising awareness. There's another rubric item in there that around the response time. I don't recall the exact wording or timeframe, but I think it's 96 hours, providing a response within 96 hours and half addressed publicly known vulnerabilities that have been reported in the last six months. Now it's entirely up to a project, whether they like not disclosing while they're working on it, right? For obvious reasons. So while it is a self-certification, you need to provide a link to your policy or procedure that captures that whatever the process is. So it does make matters for us easier to, hey, let's go look at the CI, but the batch app for this project. Let's look at this particular section. Let's see what they entered in there. What is the link? So we know where to find it in their repository structure and their directory structure than rather try to like figure out how to band where to find it. Yeah, so maybe let's have that issue be created and then we can also have it as part of the discussion if there's one or two people that wanna take the lead on the issue. So if the policy just needs to be something implemented in repository that's in the easiest way to do this through automation, like sort of a secure scorecard that's one of the Google projects to do this. Let's just check in if you have certain things in your wrapper. If this is like formal verification that this is like really happening, what's the claiming in there? Like this is like completely manual process. Yeah. I think it might start as a manual process. Like it's just really the TOC establishing, elevating the security criteria with starting with something simple. Yeah. Okay. So let's go along to the other updates. I think the next on the list is John the Meadows of supply chain update. Hi. Yeah, just a quick one. So on the... Also, sorry, there's someone that's typing and the sounds are getting true. So you could mute if you are not typing. Thanks. Just a quick one then on the supply chain working group. So we're getting a lot more content onto the document. I think we're going to restructure it. I know that Emily sent through some feedback. That's great. I think we're probably another session away from having something that we'll then start to go through and do editorial on and then report back more fully to the rest of the group. But obviously all the work that we're doing is open on that Google document. And we're also discussing it in Google chat as well. Oh, sorry, Slack. Awesome. Work continues. Yeah, if you could put the link to that document maybe in the notes would be great. Thank you. We'll do that now. All right, Robert. Hi, we had our policy work group meeting this morning at eight o'clock Pacific. Happens every other week. Currently we're in a deep dive around mapping the policy report CRD to different frameworks and in particular one that's used in the federal space from NIST called OSCO. But at some point we'll come up for air and talk to other frameworks. And then I think also on the agenda we're gonna try to build out a kind of position paper architecture, a white paper on how all these pieces fit together. That's the latest. And then I just had kind of a logistical question. We use the same Zoom, how can we get access to the videos from those meetings? So people ask for the links to the previous calls. Maybe we can take that offline with the chess and TLCB. I think we have access to the Zoom account but maybe we can discuss of whether we can provide access or somehow split up the videos. Okay, great. I'll have it in the next video offline. That's good. Yeah, and if you keep us honest by just open an issue on it because then we can tag the CNCF staff people once we figure it out. Sure. Is it a question or to find a recording in some of these meetings? Yes, it's like. How do we get a link to the like this morning's 8 a.m. call? There is a link like on top of this meeting notes to YouTube channel. Well, so that's the one for the security, the policy videos don't get uploaded there. I got it. Yeah. Okay. And we have Frederick Fernando who's a new member. Do you wanna give a quick introduction? Yeah. Hey guys. So yeah, my name is Frederick. I'm from India. I'm into, so I've been working in the SOC side, the blue team side of things. And now I'm new. I'm getting into Kubernetes security and kind of playing around with Linux internals and EBPF and things. So I like how I'm really amazed at how you guys work here and I learn a lot from these meetings. I've been here for like two or three meetings and I really appreciate how, I mean the things that I learned from you. Awesome. Welcome to the group, Frederick. Yeah. Hi. I hope you weren't in the meeting last week where you saw a really bad comedy. Don't ever learn from us from that. Ha ha ha. Ha ha ha. Oh, if you secretly wanna get it on there, you can drop a dm to pop, you know. Okay. Yeah. Yeah. Okay. So I have a question. If you were to say, what are you hoping to take away from the group or what are you hoping to contribute? So I'm, okay. I'm new to the security, I mean, sorry, the open source space. I'm more, so earlier I was into the windows, infrastructure, security, like threat detection, all those kinds of things. But on the windows side. So I wanna like get in on board with contributing to some of the open source stuff. And I learned a lot by just attending these things. So I'm just gonna like stay, I mean, for the ride. Fantastic. You're on the right place. Awesome. Yeah. I feel free to reach out to chat or TL. So anyone in the community, if you're interested in working on something. Yeah. Cool. So I think that's all the updates. I have a really quick one on my side. A couple of folks in the community to get to myself. We are having a cloud native, first starting out cloud native security meet up in New York. For now, of course, it's virtual. So I'll just put a link to it. There's one such that's going on next week if people are interested. Okay. If not, let's go hit with the agenda items. So I'll pass the mic to Emily first. About the security assessment and purpose. Sorry, I'll inject one 30 second update. Sorry, I forgot to put the update. Oh yeah, go ahead. So Justin Kappos initiated a APAC friendly meeting as of Tuesday. So for anyone here where the time is inconvenient, you can go look it up on the read me. There is an APAC friendly time zone that you could possibly join. It's barely getting started. It's only last meeting we had two people show up and both of them are like super interesting. We learned quite a bit from them. So just wanted to drop in there to give people the convenience of the time that they want to join. That's all, that's the update that I had. Thanks. Awesome. All right, Emily, oh yes. All right, so for those of you that don't know, Brandon has been leading an effort within the CIG to help us do some updates and some changes to our traditional security assessment process based off of feedback from our first five assessments. So there was a group of folks that got together, had an excellent brainstorming session, pulled all the feedback in to a consolidated area and then we created tickets and issues so that we can break down the work into smaller areas. So a lot of that work has been already contributed to the repository about like, how do we incentivize more people to join in and participate? What are the values and the benefits of the security assessments? But one of the biggest things was a couple of updates to the templates as well as some new documentation to ensure that the process is as smooth as possible both for the projects as well as for our CIG members. So taking into consideration a ton of great feedback from the community over the past few years that we've been doing this, we've created a PR called, it's number 488. It's been linked in the chat as well as a particular comment in there that kind of does a high level summary of what it is that we're talking about, what do these changes look like? So one of the first things that was recommended was the utilization of the term security assessment was confusing for some of our community members is getting mixed up with security audits and we're not really doing a full-blown assessment or a full-blown audit on it. Was there a better word that we could come up with that would still capture the essence of what it is that we're working on? So the recommended change is security review which has a more holistic capturing of what all goes on when we're performing these activities. So with the change of the name, we went through the documentation that we currently had found some areas where we really could pull more from the projects to help them better create their security documentation based off of some of the previous assessments that we've had. And I feel like every assessment that we do gets better and better because we are getting excellent feedback. So the overall changes are kind of minimal, but they do make a little bit more sense and it creates slightly more artifacts as a result of these evaluation processes. So the README has been updated to provide a more comprehensive overview of what the security review process is, the actual guide that talks about the security review process steps now includes more detailed information, links to the new documents, links to templates. There's a joint README template for the first time. This actually is a template that was built from the existing READMEs from previous project security assessments. So now that we have a standard document for SIG members to actually pull and summarize content into. The joint review template replaces the existing self-assessment template that we have. It's got a little bit more detailed sections in there based off of some of the feedback that we received. And this is the collaborative review between the project and the SIG security reviewers. It builds on top of the self-assessment, which is performed by the project. So one of the discussions for why we were going to break these two things up was to allow projects that weren't quite mature enough or at a point where they could get or support a full joint review or full security assessment as we traditionally perform them could take the template themselves and kind of do an internal reflection on what is the state of their security? How are their security development practices looking? Kind of guide them down that path of thinking about security and their development practices. So it's a little bit more day-to-day instead of a big hurdle for them later on when they would come for a security assessment. It's a much lighter weight document. It's much smaller than the joint review, but a lot of the information that's generated there gets them thinking about security in a way that when they come back for a joint review, they've got all the information put together and it should help them and help us when we're doing that joint review. The project lead information was updated with the new naming conventions and some small content updates that have needed more clarity. And now there's a review survey to provide with projects so that we can get consistent feedback from them on what they thought about the effectiveness and the experience of the entire security review process was. The security reviewer role was also updated with a new naming convention and content. So this is a very large PR. There's a lot of new content in here. There's a lot of new suggestions based off of the feedback that we've gotten from the community and the existing issues. So I wanted to bring this to everybody's attention to kind of talk about it. How do we feel about the content and the changes? Do we feel that it's a good direction for us to be moving in as well as if we wanna set another standard for another five against this new process and then reevaluate or reiterate? Awesome. And are we looking for kind of just a few more eyes on the PR? Yep, that's right. So I've been working on this for a while with some help from Magno and a few others. And I feel like I'm a little too close to it to do a fair shake on doing a review. So an extra set of eyes to make sure that everything makes sense, that we haven't missed anything, that there isn't a link in a wrong place or that something is not clear and could be better explained. I also... Go ahead, Sarah. I read through it over the last week or so. Thanks, Emily, for being really super responsive. And one... I, having been a reviewer for multiple security reviews, the separation of the project would check in itself assessment. And then the review team would create a new document pulling from that. My hypothesis is that that would make it easier on the project themselves because... And put more burden on the reviewer, on the review team, and there'd have to be presumably the lead reviewer. I don't know if this was spelled out because I guess it could be anyone would be like taking suggested edits and committing them. Whereas in the past, it's been the project lead that takes questions and suggested edits and revises this document. And that's been like... It seems like that was a little arduous for the project lead at times because they just felt like barraged with questions. However, it puts on the security reviewer then has to assert things, right? So I would feel a little uncomfortable with some of the projects because I'm like, I don't know. Like sometimes I would make suggested edits being, I think this is true and it would be comforting to have the project lead say, okay, I'm gonna commit this as truth from the project's perspective. But I think flipping the roles will make it move faster. But I'm really interested to hear from people who are project leads like, you know, maybe Ash and Andre, I don't know if there's anybody else in the virtual room, maybe at Falca, whether these changes would speed things up and make things smoother or whether you think there would be. But if you wanna, like, I don't know, you don't have to respond right now. Yeah, maybe if folks wanna kind of take a look at the PR or get a better sense of it and then, you know, we can have the discussion there and, you know, if everything is good, then I think it's due for a virgin. So thanks Emily and Meg, Noah and others who work on this. Yep, one other thing that I wanted to highlight is the new template and the updated process does allow the community, the SIG community, to perform a limited hands-on review of the projects. So that was something that was requested about, can we do it? How would we do it? What does that look like? There's all sorts of caveats and instructions that we need to provide around that. How do we ensure a level of rigor? So there's been some careful attention paid in that particular area about whether or not a review did include a hands-on review or if it didn't and what all that means. So just, as you're going through the document, be aggressive and letting me know if there's stuff that we missed or stuff that wasn't fully thought through. No plan ever really survives contact with the enemy. That's it. So we really need to put it to test. But I think you've covered a lot of considerations. Refined what we had, the process we had outlined previously. Awesome. Emily, is there anything else? Oh, I'll be good to hear. Nope, that's it. I'm looking. It might be worth mentioning the PR. Sorry, I caught up right there. There's a companion PR that I requested being pulled out because it requires TOC approval. There will be. Which has been long requested, but is awaiting. Wait, did. No, the... What Sarah is referring to is originally, when I had broken apart two of the PRs, there was a new docs and then there was an update to existing docs and it was too confusing. So I merged them together into 488. What Sarah is referring to is the new process or the updates to the process was designed to more closely align with the CNCF phases of incubation and sandboxing and graduation, such that there was a clear kind of path for projects moving through those different phases. But because that requires discussion with the TOC for concurrence and confirmation that, yes, that looks right. And that's what they're looking for. We broke that out into a separate document. So you'll see some of the language in the 488 PR that doesn't, it looks like it could align with it, but it's not explicitly called out. So is this 534 or something? Yeah, I just put a link in the chat. So, yeah, so the idea is that to first merge in the process improvements that are purely within the SIGS domain, right? And then propose the TOC. This is how we would see it happening at different project stages, which then sets up this opportunity to make it a requirement at some future time. But obviously, we're not in a position, maybe not to everybody, but we are not in a position to require anything of the projects. What we do is purely to the benefit of the community and the projects. And then the TOC could choose to set it these things as requirements. Roger. Awesome. OK, so let's move on to the next agenda item, which is actually mine, which is on the cognitive security landscape, which we have now renamed to the cognitive security map. So I'm going to give kind of a quick background on what this is about. So initially, we had the cognitive security white paper, and we had this kind of notion of landscape within the SIG Security repo, right? So if you go to the landscape, these categories that say, OK, this is access control, this is key management, and here kind of like it tried to mimic the CNCF landscape, but we have different categories, and then you have projects within different categories. So what we found was that the style of information or that style of categorization wasn't really very useful for what we wanted to do, which was to kind of provide a more practical use of the aspects of security, so kind of thinking the topics that happen to white paper and provide some more practical advice on how you can go about those things, not just on the conceptual level, but also pointing directly to projects that would cover some of these areas. So let me share my screen really quickly and show. Oh, I can't share my screen. My MacBook has prevented me from doing that. Let me see if I can resolve this quickly. Do you want me to share it? Yeah, let me put the link in the chat and then we can open this. That'd be great. Also, if I resize it soon really quick, I should be able to share it. Yeah, I got it. That may be faster, so I'm just going to drop in and come back really quick. OK. All right. So, OK, you see my screen now? Yep. OK, cool. So Cloud Native Security Map, this is the new name, so the kind of motivation around the same, and we bring some about this and we put it on that, was around kind of, we took a lot of inspiration from the Cloud Native Trail Map. So we looked at the CNCF landscape, which was kind of just like a whole ball of information, which we didn't really find that useful in terms of what we wanted to do, but then we looked at the Cloud Native Trail Map, which kind of was contained information over the projects, a bit more technical information, but it also provided a way for practitioners to kind of navigate the Cloud Native space. So we wanted to kind of mimic this kind of layout information, so someone should be able to go to this document and really be able to explore Cloud Native, go into areas which are important to them to be able to figure out how they should approach Cloud Native. So the idea is we would make kind of a hybrid between the original landscape and something that more closely resembles this CNCF Trail Map. So what we ended up with, we called it Cloud Native Security Map, and it was around, there was a lot of ideas around, you know, there being multiple continents which represent categories of security, and then you would be able to navigate and go through these areas and learn about security through that. So the work was in the Slack channel, Six Security Geography. This was when we still didn't have the name for it, but we knew we wanted to have it be something with maps. So the overall landscape goal here is basically to provide a more practical view of the Cloud Native Security. So the white paper covers everything on the conceptual level, it covers kind of different categories, but then the question that if you are a practitioner, you may want to answer is like, how do I go about doing this while it's on the resources that I can look at and while it's on the projects that I should look at in order to implement this. So this is a general idea of what the Cloud Native Security Map is about. And so the idea is that we're going to take the information and we're gonna be able to encode it in a format which is easier for someone that's new to this to navigate through. So the idea is to have kind of a different continents of different categories of security and one should be able to navigate between these things. So these are a few pictures that Emily has kind of drawn up, which kind of show like, oh, you have different islands of security categories and then you can explore them and then you have to go through like from develop to distribute and you know, what are the steps that you're going through it? So in this case, for example, to go in from develop to distribute, you go through the CEO scanning and also kind of a thematic example here and then this is okay. Then you're looking at pre-commit hopes doing application manifest scanning and so on and you finally arrive at the SM harbor. So that's the general idea in which we want to have people be able to explore the topics within the landscape. And we imagine that, so this is the last artistic question that I drew out, which kind of talks about maybe like example flow of how people would use this. So the idea is they will start off with very broad categories. Or another way you could do it is if we would embed links of the security map into the white paper itself. So if you're reading to the white paper, you see a concept that you're interested in, you can say, okay, bring me to the security map on this and then it will link you into this document that will tell you for this particular concept what are the projects and how do you use it in terms of adopting any organization. So the idea here is you would be able to go into different areas to give you information about it. And you could go into, for example, image scanning, it'll tell you a bit more, you talk about technologies that you can use and so on. And the idea of this is, for example, within certain categories, for example, image trust and integrity. You could go to the next step in distribution which, okay, maybe I should encrypt the image, but also relate that to image trust and integrity on the distribute and develop time is also the runtime protection, right? Even if you sign or you add trust into the artifacts that you're creating, you still need a way to enforce it in the runtime. And therefore, it's important to also look at protecting the workloads of runtime or they do key management and so on. So this was, this is kind of like the idea behind this is that we realized that there are a lot of different categories within cloud native security. Some kind of span different categories such as, in this case, image trust where you need to do it when you're developing and distributing a container image or artifact by the end at the same time. It only makes sense if you have good key management and you also enable verification of the runtime. So these are the kind of ideas that we were thinking, right? Being able to see this information and being able to navigate this information. I think I want the main goals that we're trying to achieve here. So, and, you know, you can just navigate this however you want. So that is kind of what we are trying to do with this cloud native security map. So we are now going towards phase two which is kind of content contribution and design iteration. We hope to get all this done in time for QCon EU and hopefully to some publicizing of this project then like we did with the cloud native security by paper. So kind of to wrap up what we're doing now is really we're looking at how do we populate the content of this, right? So we have this document which is for the content and this is an example of content, right? So we have application manifest and this is a template that we came out with. You have some one or two sentence motivation on why it's important. Trads and incidents if they are available. So this is kind of similar to what we see in the security supply chain catalog where, okay, while some examples or incidents that happened because there was a lapse in security in this area. A quick description on the security relation, quick recommendations of what can be done to protect it and instances of those recommendations. So these are more concrete examples. So in this case and we're saying application manifest can be Kubernetes YAMLs. You know, you don't want to use a latest tag. You don't want to run containers of privilege or run this root users and so on. And we will have projects and references that we could have also, right? So that's where we are today. We want to be able to populate this for basically all the different categories that we had in the white paper. So there will be some, definitely some reuse of content over that. What we would really be adding on this really here, what are the projects involved with this and what are some of the more concrete recommendations and examples. So going forward is this document has been populated with kind of one of each page. So I think what we're going to strive for is to get contributions across the community to populate this document. And then we will integrate it into the cognitive security map that we showed earlier. So I'm going to put the link to the issue in the chat and also I'll put a few notes on how we can contribute to the content here. Any questions about those comments? So Brandon, at this point, if folks want to say contribute to a particular section within the content doc, are we like maintaining a spreadsheet of who's writing for what content or do you recommend them joining the Slack channel or do you recommend them joining the meeting that we have before this call, like the bi-weekly or whatever? So what's the recommended way for folks to join in? So we will organize another kind of check-in next week before this meeting. But I'm going to put like a set of instructions what it's going to be like is basically find a topic that you want to write about and then just put like an ampere. Actually, related to that if we can comment I think a few other six have also reached out to Emily trying to replicate Emily's process of how she ran the white paper. And there is a need to document that process and if we can get volunteers that have worked in white paper to document the process that will be useful even for the landscape, I would think. Yeah, there's actually an open issue on that, J.J. Let me find the issue number. I had talked to Benay and Benay said he was very interested in volunteering for that but I do know that it is a big ask because there was a lot of stuff that went on. So I will find the issue and drop it. Yeah. Is there a section in the doc or a place in the process that I could start coming in for emerging technology to things that aren't yet in cognitive landscape but that folks are interested in and I'd like to help support more folks using. So we do have one section. So this just kind of, this is just a photocopy of the topics that is in the cognitive security of white paper. We do have, I think the section, actually I should have the white paper. Here's some for her. There is a section on the white paper that I think is extensible to other topics. Yeah. So there is kind of security sack. This kind of is what we put a lot of the emerging things like zero trust architecture. And to end encryption in use as well, zero trust architecture. That's exactly the area I'd like to step in and help out. Yeah. So I would say the best approach for that is kind of contributing to the white paper. And then these things would, we would sync up on these things with the landscape on the map as well. Great. Thank you. Yeah. I'm going to put this issue in the notes as well as I'll put it down the section as well as some instructions on how to contribute to the content. And also figure out where Vinay and Emily on maybe we can discuss on that and document some of those steps as well. Cool. So I think that's all that we have for today. Next week we have Doug who's going to talk about the service working group. Yeah. And it'd be great if I could have a volunteer who would facilitate that. Ideally somebody from the, or you did you call him? I signed up, but if anyone wants to do a facilitation I'm more than happy to. Yeah. Maybe somebody who's, there's a team interested in serverless security. It'd be great to have one of them, but anyone really who's going to keep the meeting on track and make sure Q and A happens. Yeah. So if you're interested in a facilitation meeting, there is a plan meeting sections in the meeting notes. So you can just put in your name there and then you can reach out to one of the chairs of TLs to talk about what you need to know just the facilitation. Cool. Just a quick note Brendan to all the new folks out there. So we are adding a new section to the doc which lists some of the good first issues to get started with some low hanging fruit issues. So we'll keep on adding more issues to that tag in GitHub. So if you are interested in like just contributing to any kind of issues with security, feel free to check out that section. Thanks. Awesome. So on this way, I think we don't know what the topics for today. So if there's nothing else, then we can give you back another eight minutes. Yeah. It's just the usual fire hose here. This is where we start to improv, right? All right. Thank you everyone. Thanks Brendan. See you next week. Bye bye.