 Good afternoon, morning, day. Hello, good, good, everything as well. Good evening. Hi, Emily. So I think Mathew is our facilitator today, but I do not see him dialed in. That's Mathew. Good day. Hi, Mathew. Farne for my delay started up my Windows virtual machine and it decided to do a couple rounds of reboots and updates without being told. So, and people wonder why I am such a Linux promoter. Should we give a couple more minutes for everyone to be on the call? I think there's gonna be a couple of people attending Brandon's presentation, so we may not have everybody today. Okay, I'll hold back for one more minute while I get my camera going and then I'm all good to go. Is there anyone that wants to take care of Scribe slash minutes today? I've already got Scribe on. Thank you, Emily. Fill in the blanks of Scribe too, share. Okay, so all good to go. I don't see any updates from the attendees jotted down this far and there was already a planned discussion slash presentation by Vinay, so Vinay, floor is yours. Great, thanks Mathew, thanks everyone. I wanted to share some ideas that I put down in issue 405. I have posted a link on the CNCF meeting document as well and without further ado, I'll get started with sharing my screen. So the idea that I've been working on for a little while as I've been scouting and scouting the security landscape is one thing that's missing is a security reference architecture for cloud native applications and the CI CD pipeline. And as many of us would agree, I mean, it's a very, very common theme that a lot of operators are struggling with. And so what I wanted to do was to actually propose this kind of a security reference architecture for cloud native applications as well as the CI CD pipeline with the goal of providing operators and DevOps architects a holistic view and an approach for cloud native security for them to actually understand what are all the different parts of the puzzle that go to actually injecting security and how do you think about security as you're building out large scale, horizontally scaled applications, microservices. And as we know that these are highly ephemeral so how do they need to think about the security landscape and how do they appropriately inject security throughout the entire lifecycle, from build deploy to run. And one of the other goals is also to provide operators with a blueprint in order to operationalize security. How do they think about it? What are the missing pieces? What should they be aware of? What are they missing? So the goal here is rather than for everyone to continue to reinvent the wheel. I think there is an opportunity for us as the potentially the six security group to actually say, here's how we index security, here's how you should be thinking about security, here's how you should be incorporating security for all your cloud native applications and provide a bird's eye view into what that looks like and also how do you build out like a entire process and a pipeline to match that blueprint and demonstrate and another goal that I thought would be really good was to actually demonstrate the mapping of all the CNCF projects in terms of the blueprint. That's a work in progress and I'll also talk a little bit more about that. And the other objective is also to figure out how we can actually make it available via the six security as a reference for, as we publicize this, as operators are thinking about, hey, what are all the different mechanisms and approaches that I need to be adopting and enforcing in order to inject security? And I use the word inject because traditionally we all have been in that world where security has always been bolted on but how do you now inject and incorporate security right through the development and the deployment phases and to actually provide this as a reference to the community for security for cloud native workloads? So that's the objective and the benefit. I don't have too many slides so feel free to interject if you have any questions, comments, suggestions as we go through this. May I throw in your way now, Vinay? Sure. So I guess you already answered a question. I always forget to ask at the beginning questions in the middle or same for the end. In terms of actually, I guess, encouraging people to adopt it, what would you say is I guess the most practical or pragmatic element that gets people to treat it as this is something we can integrate as we go without really many pain points or loss of project velocity versus, as you said, bolted on at the end sort of thing as an afterthought because there isn't time for it. What do you think is the key parts of what you're describing here that encourages voluntary adoption? So obviously it's, I mean, obviously the current problem is the, we'd always talk about it where security and DevOps are not meeting I do I, right? And I think that's firstly, that's the end just we're recognizing that's the fundamental problem. And that's also because security teams are so often brought in at the flag end of projects or, you know, so once all the development, all the everything is done and then security teams are made aware of it and saying, hey, now you can maybe just give me a stamp of approval as I really, really need to deploy this application into production. And that's obviously the reason for a lot of this friction. And then there is this concept that security needs to be embedded but then DevOps teams don't think that you have the right tools and the capabilities for them to really adopt with their need for agility. And then security doesn't think that DevOps knows how to get security, right? As a developer and as a security person myself, you know, I built large scale applications but I'll be honest, security was the last paradigm, right? That I think about, you know, because I need to develop this application. I need to make sure that it's highly available. I need to make sure that it's reliable. I need to go through all of that. So security is the last thing on my mind and we've always thought about it as someone else's responsibility. And to answer your question, maybe to say how can we change that perception is to provide DevOps teams with the right tools and the capabilities so that they can actually adopt it. And more and more, as I think about this, I feel like the key concept there is also developers are far more willing to make changes and fixes and address issues and bugs, if you will, when they're developing a new feature, when it's brand spanking you in front of our eyes, then maybe two weeks later or three weeks later when we've already moved on to the next feature or capability that we want to develop. So this actually fosters, meets the DevOps and the developers where they are. So providing them the right tools and the visibility and I'll talk about what that really, really means in the next slide. But, you know, when you're making a pull request, you know, make sure that your security debt is not continuously increasing. Unit testing, system testing, integration texting is fundamental. Let's make security testing fundamental. So putting in together these processes and showcasing the ideal state and empowering DevOps with the right tools really, really, really goes a long way in ensuring that they adopt those capabilities and incorporate security throughout the process. Is that, did that answer your question a little bit? Yeah, that's all the money. Thank you Vinay. Sounds good, sure thing. So what I, you know, put together is this concept of, the life cycle is so important when you talk about cloud native applications and deployments, right? Which is, you have the development phase. Once your artifacts have been developed, you know, you go through the build phase, these artifacts now are built in, you know, for our purposes, for example, the form factor is container images. You go through building all the different layers, pulling all your dependencies. You build your container image, push it into a container registry and then go through a whole bunch of testing. So I've identified four distinct phases, which I think we'll all agree with, which is develop, build, deploy, and then obviously the run phase. And what I've tried to do is in this particular view, I think this is the best practices view and then the next slide talks about an operationalizing view to say that, you know, here's how your code is being developed. You have different types of code, custom code, your dependencies that you're pulling in. You also have infrastructure as code, which is your Terraform templates, your CloudFormation templates, ARM templates, what have you, as well as you're now representing all aspects of your application as Kubernetes manifests, for example, right? And all of these is now going part as your code, if you will, including your infrastructure and all of these application definitions and you push them and you make a pull request, right? And then as part of this pull request, the point is to say that in your development phase, you have the ability to do various security scans. So for example, you know, we've seen even in my day-to-day that, you know, as we are developing so many new automation templates and capabilities, you know, once again, there are so many new services that we're leveraging, we don't really, really know all the high value security controls that you need to be enforcing and applying, right? So that's the point here. And if we could actually scan these templates, scan your Kubernetes manifest, make sure that you don't have insecure defaults and actually fail a commit, if you will, and provide that feedback to the developer, right at the commit phase, it's very, very powerful, right? So that's the point that you can do. So once those things are validated and if you, let's say for example, it goes through your validation and your policies process and the develop in the pull request phase, your code gets checked into your source code management and then in the build phase is when you apply the next set of capabilities. And I'm gonna talk about this more from an operationalization aspect in the next slide, but the point of this slide is to say, for example, in the build phase, and I also want to highlight the fact, hopefully it's evident by now, the light blue boxes are all the security capabilities, right? That you can enforce at all the different phases of the development and the deployment pipeline. So in the light blue is, once your code has been checked, you'll obviously want to run it through your static checkers. You want to be able to perform the vulnerability scans. You want to be able to do the image scanning, infrastructure as code scanning, as well as your Kubernetes. And then also the notion here also encompasses that, developers need to move fast. So you probably have a loser set of policy, security policies that you want to enforce at the develop phase. But then when you go into the build phase, it's maybe it's now you're going from the dev environment to your test environment. In your test environment, you have stricter policies that you want to apply. So you have the capability of applying a different set of stricter, potentially stricter policies at the build phase, but then you apply all of these security capabilities and actions. And then the ultimate artifacts are your cloud images or your container images or your serverless images. And then the, and then straddling the build and the deploy phase is the phase of testing, which I talked about. No code goes into production without going through significant unit system integration tests. And the point theme also here is that, we want security testing to be a mainstay as part of that process as well. So once you've done your application testing, so if you have failures, what happens is it gets pushed back, developers look into it, fix your bugs, fix your issues and it goes back through the process. Similarly, we want to apply the same rigor to security testing, where you want to scan your AMIs, your container images, your manifests, and your infrastructure as code templates based on vulnerabilities, config and compliance, scanning capabilities. A simple example, just to maybe I shouldn't make any assumptions, just to give you context as to what the compliance scanning for example is, right? When we want to deploy a cluster, for example, in GKE, for example, just making sure that your Kubernetes API server, for example, is not exposed to the world. Stuff like that. If you're having a database, make sure that your database is encrypted. You're ensuring that your keys are secured properly. Make sure that the database is not exposed to the internet. All those kinds of checks, and with this new cloud native pattern and paradigm, we have an unprecedented ability to catch it even before all of these assets are deployed into the runtime. And that's the point, right? And we can fix it. So it tremendously improves the security posture of applications that get deployed in production, if you will, right? So in the deploy phase, you have the ability to actually apply a lot of these security rigor testing and approaches. And then obviously in the run phase, which is either in your cloud or your on-prem across different asset classes, if you will, which is serverless containers, host VMs, you need network security, you need runtime security, you need the capabilities for micro segmentation, visibility, monitoring, logging, tracing. So all of these are fundamental infrastructural components that are absolutely necessary in order to run cloud native applications, which are once again characterized by scale and numbers and highly ephemeral characteristics. But this architecture and the representation is to help a lot of operators who are not as familiar as us who live this, have read this day in and day out to get a bird's eye view onto the concepts that they need to be aware of and thinking about as they are deploying cloud native applications. So on the far left, you have the different phases. And then on the second to last bar, I tried to kind of represent the applicability. So for example, the code commit is pretty much your develop phase. And then your build and deploy is your CI CD pipeline. And then of course, the run phase is pretty much your infrastructure, IAS, PAS and CAS capabilities. And the fact that you also want to have operate your policies across all these three or four different phases of the application deployment lifecycle. So, and then I'd love to have a discussion. I mean, this is just a preliminary. I wanted to put this out there, but I'll talk about that more. And once again, if you have any questions, please feel free to stop me. But the next slide that I wanted to talk about is, now how does, how do operators actually think about operationalizing? So this is more of the operational view if you will, to take a lot of those components that we talked about, but then how do you build and integrate and incorporate all of these different concepts and capabilities and tools into your entire development process, right? So once again, it starts with your DevOps, your users, your developers, your operations folks and others who are developing these capabilities such as custom code, your Docker files, Kubernetes manifest, infrastructure as code capabilities. And then we talked about being checked into your source code management system. Now you have the ability to actually have a commit pre hooks where you can actually check. And we talked about all the different types of scans that are possible to ensure that these are best practices, security controls that now you can apply even before your infrastructure is running. So you can catch all of these capabilities and flag it and make the appropriate changes. And then I also wanted to highlight the fact that there are so many different capabilities, right? So for example, with the advent of open source tooling, there's so much of open source. I've never worked at a place where everyone actually had a perfect visibility into all the open source tooling, the libraries that they have, all the licensing implications there are for both the library as well as ultimately their own application. So the source code composition analysis capabilities play a very important role. And then you actually now run through all your security capabilities, which is defined and then with the development environment policies, right? As I talked about it. So you do your static analysis, you do your vulnerability scans, you do your IAC scans and the Kubernetes manifest scans. And then, so security is a first class citizen. You wanna be able, these are the best practices. I mean, these are the best practice steps that you need to execute. If they're evaluated, if any failure, if it results in a failure, you go back to the drawing board, go back. And then, so those things, there's a constant feedback loop for the developer. They're able to fix what issues they're now. Once again, I think the underlying theme also is we can't expect developers and DevOps folks to be security experts. But now with the right tooling and the capabilities, you have contextualized information on for them to actually take remedial action. And if everything is checks out, it passes, it gets checked into your source code management system. And then it goes into your build. So let's go ahead and build all these different artifacts. It goes and fetches all the dependencies. It goes through and builds your container images or AMIs or serverless images. And then your build artifacts are now checked in, for example, into your virtual machine catalogs, container registries, server registries. And then the next step is now, this is where I would love input from the folks in our group here, where now I wanna showcase how we wanna incorporate best practices in terms of signing images. We wanna make sure all your images are signed. So then once the images are all signed, then you go into your application testing that we talked about, which is system and integration tests. If there's a failure, go back to the drawing board. And then the next step is to perform your scans with your test environment policies. These are potentially stricter policies, right? So you make sure that your images are always scanned based on policies. Make sure that all your security controls are being applied accurately. For example, the NIST 800-190, there's an opportunity to actually bring that in into your build pipeline and validate that your Kubernetes or your container orchestration platform is appropriately secured. For example, you're not running your applications. That's a root user. You're not running as a privileged container. It's just so many different things that now we can actually catch and actually test for in your build pipeline. And then once this is passed through, then we wanna actually now, for example, this is where I want to bring it back to the vision that I have in terms of, let's talk about the in-total project, right? Where you're talking about software supply chain security. So this concept of this controller and how it can actually validate that your images have been signed. There has not been any kind of modification or changing of your binaries and your images, et cetera. But you have the opportunity to inject these policies and these capabilities at different parts of the deployment pipeline. And then you go into the deployment phase where now you can actually incorporate these steps to validate the image, the hash, the signatures, et cetera. And for certain kinds of using admission controllers, potentially runtime image policies and then your runtime compliance policies. And then there are three different capabilities yet again. And as you can see, which is the configuration, the appropriate security of the container orchestration platform, then the appropriate configuration for the host as well as the pods, right? So that's the kind of representation that I've tried to afford here. And you wanna make sure that you have the right policies. There are so many best practices and this goes back to now the platforms that we work in, whether it's Kubernetes or OpenShift or one of the cloud vendor managed platforms, it's still a shared responsibility model. So you have to, they give you the capabilities. So you have to make sure that they are enforcing the right capabilities. So for example, the NIST 800-190 is a special publication that talks about container and security for container and application containers. So there is a whole bunch of security controls. So you need to make sure that you are applying those best practices in your for your container orchestration platform. And there's so many different as I talked about, give you examples about privilege containers, et cetera. So, and we need to make sure that our operators are aware of them and then make sure that they need to take steps to actually enforce that. So here's how, here's providing an ability to showcase how they can think about enforcing those kinds of best practices. And then you talk about the hosts, make sure that the hosts are appropriately secured and configured based on your compliance controls. And then you also need to make sure that those hosts are appropriately locked down in terms of either network policies or network security, make sure that they're not making unsanctioned access to malicious domains, et cetera. And then we talk about pods, right? So you have to think about container and pod securities. Yes. Quick question, Vinay. I was wondering with respect to I guess one of the final deliverables, like if this was to be seen through to fruition, what do you see as the ultimate deliverable? Like is it a large, heavily documented slash well designed documentation wiki? Kind of like say, the Kubernetes documentation, does it have specific examples without necessarily advertising or advocating a specific implementation? Like here's how you do future XYZ with GitLab, with Jenkins or some other pieces like that. Is it meant to be a broad documentation project? And B, is it something, for lack of a better term, somewhat democratized in the sense that the request is that once it's in the right direction and it has enough maturity, CNCF officially adopts it and endorses it, for example. So I guess what are the desired implementation outcomes? Rough ballpark, I know that's always down the road and B, what's the intent in terms of, I guess audience and promoting it? Yeah, all great questions. So initially, I think the premise is that, these are very, very complex systems. As we can imagine, each of these is a big project in itself. Like for example, if you're taking into consideration hardware. No argument for me there. So I beg your pardon? Oh, sorry, I'll mute myself. I was just saying, no argument for me on there, I concur. Yeah, so, and that's the sense, right? So these are very, very complex projects. So we wanna actually help our operators and our users, ultimate users along the way in helping them understand how they can wrap their heads around it, how they can approach it, how they should be thinking about it, how they can adopt it, right? So the first goal is to give them some kind of a sense as to how they can, what are all the different components that they need to be indexing as they're putting together a plan for, fundamentally their CI CD pipelines for cloud native applications. But then I think we would all agree that we don't want to be, let security be a bolted on capability, right? So we want to constantly advocate that security needs to be built in. So we want to highlight all the different, psychogenetically speaking, the security capabilities that needs to be incorporated into this entire DevOps and DevOps process, right? So some kind of a consumable document that gives them a bird's eye view in terms of what are all the different components and then how can you operationalize? And then if this group feels like we can take it a step further, which I think we could in one example of that is to actually say, how do we take harbor? How do we take in total? How do we take tough? How do we take, I don't know, certain other capabilities, binary authorization, all those different capabilities and then take a generic framework and make it a specific use case, right? So I think there's potential to take it further and make it a little bit more specific. But the initial goal is to provide like a totally generic agnostic platform and potentially portraying the ideal state. I think that's my initial goal. But I think, and that's where I'd love to hear feedback and comments from the community here on how we could take it forward and elaborate and really make it useful for our users. I think, first of all, I just wanna say, I think this is great. I think one thing that has struck both me and I think probably is striking others is that this is actually very similar in many ways to the goals of both the white paper that we were planning to do as a group and the landscape. And I think, in fact, we, some folks who've been working on those two efforts have had met a week or so ago and came to the conclusion that we actually have a lot more overlap with what we're doing than what we were thinking, perhaps from the outset we might have. And I just wanna say that I think it would be good for us to all, like for you to join those conversations along with others that are interested in this because I think now that we're sort of three times independently seeing the need for the same thing and taking what on the surface looks like it has some very mild differences. But I think underneath really doesn't, is mostly the same way of presenting the same information. It would just be, I think, better for us to kind of converge on something rather than having three different almost identical perspectives on basically the same topic. Is there a specific conversation or a thread that I could copy paste a link to in Slack? Justin, just so we could say, hey, here's this presentation, here's the link to the YouTube recording when it goes up, let's converge these discussion threads. I'll have to look on that. Because what's largely happened at this point has been the landscape work has mostly been, Brandon and myself, although we have had a bit of feedback also from Yeeling and I think the write up has mostly been Emily and JJ. I think we've been sort of reusing the six security chairs and tech leads channel that we talk on sometimes for some of that discussion especially since we've really only had one initial meeting. So maybe this is something where we need to create a new channel and open it and let people come in and discuss or open the existing tech landscape channel and do that. Let me follow up with others and we'll figure out something to do this and we'll have that like making this a public thing that we'll mention how to get to from six security before the next meeting. Hey, Justin, could you remind everybody what the landscape is and then I'll follow up with a little bit about what the white paper is? So everybody has a understanding because I don't think we've discussed it often enough across several of these meetings. Got it, okay. The landscape, I think actually this diagram that's up is an ideal way to talk about what the landscape isn't supposed to be. It's basically supposed to be the flow of how... Sorry, so it's supposed to be a way for you to figure out what tools and processes and things exist to add security throughout the way in which you're making, deploying, maintaining, so on, your cloud-native application. And so the idea would be is that you could go into something like the picture that you have here, which we have a picture that's a little different in some ways but is kind of in spirit, fairly similar here. And then you can go and click on things and you can see like these are the concerns that you should have at this level. Like these are the types of attacks that have historically happened. These are the types of protections that are available and these are what will happen if you apply these protections. Like this protection here will make it so that it doesn't stop somebody from breaking in but it allows you to detect it very quickly and mitigate it. Or this right here makes it so that even if they break in the damage they cause is very limited in this way or whatever else. And the white paper is meant to be, well, actually Emily, maybe I should let you talk about that because you've been more involved in it. So the white paper is intended to be that, think of it as the landscape and the items that Vinay has been presented more at a high level C3 executive overview. A better understanding for a technology officer or a CISO to get a more clear insight into what cognitive and cognitive security is and how that intersects with their development life cycle. How does that affect their organization's ability to adopt specific products? Where should they be focusing some of their resources and some of the conversations that we've been having around that in the landscape is there's overlapped audiences are slightly different, but a lot of the information can be used across them. So with the white paper coming at it from the perspective of we have all of these stacks or ecosystems associated with cognitive practices, there's DevOps, there's the Buffer Development Life Cycle, there's your core stack, whether or not you're using platform as a service or functions as a service, whatever it is that you're deploying on or if you're bringing your own case and communication, what does that stack actually look like? And then there's just the general application development that goes into all of that. What is your application definition look like and everything that goes into it? So these are all, it's essentially the culmination of the problem that anybody in security or anybody moving into cognitive is having and we're coming at it from a bunch of different angles either from the top down or from the bottom up. Because we've realized that there are people across all sections of the community that don't have access to this information. You have to have been in for a long period of time to be able to fit all of this together. I have a question of the, oh, sorry, good evening. No, I'm sorry. So, Matthew, Michelle's had her hand up for a bit and the back of the other could have been. Yeah, I have a couple of questions. One, how would you like the feedback on this? Would you like comments on the document? Or do you want, I see you have it in GitHub. How would you prefer? Because I have specific comments about the order of eight and 10. I don't know why you would sign. If signing is intended as a symbol of immutability, why would you have eight before 10 and why is there no distribution mechanism in place to maintain integrity of the supply chain better? So I'd like to add that to the, however you'd like written feedback, but just let me know. Sure, thank you for that. I think you can, the commenting on the ticket would be fantastic. On the ticket or the document itself? Either, either. Okay, great, great. And I'm happy to contribute to this. I've worked on an attestation process before because I really think that it's more, it's about validation and attestation and it's, but I have some concern in that like the reference architecture that you're prescribing is, it could also be called the DevSecOps reference architecture, right? So, where's the value add? And there are millions of those out there, right? So where's the value add in specifically, like where are the differentiation points for cloud native, right? I think that's going to be important to note because this, a lot of people see similar things out there. Is that, sorry, I'm not trying to be... No, that's a good question. That's a great point. Maybe if I could quickly just sound out on that and I think some, I just opened the floor up and I know others wanted to have input. I think the value add for this group to be able to advocate for one of these kinds of reference architecture is they have a lot of thought leaders and subject matter experts and then putting our heads together if we come up with some kind of an accepted, validated paradigm that goes a long way in helping operators and adopters have confidence that they can adopt this kind of a paradigm which gives some kind of weight given the fact that it's been coming from this particular group, right? So I think that's the value I see in collaborating here and putting something out to answer that question. And Chase, I believe you wanted to say something. Yeah, I had a question or maybe it's a comment there. I don't know. Funny enough, I made this similar diagram just in the last few months for similar reasons, right? And basically this is very difficult to conceptualize and then without some kind of table conversation piece in the meeting with developers and other stakeholders just within my organization, right? You just need a thing to where everybody knows that you're talking about number seven or everybody knows you're talking about number six. And without having some kind of infographic, it's virtually impossible. So that's my experience. And it's interesting. I think it was Justin that there were kind of have been three variants of recognizing that all of the lego pieces are dumped on the table but nobody's really laid out like, well, if you wanna build a monster track, right? It has wheels, it has an undercarriage, whatever if you wanna build a pirate ship, et cetera, et cetera. But where I'm wondering if this is a gap and maybe it's an intentional honor. Maybe I'm way off on an island. But if I'm looking at this and I'm thinking about it in terms of just the CMCF in general, I wanna be able to go to four or five or 12 or wherever. And I wanna see what components of the CMCF ecosystem play here, right? If I go to the landscape, you know, when I was looking at this, I think I put in the notes that like if CMCF were a company, right? And was trying to sell all this stuff, you're talking about like a, not even quite a product roadmap, but like a portfolio view of like how all the components could fit together into a cohesive whole. But whereas this is generalized, right? Which is cool and maybe that's the thought. I don't know if any, I wonder if any of the three variants have a goal of saying, hey, this is where Harbor fits in. It covers some items of seven. You know, these points that cover some items of, I don't know what seven is here, I can't read it. But my point is just like, if I'm looking at, if I go and look at the landscape page for CMCF, all I see are 150 boxes. And they're grouped, but not, and they're sort of functionally grouped, but they're not process or workflow oriented in that way. Right? So for me, like if I'm looking at this, I want to use it as a translation mechanism for like, you know, I need one thing out of this bucket to fit in here, you know, but it's not clear at least to me how the buckets translate for say, okay, you know, service providers, I remember as a category on the landscape pictorial, but like, you know, where does that, some of them are pass providers only, some of them are whatever, that would be an easy one to sort of draw straight lines to, but if that existed, boy, I would be overjoyed and I would use it all the time. So I'd be interested in contributing. And again, I don't know if that was on your mind or if that's appropriate, but that's the piece of this where, from what I've understood of the descriptions of the three initiatives, that may still be missing at the end of the rainbow. Yeah, I think just quickly to highlight that, I think that, I think bullet number four, so that was one of the potentially the next steps where we could demonstrate the mapping of all the CNC, not all, but let's say as appropriate, you know, based on industry, I like what you said, you know, building this monster truck or I don't know what you said the other one was, some other maybe a spaceship or whatever, for all these different, I think that as we mature through these things, and I think it's applicable across all of them, and to actually showcase that, you know, here are ways in which you can put these Lego pieces together to your point. I love the analogy to build what, ultimately this is what you wanna build, but here are the pieces that you need and here's how you can put those pieces together to potentially build the Millennium Falcon, for example. So I said, but Millennium Falcon is also accepted. And Justin, correct me if I'm wrong, but the intent with the landscape is to provide that level case that you're looking for. Yes. Yeah, no, absolutely thanks for that, Justin. So I, because when I was on a call where I think you and Brandon talked about the landscape, and I think maybe I got something a little different out of it, because maybe the granularity with which that presentation was done, I think I was trying to provide a little bit more of an abstract view, but I think it could be highly complimentary, and I'd love to discuss that a little bit more. Yeah, so that's where the overlap between the landscape and the white paper comes in. The landscape is to provide that level of granularity with the explanations and the appropriate context for somebody doing that level of shopping, so to speak, where the white paper provides that higher level of extraction and the generalized concepts associated with it. Steve, what you presented kind of bridges that a little bit more between the two of them. That's something that the tech ways and the chairs have discussed last week. I see. Yeah, I mean, too much. I just want to jump in for a quick second. I just want to jump in for a very quick second to ask if Justin Cormack had an update or something you want to present. I don't see any specific issues or PRs, so just want to make sure you have a window of opportunity if there's anything you need to bring up. If not, we can leave the remaining 15 minutes for today's meeting with Vinay and everyone else. Yeah, no, I actually, I just wanted to conclude with one last few comments. You know, I'd love to collaboration and pick it out there. So if we can collapse all these into some other ticket that makes more sense, happy to do that. But, and Justin, if you could please just let us know where we could have the further conversations and how we could collapse these efforts, that'll be great. Awesome. So Vinay, this is great. You know, your input and the goals here, you know, align very much with something that we've been trying to tease out and everyone who's sort of approached how we lead and align everyone together has struggled with. Now, since I've been grinding on this particular problem for at this point, better part of two years, I want to level set a little bit on how we got here and make sure you sort of manage expectations in line with that. So, you know, the founding premise of, you know, the safe working group, secure access for everyone that eventually became a security was, you know, really to, you know, bring together the points of view around security that were underrepresented in the constellation of projects that, you know, the Cloud Native Computing Foundation brings together and the Federation of Corporate Interest that the CNCF represents. For better or for worse, we start, you know, this journey with a lot of these projects and they're contributed, you know, from a lot of different organizations. So, you know, I love the articulation of, you know, the product company, you know, we are starting as a multi-conglomerate, you know, organization that has inherited all kinds of legacies from everywhere in a Greenfield's opportunity of ecosystem change. So, you know, the challenge in that of articulating exactly like what it is that we're doing and how we get there is, you know, in that origination, you know, really, really hard because we aren't actually coming from a point in time, you know, Greenfield's premise, we're coming from, you know, this Federation of all these parts that are coming together. The white paper as, you know, kind of, unfortunately, you know, it's tended, you know, towards unified theory, you know, kind of, you know, perspective of what this world is and how it should work in security. We've ripped out a lot of the lower level components in our architecture that, you know, for the last 20 years, we've been able to make security assumptions on and those things are no longer valid. And then as we look at the components that we have in our system and, you know, how we pull them together, you know, that those things are all operating on a complex set of assumptions that, you know, many folks actually haven't aligned on or, you know, didn't have the context of what the underlying, you know, things were or how those things have actually changed. And, you know, all of those things need to actually be articulated so we can have aligned upon frames of reference that we can draw forward. You know, I think there's a great opportunity to establish robust consensus about what those pillars are, you know, just in sort of assessing, you know, where, you know, things might be heading in this articulation. The one thing that I can sort of get you an easy no on is I think that SIG Security, you know, defining a comprehensive representation of how this is all implemented for all the use cases is probably outside of our purview. You know, that is something that, you know, I've leaned on corporate interest in the past. Organizations, you know, that have a stake in the game, you know, could align to, all right, here are the pillars, you know, that we cover and how we implement that. That is in my mind, you know, when you complete this journey, what success looks like is that we have, you know, organizations that are actively interested in pursuing the needs of those end users, aligning to the consensus work that we've, you know, built out or contesting those pillars and, you know, producing artifacts that, you know, that articulate the specifics of, you know, a reference implementation in line with the work that we can do here in SIG Security. Yeah, no, it totally makes sense then. I mean, just to summarize, I think my goal was just that I see this and I think we would all agree to this, that these are some common issues that we see on a day-to-day basis. And then just to, I thought there was an opportunity just to put out like a very, very generic framework. I mean, it's not, and I'm being totally vendor agnostic, right, which is, so just, this is kind of the, what operator should be thinking about as you think about these things because security has, for cloud native has always been, it's been problematic. And here's how a lot of the initiatives of the CNCF and a lot of those projects, especially, right, which I like, which is Harbor and Intoto and Tough and so many other mechanisms really, really go a very long way in helping getting better security posture. And now just to, here's how you could potentially operationalize it because I think, and I'm a bit, maybe I've gone skewed a little bit more towards that the maturity scale is all over the place, right, from an operator, so just to give them that context. And I think that's why, and not make any assumptions. And that journey is hard and it'll take a lot. And there are all kinds of ways in which folks kind of give themselves out, either they're too big or they're too large. And they'll be like, oh, doesn't apply to us. And expressing the needs that need to be addressed will help folks see, oh, okay, that's a consideration I haven't addressed and I can move on rather than, oh, this isn't valid. I need to think of DevSecOps reference rather than this. I think both can be valid, but if we're starting from that quote unquote pure cognitive perspective and articulating the key components that we see there, that's a defensible position. Right, awesome, totally makes sense. Thank you. So I think from what I can take away as a next step is to maybe have a few more discussions with maybe Emily and Justin and see how we can collapse these efforts and contribute to the existing work items and artifacts. That's good. And a lot of great points in the chat, by the way. Thank you all for the inputs. I mean, that's been great. And would love to see, do we get to save this chat somewhere somehow from this meeting? They are recorded and automatically uploaded to YouTube a couple of hours after. Even the chat on the Zoom chat. It is. I don't know, but I'll just copy paste it right now. Oh, that's included, Tim? Okay. It is included in the archive. We currently don't do anything with that or make that generally available. So it is, but kind of it isn't. So if we want to log this as part of the issue, what is it, 405? Then what Matthew's done of just grabbing the chat and dropping in that issue, probably the easiest way to make sure we close that loop. Just revisiting one thing. I'm just gonna call it one more time to Justin Cormack. Did you have an update? I didn't see the no update brackets beside your name. Sorry, no, I don't have anything this way. There's a couple of things I think we can wait till next week. How's this? Okay. Sorry, back to you, Vinay. And Dan. No, that's all I had, everyone. Thank you so much for your time. I really appreciate it. It's to my understanding, Justin Kappos will be picking up on the alignment of the, or at least bring up the discussion of the alignment of white paper and the communication channels used for that. And what Vinay has put together today, as well as the landscape. Is that something that'll be posted in the security Slack or a new ticket on the GitHub page? Yeah, I'll put this in the scheme in the Slack channel. I'll just put a link to this. I think what we'll do is just create a separate channel because we're gonna have a lot of conversation in here. And I wanted to talk with Brandon first to figure out if we wanna reuse the existing landscape channel that we have or abandon that and make a new one. And one additional question on the landscape. Does it, is it a landscape in the generic sense or does it literally use the CNCF interactive landscape like we do? No, it's generic sense. It does not use the CNCF landscape. And the few minutes we have left, does anyone else have any questions, comments, concerns? All right, so that wraps up for today, everyone. Thanks everyone for joining and hope everyone stays in good health and good spirits. Thanks, be well. Thank you. Thank you very much, thank you. Oh, I think you've got to ask it as a meeting. I'm still on, okay, thanks. Yeah, I miss the loss of chunk of the meeting. So, because I have other things to do. So I joined back, but like, No, well, thanks for reminding me. Now I think the recording will end. Nice to meet you. Cheers. See you.