 Hi everyone, for those that just joined, I am filming the Google Doc. Please feel free to go in, put your name down, if you have any updates or you want to share with a group, just write something and parentheses beside your name. Let's wait a couple of minutes for more folks to track all in. If there is anyone that can help us scribe, don't have to be too detailed, kind of just take notes on what sounds like action items that would be appreciated. Thank you again, Alex. It's good that you've been doing it a lot recently. Thank you very much. Alright, a couple more folks joining in so let's wait until they are connected and then let's start. Let's address in the matrix. I don't know. You should tell us then address. I wish I knew. The stream everyone sends on to that. Alright, looks like everyone pretty much is connected now. So that's that I pasted in the notes again, please put in your name and the attendances. And if you have any updates, put an inference beside. Today we have a pretty packed agenda. We have several discussion topics and several new issues and updates on certain projects. So let's get started until we're going to go do a round of check-in. So let's say no dates before we get started. This meeting is recorded and it follows the CNCF code of conduct guidelines so standard rules of black. So going through a CLCB fulfilling in the list so I will make sure I swing back to do another check. Diego, you have an update on the county security map. I didn't really have a gender item of this right. So I can, you can talk about it then, or do you have something else that's not on the agenda. No, no, but I can talk about it. So let me just share one second. I mean, I think we're already on the agenda right so we'll get into that later. Okay. Yeah, okay. All right. Next up, Mark PCI Council update. Hey guys, this will be really fast. I mentioned this a few meetings back. PCI Council is writing a container security test practices documented for payment card into PCI payment card industry. So finance centric, but this is really the best practices for containers. I'm going to steal stuff from our own white papers and so on. So if people want to be party to that and help me write paragraphs to that I'm mainly looking at the ICD aspects of this. That's the best. Awesome. And if you have any links, please add them to the document and chat. Yeah, I've got a list or you have to be party to it. Thanks. All right. Emily. Do you want to like to come updates and then the other stuff in the agenda. I actually had two of them so lexicon is going forward doing the team is doing a great job of providing some of those definitions for terms. Not quite ready for everyone to start reviewing it yet but they're getting closer. The other one was a quick update on security pals. They've reached out to cross plane and artifact hub at a minimum those two but I believe there's there's third one that I'm probably forgetting about starting conversations. Everyone seems interested and that's kind of where we're at those. Awesome. Is there is there any. Is there any ask for any volunteer so any, any ways to contribute that. So the, the security pals is just limited to the three projects currently and the few and the those individuals that we have working on it and this is to test our engagement early with sandbox projects to determine their appetite for completing a self assessment. Awesome. All right, cool. All right, Tim, you want to talk a little bit about the automatic scribe. Tim, we can't hear you if you're talking I just want to make sure you hear me now. Yes. Okay, cool. So I just put the link in there and love for people to just see how does it work. I think we're getting pretty close. You can do it asynchronously enough to do it. Now, pretty close to like starting to implement this so that you'd be able to access this. So the scribe the search, I think one of the cool features people are playing around with if you add plus one it automatically captures that snippet and puts it in the side. But we don't need to spend time on it right now you guys can look at it on your own and then give me feedback because I'm getting close to like getting to implementation to make it available for all of you guys for transcription and summaries. Thanks, Tim. Yeah, it's really it's a really cool thing and yeah. I think one of the nice features if you go to the site it's like if someone in the chat said like, toss one something or like this. It will kind of try and detect what was important and action items and kind of track them. Yeah. Cool. Thanks, Tim. Going to the updates here. Robert says it's going to be joining late. We can put him on the agenda later. Raghashree. Okay, so you have to cover my Emily that's all good. We had a TLC meeting on Tuesday. Andres and I were there to kind of represent the sake, and they were talking about incubation processes and that the main part of it is like, yeah, they're making the TLC sponsor own the entire incubation process. Andres, do you want to talk a little bit or chime in on that. Yeah, sorry I was just typing pasting the PR and chat for those interested in the details, but the gist of it is the TLC is trying to streamline the incubation process by appointing a designated talk sponsor upfront. Andres has been a project going over the due diligence requirements and chasing different sakes and filling out the doc ahead of time, they would first find someone in the talk to sponsor the project and hand hold them and direct them throughout the process. So from a security perspective, we would typically either hear from, well, from this point on would be hearing from the talk liaison, or from the talk sponsor for the project of we have a project in pipeline. We need a security review or we need a recommendation, rather than some project we might have not heard of coming to present to us first try to get buy in for us to try to go sell it to the talk so that's the part of it. I'm pasting the PR right here. I can scratch all the text that I was writing around it and just give you the link. Awesome. Yeah, and I think I think throughout like we were having some conversations on the call about you know what is what is really requested to say and I think this acknowledge that security is kind of a special case in which our security is kind of a little bit different from the other six right it's not just for the it's been an ecosystem and it's good technology but even for the non security projects for you we do also need to provide time for that. So quickly add on to that. That was a topic of conversation today with the talk liaison Liz and Justin that they're looking at ways in which we can highlight the security of projects regardless of the stage that they're at and what mechanisms we can engage with them either asynchronously or synchronously to improve their overall security posture. That's right. Ultimately that's the goal. Yeah, and while the other thing is it was typically very consuming for for the talk, you have the entire to see on the call listening to a proposal to hear out things that they could have read through the red red me file of read me file of the project. So also moving away from presentation proposals and more like fleshed out written proposals. From a security standpoint, we would still want to hear presentations throughout assessment processes because it helps us inform the assessment and a lot of the as Marios, in which a project might be deployed. So, yeah, well, this has yet to be merged will learn more as as this gets implemented, and we go through it. Let's see how much changes. Cool. All right. Let's get to the agenda. So quick announcement before we hit to Tim, just since he has to leave for the early so quick reminder, cognitive security day is made up of this con coupons that have been sent out in the sick mailing list. If you are not yet subscribed to the sick mailing list, please do so. Yeah, so there's like, I think it was a 20% discount or something. Any additional notes of that interest in Emily. Oh, that's pretty much it. You're good. Awesome. All right, let's hit the Tim then. So 10% that a couple weeks back and then this is a follow up. I'm going to pass it to you to kind of do the introduction. Okay, super. Yeah, thanks. So it seemed like a good time we're working on the white paper I really read it like three weeks ago so maybe some of the observations are not germane at this point. But I'm also coming up with the roadmap and the way I kind of like thinking about robust I'd like to write out like a blog that like tells the overarching story and then I figure out kind of what fits into it and I figured this is like a really good group for us to figure out. It just makes sense and that the difference at the time when I read it but it's how I was starting out my blog and how I think through the roadmap was getting a handle on the problem space and seeing well what what seems to be the issues what are a priority and then for this group what what should we try to solve for or even can we solve for them so that's what I wanted to like get some feedback on really quickly so here's how I started was thinking you know and at the time when I read it I was like well it would help to understand when we talk about supply chain where are the problems we could visualize I'm not saying this is the right way I liked it because it was a good starting point there's lots of different ways you could do it, but it does start to put into context. Okay, there are lots of pieces in a supply chain, and then what tend to be the attack vectors. Based on that, and then from there iterate because I think last time we started to go down into the tooling tool chain discussion, and I felt oh it might be better to start. Hey, let's frame it as what the problems are and then we can iterate on tools or a list of tools and that would be helpful for me to. So so I'd love some thoughts and feedback on that that's kind of how I've been doing and then I try to make it a little bit more explicit in my own mind. What is the range of the attack vectors and so this is a bunch of different sources and the stuff that I threw in there and this is where I could use some some some guidance but you can kind of see this one bucket around code signing like that seems to be a bucket that stands alone but there's a couple of different ways people access it something that we would call. I think the terms pretty good distribution vectors which is how do they get the malware to be distributed. I was sort of pinging on a little bit because it wasn't really covered in either in really great detail on many of the sources. I've read by been thinking about a lot was, you know, the identity problem, which is, you know, a bad actor, unknown actor, or, you know, a fraudulent actor and kind of like how do they, you know, do that and if you kind of think about we don't sometimes we don't really even know who's contributing and we think they're legitimate or they're bad, or, and it was a takeover. It's been very specific things. Yeah. Could you give like a little bit of context just in case for those people that were not previous on the previous call. What is kind of like the, the, the, the end goal. Oh, right. Yeah, so the end goal was, I wanted to figure out what do we want to do in terms of approaches, like we already are planning on rolling out some kind of basic vulnerability detection that has dependency mapping that seems to be kind of well defined. And I wanted to see what else is, is, is next like the next thing that we know is going to be keys. Scanning for keys and sort of kind of fits somewhere in SCI I suppose kind of sub bullet. But some of the things I was getting stuck on was, well our people interested in, you know, DAS there's a lot of complexity because I started to go down the path of evaluating a DAS solution but I was like, oh but you know everybody's runtime is sort of different to people want to bother with instrumenting that blah, blah, blah, blah, sassed fuzzing. And then I started exploring a solution around code search, which was more initially around improving productivity for developers so it's like, you know, imagine it's like Splunk or Google but for your code. But I started to ask the creators of this tool, you know, is there a security application because I feel sometimes there's issues when you have sort of these vulnerability databases whereas people who are closer to the code may start to think through what the vulnerability patterns are they may just want to do a fast search in real time, or build out their own libraries on their own. So I want my end state is this, like, what do you guys think we should try to consider making a standard offering that's enabled through a security portal for projects to ease the instrumentation and reporting. But before I could get to the tools I wanted to understand well what are meaningful problems, and then we can kind of say well. Yeah let's try to explore these tools. And then when you say offering that would be an offering from the Linux Foundation, a host. That's correct. And so the way we've been doing it is and that's why the tooling discussion will be in fact valuable when we get there is. And one of the things I had heard was oh well there's lots of different tools I have to pick a tool how do you get neutrality. So we're going to take that out by saying okay we're going to vet vendor a without some arrangement and a lot of times we have to make the spoke arrangements in terms of billing or integrations or the UX to solve for certain things so you know and the goal would be okay now you have a single control plane that you could then govern it for a project instrument your repos and you know kind of simplify and not have people have to go and search a vendor and then do a POC and all this other stuff. Hey Tim it's you know that I think there is a similar approach and our voices of open software security foundation, and that they are doing creating their own tools and services to improve the supply chain security right so So do you want justice to be focused on commercial vendors or do you just want to No, no, no I definitely want the open I've tried to reach out to open SSF and I couldn't get clarity how far along the tools were, whether we should do it or not and so I figured let me triangulate by having, you know, a different set of practitioners, some that you guys might be neutral whether it's from open SSF or commercial versus they're doing it and that way I can kind of harmonize between the two. I don't have a clear picture of what they're going to do when it's going to be available. What's the difference between that and commercial tools that we try to offer so I think that's part of this exercise. Yeah, so they're going beyond SCA and vulnerability right so they're also considering other attributes about open source libraries, securities and risk like they do have a package feed and the criticality score. There are multiple tools around there and they have a dashboard where they calculate all these metrics and give you some knowledge score for the for an open source package right so I think it's good to consider those tools and some of these tools are not necessarily going to help that much with the supply chain problem it may help with the application security of the software in building inside a company not necessarily a supply chain security specific right like SAST it is not that practical to scan all the open source code through a SAST like I don't know how many companies are doing that and even yeah so SCA itself is kind of a limited approach for open source security. Yeah, that's kind of what I've been sensing to but I couldn't, I couldn't tell when I synced up with David, what's the status on, you know, release and is it working and is the metrics well defined. So if all the tools from so on the extreme if everything from open SSF will fit all the needs and requirements from a group like this, then problem solved. If there's a gap, and we need some commercial tool, then, or other tool, then I would like to understand that. One example for example is fuzzing so when I would talk to them they said well yeah you know open fuzz is available, but part of me was like but even if it's available how easy is it, and how widespread is it used across projects and so there we would be tackling okay maybe we have a control plane, which is makes it much easier for everyone to run code against open fuzz if that isn't done, or, you know, helps them to record the output or select what the library is used like that I'm open to as well. So I have a quick question. Tim is there a path or a mechanism by which as the SIG discovers gaps in these particular areas that we're expected to engage with the foundation to highlight an overwhelming need in this particular area. We have a lot of projects ongoing the supply chain paper is one of them. There's the map and as some of the SIG leadership as well as a lot of the SIG members and the community members are discussing like the current state of things and other attack just happened. What do we do what are we recommending to people we're starting to realize key areas such as the ones that you pointed out for which there is a lack of tooling that's available to the community. And we're struggling with where do we where do we write all that down right now that looks like cards in our repo. But is there a path by which we can engage and say hey, we were doing X, Y and Z. We've noticed that this is a potential problem area and we'd like you guys to focus on this or just just a place where we can point to. That's a super great question to which I don't have an answer. And given I don't have an answer, we could, you know, co created here, like, you know, you guys are the most active. What's useful for you. I actually don't have it's a super great answer. And I think having a solution would be super I don't have a prescription at this point so what what what do you think works for you and if it's like the least friction and highest fidelity for you, then I'll just follow, and then I'll just use that as a source of truth for the C&C of SIG. I think you have you've got a couple of areas that are already here that are called out as potential problem cases. I think if it's intended to be our SIG ownership of those problem areas from a security focus remember that that's kind of like how we're scoped, maybe having something akin to this listing in our repo where we we've particularly called out problem space, and then just engaging with the foundation to be like hey you can always go here and look for any things that we identify. But again, we're going to be limited in scope to just that, whereas storage secrets management, there's a couple of other areas that have similar problems where they're finding gaps in the community that are not necessarily security specific. I see. I know that at least the TOC has asked us to kind of engage them with helping to identify where there may be not really gaps well gaps in terms of open source projects. I think we have kind of that. We should have a discussion there. And part of the part of the landscape size security map was to do together some data. So, I think that what you laid out here Tim is probably a good start as well to kind of have a discussion around this. So I just want to do to understand so you that's I think that's like two different discussion points. One of them is discussing what are some things that we need to do to enable like maybe invest in a new project to enable the security community as a whole. And the specific problem that you're looking at here is how do I increase the security of open source projects with by providing a service right just to make sure that I'm not mixing up two of them. Yeah, I that sounds right, you know, and I tried so this one I started from scratch but then we did that whole exercise for the DoD and I reach back to them say hey what's the published outcome for what you guys did they didn't they haven't gotten back to me the two folks that are that are working on it so I, you know, we could always you know I like the format that we did last time to as a spreadsheet and you know that was super valuable. So I'm pretty open, and I'm hearing the two things one is what's the list that you guys like this one's probably not a very great great list I just pulled it out of my whatever kind of like jamming through it just to give a context but you guys probably know a lot more. And then like you said, where do we go to find it. So I'm open to what they think the form for the right form factor is, meaning, you know, I like the idea of a repo. I also like how we have that spreadsheet which allowed us to kind of say here's the problem is what the thing with the solution was that seemed interesting because then could add on. Here's how we plan to do implementation. Or here's an existing solution then the kind of debate, oh open SSF solves this or this is a better solution and stuff like that. So those would be the outcomes but I don't have a prescription. So here there should be consideration that a lot of the projects are run by skeleton cruise and the fact that they don't do this things are is not out of neglect is they prioritize other things. Exactly. Yeah. Okay, go ahead. One of the stories you've actually stated the sub problem, which we're trying to solve is how do we make it super easy. How do we make it for those that are skeleton cruise to still have some level of security assurance. Like the higher order bit question is, okay, what's the scope of the problems which I'm turning to you guys as practitioners, what it is, and then the product aspect is okay how do we enable it for the persona of someone who doesn't really have time. Yeah. Like take flossing for example, I've seen maintainers of the flossing projects for the creators of a flossing tool approach CNCF projects and say hey, we'll help you implement flossing and maintainers like don't have actually not taking those offers, even though they're getting it from the expert. And a lot of it is, well, there's there's a whole lot more to this and their implications and their considerations. So if it were something similar to the CNCF service desk model where the LF is going to make a person available to work with maintainers and help them expedite all the due diligence to be able to, like the problem is not really technology right it's, it's putting it yet going back to your diagram that like, even system design stage, and making sure that, well, yes, there's there's a problem we can consume in the service, great tooling, but making sure you can hand hold the project maintainers and make it and even do it for them just like do that augmentation for them. So that it's not additional overhead where they don't understand the implications of well how's this going to change our build pipeline how's this going to change the threat model of our project like this is going to uncover stuff that we're ready to tackle at this point, etc etc. Yeah, that's a good point. I really, I really like that. Yeah. That's one. Yeah, I was thinking about fuzzing as well. I was thinking about, you know, the kind of like domain knowledge that you would need to know to implement the fuzzer. Yeah, that's your application but like, if it's a service based model. Yeah, it could be. Even if like just open source tooling right doesn't have to be as tough as we could just like oh we do a security process for you go write a CD pipeline for you or something like that. Like, even take like running the web infrastructure for web pages of the projects. Maintainers are not doing that and there's been like some shuffling on the CNC upside for the people that have put up Netlify and do the load balancing and do cloud flare for this project has moved on and now like maintainers are scrambling because they haven't dealt with this stuff before. Hmm. I love to hear those use cases on the deployment side, and maybe that's something that we, you know, we just iterate on this. So I just wanted to kick it off. It seems like there's some things I don't have answers on like where we go to put those in there. I'll take my lead from you guys because I think it's whatever is the least friction for you that gives lowest friction and highest fidelity. It would be good to talk to a few different projects and interview them understand their paints, because I'm speaking strictly from the experience of spire but mileage varies right. Okay, cool. Well, the, that's it for me. Maybe what we do is I kind of jumped to another meeting, but I think we framed it. And then let's see what may happens the next week or two on thoughts that we come up. We can we also have the slack in terms of what you guys want to do in terms of the repo location like where the discussion and, and the things go and I think that seems like a good starting point that sound good. Yep. Thanks so much to him. Thanks you guys. All right. Okay. Yeah. And also I think I will open up an issue for the point that Emily brought up, which is like kind of looking at gaps right already did it. It's posted in the chat. Great. Great. Awesome. So, I think that right, and then let me let me open this, I'll open the issue for Tim as well so that we can at least get the track going for this. And next on the agenda item is you Emily so Yes. All right, let me go up and figure out what I'm talking about meeting summaries first and foremost. So, for those of you that probably already know and those of you that don't six security is considered a global group. We have a community spanning multiple time zones. And, and as a result of that expansion and community interest we do have an APAC region being that occurs where they have lots of conversations they are active community members and they are engaged in these discussions. So, my effort to ensure that the work that they're doing as part of the SIG is included in our discussions. I have made an adjustment to the meeting template to include a review as part of the attendance of the notes that came from the last meeting. And then we reflected both for the APAC region as well as this region. So at the start of our meetings, we should or the facilitator should go through and do a quick summary of what was discussed at the other regions meeting, and then a pack would do the same. This is in an effort to be a lot more inclusive about our globally diverse community. So that's the first item. And then the second one is inclusion language changes. This is issue number 478 it was originally brought up by Andres, and I wanted to bring this back to the community is something that I think we can actually get taken care of. So this is regarding the use of non inclusive terms within our repository, we do have a few of them to include the branching schema by which we employ within the SIG. So what this is is it would entail somebody going through probably grabbing files, doing changes to some of the terminology, as well as a decision point in which we switch over from the master branch over to the main. This is especially important because the talk has already made this change. And initially we held off on it because we were concerned about breaking all of our links. So this is, well it may seem like a small change. I understand that it's a big ask by the community to take care of this. Awesome. And I think that also I was just looking at the issue that the link and, and, you know, this is a whole discussion thread on tooling that can help us this as well. This is a great issue for somebody that wants to have a positive long lasting impact on the SIG and how we move forward and kind of these engagements, as well as you will be exposed to pretty much every part of the repo and you will learn a lot in the process. And I would say, I would say like, don't feel like you have to do like gigantic PR and do everything at once. If you can identify, okay, you know, I'll do the changes within this single document within the set of files. Feel free to just go ahead and create a PR. Or start small and as you as you do a PR refer back to the issue do a couple of them at a time and we can save the major branch change at the end. In terms of the inclusive naming I mean it was in the New York Times recently in terms of like the crew that put that all together and stuff like that I think it's an amazing initiative for all of us here so kind of like putting my two cents in here, even though it's unsolicited but it's it's a really amazing initiative they've done a bunch of projects so I think it would be awesome and whatever I can do to contribute I'm going to do here. Okay. So the issue is in the document, I'm going to paste it in the chat as well. Cool. And we have our last agenda item for today, which is project criteria for listing projects and the colleagues security map. Diego. Yeah. Yeah, I said, see a second. See if I can share. No, I cannot share. No, anyway, permissions thing. Okay, so the thing is that I think most of you know that we have been working for a while in the cloud native security map. I'm going to put in the chat the link of the show. And apart from that we've been working on the web version so that people can see what are the recommendations what are the different areas related to the security white paper and how people can see the projects that can help them examples and descriptions and having more information. But now that we have we're close to complete the all the areas of the documents and there have been some questions like we are having a lot of contributors and some of the projects that can be included might not be potentially stable enough mature enough or with the right quality. So we started thinking what will be the right pattern conditions so how people can trust that the information that we show is going to be useful because we don't want to confuse people and say like Oh, use this open source project that was built five years ago, and nobody did the committee in four years. So because that will reduce the confidence of the audience. So a minimum criteria that we are starting to write down is things that we consider that can be useful to filter a few of those projects. And that's why we wanted to present to you the what are the options if you agree, we're trying to see what will be a similar criteria for example for sandbox projects in the CNCF. But then the process needs to be quite clear at the beginning rather than going through a review pool. We will like that people know in advance, how they can propose a project so things like the criteria will be something like the project has more than one contributor. And the project has more than six months of lifetime. There are regular releases and their active committees in the in the last six months. And it's a priority if it can be a CNCF projects or Linux Foundation relationship so that this is a discussion from the rest of the group of what is appropriate. Any other suggestion, what is important, but the goal is to always provide good quality projects so that people trust this resource. Any questions. Do you have a list that you can maybe share on the screen. I don't have a link right now, but I will say I'll put something like this in the chat. It's part of the essential elements but and that's why we wanted to bring it forward if somebody has some objection suggestions or indications of a good reference of starting filtering projects. Otherwise, we will just move forward with a few more detail descriptions in when the contributors wants to add some projects and that will be the reference. So, so part of this is kind of I think we were discussing this as well as we hope to not get too many angry messages from people to be like, why wasn't my project, not why isn't it in this list or why is it like, you know, this guy's project in but not mine. And I think the idea is to make it as objective as possible and to have a criteria that I think covers all the basis that that people should have about I think we haven't really decided on exactly what the we have this Scott criteria but I think like maybe that is also consideration to like the wait for it. Maybe, you know, having more than one contributor is going to be at least a minimum requirement. And then, you know, being CNCF other not the same project is like, nice to have these additional points but it's not, it's not a requirement to be in this. What when you say more than one contributor shouldn't that be like meeting certain boss factor. When you said when you said having more than one contributor you mean total one contributor to the project or one contributor from here. Um, total more than one I think. Right, Diego. Yeah. Yeah, we might want to raise that you know what like best practices patch or sandbox innovation criteria we really seek that. And the, the bus factor is this formula if the whole project works take a field trip and they're involved in an accident. Unfortunately that with the products though, succeed and carry on without this group of people and there's there's ways to calculate that you want Emily slapping by our frame that sorry. It's the not necessarily the vendor independence portion of a given project but more about the project continuity success. But that's, I believe the right way to say that if somebody inadvertently becomes unavailable will they still be successful. The nicer version of that is the lottery factor to pretend the project person won the lottery. And they can't they're going to do open sourcing where they're going to live on an island or something. Yeah. So we are looking forward. And we didn't we all win the lottery being part of this group with Andres and Diego, then we all in a lot. Yeah, it's just it's just to make it more clear because as Brandon said like we we think that people say oh why my weekend project is not included there because I think it's really nice and help people. Rather than having just a long conversation with some people just like we think it's not aligned with these specific criteria. I think walking that line between allowing users to be more informed versus actually providing a grade is very tricky. I think that a lot of it has to do with how we present or how we label some of that. So if the intent is to allow a user to make a more informed decision about this being 100% transparent and kind of the things that we would be concerned with where we evaluating the project. I think I think is very important. As far as more than one contributor, I would ask I would make the recommendation that it should be more than to burst off. Because they could, you can have two people and they could be doing awesome and amazing work, but they can also just go to the same company together abandon the project together or leave that one person overwhelmed with the massive amount of things. To that end, I think that we should be very clear and upfront about like what what kind of those expectations are and incite that principle that Rory eloquently stated for us a lot everyone as the kind of the reasoning for why we're looking at that particularly. That's good. Yeah, we will just say I'm just putting this for debate to make a richer decision. Another thing that we will also I think thinking about is, you know, whether can we kind of make whether we should just either make it or you don't and you're on the list or not. We have like multiple categories of projects. Like, you know, obviously a project with like 12,000 stars CNC a graduated project, and then you know project from from that's much smaller right then like it's there. Do you want to make the distinction between those two things and then that also becomes a trick exercise. Is there anything in the criteria about some sort of proxy for measuring how widely a product has been adopted or how widely a project is being used. I think I recall in the CNTF broad based landscape. There's something about you know, open source projects with 300 or more stars which I assume is sort of being as a proxy for you've got 300 or more stars there's at least a few people using your project. Do we have anything like that under consideration in these criteria. Yeah, I think that we, we talked about that, but there's always some time sets them. Yeah, it's to put a limit and a number that we consider appropriate, because why, why 300 and not 500 or 200. The other problem with the specific GitHub stars is that quickly becomes a popularity contest. And we would like to avoid that at all costs. So it's a good idea. And if we figure out a way to do a somewhat accurate measurement about the use of a project across industry. That would go a long way to helping them in seeking incubation and graduation criteria, because that highlights project maturity. So I think that was more about we're looking for is like what is the project maturity. How, how do we quantify that as something, and maybe, maybe that's not necessarily a fixing a numerical value for assignment but showcasing where that falls on that chasm chart is it early early adopters it innovation is it like, where is it out on that curve. Any source reliable source to identify the usage by other parties that you would recommend anyone. I honestly can't think of anything like if GitHub had that content for how often a project was clones on a recurring basis from a centralized or singular IP address. That would be a privacy violation. But that would be like, you think so. No, that's right. But you said, I think they do that. Where it's container images that Docker hub not I know have that because just in Cormac talking about it today on. But, but yeah, I don't think for where it's not a Docker image. Yeah, I'm also worried like a lot of this information is a necessity public and I feel like it's also gonna take a lot of effort for us to go to every single individual for checking out for it. I think like a CNCF. This one I just put in channel Brendan is one that's fairly good at a high level it's not going to go in depth right in terms of just understanding contributors contributions commits for positive or is that that the thing. I just found out about this like two weeks ago and you know like, it's pretty incredible like you can kind of see an overview of each one of the underlying projects. I don't know how many lines of codes are there but like again it doesn't stick to a specific criteria but I would assume that the upper like line of these of okay X amount of lines of code X amount of contributors would would be something that would be something that precludes them or adds them to whatever thing we have here. And again I think this is beta, but it's been super useful and some of the recent pursuits I'm in. Well, that's cool they have you update that all the information you're just talking about. I think that might be a good source to look at. With the meeting I contributed something guys I can ever you all I can I can leave. It's not an appeal. That's just that. Sorry. Good. I would say your biggest contribution this this meeting is secure Batman. The next project. You know, an often overlooked file but a great indicator of the product health is the adopters file, if there are public adopters. It's one to look at and encouraging people to do that. Yes, for security projects there's a lot of organizations that won't publicly state this is what we do, but while there's, there's other signs of evidence whether the product is as well adopted or not, versus a developer spawn up 200,000 bottles to go do a kid clone from this thing. So a lot of certain metrics depending how you measure them can be not very meaningful and just a ton of noise because maybe someone clone this thing once but they rolled it out as massive production as someone has a big lab and they've been pulling this over and over and over again. I think that's what's all these things make it a little bit difficult to make a clear cut quickly. I would add on to that. That's actually a good suggestion. Andres it triggered something else for me. If we have the ability to determine whether or not there is a security file on the repo. So there is a security tab in GitHub now that talks about whether or not there is a security policy or security advisories. And one of the things that we talked about in the security review process was being able to assist projects and creating their security file within the repository. And making sure it's discoverable because it might accept acts and a contributing file or in the main cadence file. Yeah, I see this now. And another like a lot a lot of CNCF projects have dedicated community managers and these community managers from surveys at certain cadence and often they're like net promoters core questions in there. So if you recommend the product to others. Are you actively panning on implementing this product we should. And we should try to encourage people to put those things on on the repositories to have it readily discoverable and we don't have to chase community managers. Okay, I think that's it. I think we will write them all these details and propose a final version of all the properties that we think are important. Awesome. Thanks to you. Cool. Cool. Any other topics that people want to bring up. And the other things that people want to maybe suggest for next week's meeting. And next week is next week we do not have. May 5, there is no meeting because you can you're up. So hopefully everybody can attend and show up and have a lot of fun. And I expect to see every single one of you at cloud native security day and I will be personally upset if you don't make it. I will cry. Andres will hear about it. Yeah, as most people here are going to be sleeping during the event. Well, at least half of the event, you know, Awesome. You can all just come to the proper types of summer time for a week. We're all moving in or you have a spare 10, 20 bedrooms. So I've got like a couple of acres. I live in the middle of nowhere. I was going to say, he will offer hiking tours for all of us. Are you saying that aqua is sponsoring us? Oh, no, no. I got trouble with that one. Awesome. Thanks everyone. And it shouldn't be long after that that we regroup to start talking about North America. So, yeah, that's right. So if you're interested in North America, keep that in your back pocket and stock the issues while you're going through and trying to close some of them out because you're awesome and you like to contribute. On to ships. From Aqua. Ravi are going to get a lot of emails soon. Oh man, that's, that's what actually I don't say. For all the money. All right, thanks everyone.