 Hello. Brandon. How's the guy? Good, how are you? Sarah, how are you? Well enough to say hello and listen. So it's good to see you. All the new faces. Avatar's names on lists. We'll give it a few more minutes for people to join. While we are waiting, if you can update your attendance on the meeting, meeting notes. I just dropped a link in the chat for people's convenience. All right, just one more minute and we'll just get started. Thanks Brandon for signing up for Scribes. Anyone else wants to join? Who can do Scribes? Second Scribes. All right, so let's get started. We have a few things that we wanted to cover. We could cover today. Sarah, do you have any updates that you want to add to? No, I just wanted to. I've been on a bit of a leave of absence for about six months. So I wanted to just introduce myself to folks who are new and say hello to old folks. I'm one of the co-chairs of six securities. So Sarah Allen, ultra source on all the things. Good to see you all. Welcome back, Sarah. Welcome back. Yeah, she's instrumental in bootstrapping assessment. People that are new that didn't know. She's been instrumental in so many other things as well. So. So we have some updates that I'm seeing. If anyone else has any updates or anyone else wants to go, please add your updates on the attendance. Emily, you had some updates on. Security day. If you want to go. So, like I said last time, we are going to be doing security day again for North America this year virtual. We had a great discussion on the program committee did with the NCS. So the website is live. I will be posting it in the meeting notes and the call for CFP is also live. So if you have a security cognitive talk that you would like to give, go ahead and submit a CFP for it. It closes October 4th. So keep that in mind. This is a short crunch time to get everybody in and reviewed and get, make sure that you have time to do all your recordings. Yeah. Emily, can you post a link to the CFP to the, in the chat and the notes. It's in the notes, but I will make sure it's in both places. Okay. So, I read the map was helping us with the, who would strap the white paper with this, she was going to join and, but she was going to join through phone and she asked me to give an update about update, but when she joins, I think she'll probably introduce herself. I'll put that as a backlog for the updates. But for the agenda that we have today, Vinay has updates about white paper. And I'll give it to him. Thanks, Jay. So should I just get going on that item? Yeah. Share my screen. See the cloud native security white paper update. Yeah. Great. Yeah. You know, I think we talked about it last week. I think Jay and Emily thought it would be a good idea to provide an update to the team on the progress of the, the white paper. And that's the objective that we'll cover over the next few minutes. Once again, for those of you who don't know me, my name is Vinay Venkatragwan. So I thought it'd be a good idea to start with the, the goals for this paper. And it's been, I really liked it. And it's been stated in the paper, which is provide a framework for securing cloud native applications. So, you know, as we know that this is a very, very complex landscape that's evolving around, you know, cloud native, micro services, large scale, et cetera. But we as security think that it's a really good idea to provide our perspective and a framework for operators. And I'll get into the other audience aspect as well, but generally speaking operators as to what are the different dimensions that they should be thinking about when they're talking about security for cloud native applications. And hopefully we will achieve that using this white paper that will be obviously generically available. The audience that is being, and once again, please feel free to interject and provide comments and ask questions. As we go through this, the whole idea was to provide an overview, but you know, we can always expand it to take questions, answer, clarify any questions or comments. The audience for this paper was meant to be the, the CISOs, the CISOs, CTOs and architects. And to really, really give them a comprehensive as well as a bird's eye view into what are the different dimensions that they need to be thinking about. And, you know, modern security pipelines are starting to become very, very prevalent, if you will. And so how do you ensure that you're injecting security? And I think we're all very conscious of the fact that, you know, generally and typically speaking, security is, has always been an afterthought, but that's just not going to work for cloud natives. So the posture that we are providing is to say that, hey, you need to make sure that you're injecting security throughout this pipeline. And as you will see shortly, some of the cloud native layers that we have identified very, very broadly speaking is the develop, distribute, deploy and runtime. And in each of those different broadly speaking phases, if you will, from a cloud native application, development, deployment cycle, how security fits in. So the current status is, you know, for the last six to seven weeks, I forget exactly how long, maybe even eight weeks, there has been some fantastic collaboration going on around the paper. And also Emily has done a fabulous job of keeping everybody informed and on point in terms of soliciting inputs and then assigning stakeholders for various sections. And consequently, what has happened is there's been some phenomenal content that's been developed on the paper. We can even switch to the white paper very, very shortly and maybe we can look at the current status. But thanks, Emily, for doing a phenomenal job of providing constant feedback input, keeping us on track. And what has happened is there's been some incredible content around all the sections that I mentioned just now. So thank you for that. And if anybody would like to collaborate, I'm sure we're still taking input and the paper is available. And what has happened is it's gone from a raw version of the paper where we know, you know, the collaborators are providing their perspectives input to a more, it's starting to get a lot more formalized. So that's very, very exciting. And so there is a link to that as well. I don't know if we can share it or we can share the issue that's tracking all of these activities. And that's the next point that I wanted to mention. It's more from a broad collaborative document or more concrete document and framework. The target is to reconvene and review the paper in a couple of weeks. And so, you know, we still have a couple of weeks where we're trying to make sure that all of the different sections fit in and there is a natural logical progression between all of the different sections of the paper and to make sure that we are highlighting all the important dimensions and attributes for cloud native security. Then there's also been some good progress made on the security structural model. And maybe I can even share that once we're done. There's a link to that. But what we have seen there is, you know, to provide like a bird's eye view into the different phases, if you will, which has started to form into the develop, distribute, deploy, and the runtime phases. And then for each of those different phases, provide a double click into how does an operator think about security and what are the different opportunities to inject security, what are some of the best practices, et cetera. So we have some, and thanks to Jay and his team for a lot of creative work, the diagrams are starting to really, really flesh out very nicely. So there's a link in my PowerPoint for that. I will also share a link to this PowerPoint so that you can have access to those documents. And, you know, the next thing that I wanted to talk about so that just we level set and it's obviously opening it up to more conversation is some of the major sections in this paper that are starting to form are, you know, we're going to start with the goals and objectives and, you know, the personas we identify and what the, our audience can get out of these papers. But once that's been done, the major sections are, you know, we go into a deeper dive into the cloud native layers, I talked about it. And I think even from an industry perspective, you know, everybody is converging on these four broad categories when you talk about the application life cycle, which is develop, distribute, deploy runtime. And as I said, each of these we go dive deeper into each of those sections to articulate what operators should be thinking about and how they can think about incorporating security into each of those layers. And then we also have another section called security assurance. And this is where we are starting to talk about threat modeling and how, what are the different attack vectors, etc. And what are the resources that are available from an open source perspective to help security practitioners as well as different personas think about the threats potentially to their environments. And then there is also a section on compliance. And then there was also some good discussion on the potential personas that came up in the last meeting, I believe. So there is also a section on personas and use cases. So I think when I looked at the paper, you know, the cloud native layers has a lot of great content, security assurance section is also starting to develop pretty well. But I think, you know, we could use with more eyes on the compliance and the personas and use cases, as well as a few other sections that I'll highlight shortly. So before I continue on to the next couple of slides that I have, I'll pause and maybe would love to see if there are any questions that we can answer at this point. I saw some, some comments in the chat, maybe. I guess it's market. Is there anything you feel like is gaps where we, you need some more help or is this on the home stretch and you're just letting us know? Definitely. I think it's the former, but also I think I, I mean, from my perspective, I think we're in the middle stretch, if you will, and getting closer to the home stretch. So I, from my perspective, I feel like I think the compliance section could definitely use a little bit more detail. And even the, and then the personas and use cases are also just to make sure that we are highlighting all, we're not missing any critical personas and the use cases thereof, but that's a good segue into where we need a little bit more content, specifically storage. And I know Emily mentioned that she has reached out to the six storage group for their perspective on storage security and its applicability into, you know, the, the container model and what, what are the threats, what are the aspects that need to be addressed from a storage standpoint. So we definitely could use with more content there. And also in general, I believe, you know, anybody, please feel free to review it and, and maybe comment about the intro and as well as the transitions thereof to the various sections. We could definitely use some help in those areas. Hi there, this is Adna. I wanted to comment on the compliance section. Are we thinking about integrating with the OSCAL continuous compliance framework? I mean, has anyone done any work in that space with NIST? We had a conference earlier this year where there was a lot of emphasis on building those probes into the code itself. So there's no external compliance validation required. It's continuous compliance and auditor can just get a dashboard or some metrics through which we can validate the compliance of any particular application. I'm just curious and I'm happy to help in that section as well as the use cases. Yeah, those are great points Adna. I mean, we can even jump to that section if needed on right now. But yeah, if you could please take a stab at that, that would be fantastic. Another area that we had discussed at that point is forensics and investigations. The whole detection piece, right? I see a lot of enterprises dumping a lot of data from cloud-native applications and platforms into slunk. But then the detection takes so long that the container may not even exist by the time you detect something. So there are multiple layers of detection required. So I think that's an area that we can really add value to the industry by enumerating that in the paper as well. Absolutely. And I think that is one section where we have a section in my mind that would come under the runtime section. And I think, and we should definitely call out, you know, for example, an example that comes to mind is an unsanctioned process, right? If some kind of malware exists and it starts executing, you know, how do you quickly and to your point, these are all very, very ephemeral. Unlike traditional security practices, your asset is no longer there, but to be able to find, detect and alert on that is very, very important. And I think we have done, we have some content there, but would love for it if you could please review it and supplement it. Radhina, while you're online, would you want to introduce yourself? I was going to have you introduce later, but know that you're talking. Okay, so thanks. I did introduce myself, I think a couple of weeks ago. Again, my name is Radhina Chital. I work for TIA organization and it's a financial services entity that I lead the cloud security program for. I've done a lot of work in banking and finance. I've worked closely with NIST and cloud security Alliance on a number of initiatives related to cloud and container security. Thanks, Anand. Thank you very much. Yeah. Yeah, actually a side note here. I know a couple of people also working in Oskar. I think they'd be really interested to have a chat. So if you don't mind, I'll reach out to you after the call. That sounds like a plan. Yeah. I'm happy to do that. Awesome. Thank you. I have a question, Vinay. How does the contribution process looks like? Is the document just a word editable? Or is there like a public request process? So how do you want it to work? Yeah, I'm going to defer to Emily or Jay to take that one. So the folks that are part of the original working group have direct edit access. Everybody else is role viewable, which should give you suggestion options to go ahead and suggest content changes. If you find that it's not working for you, reach out to me or one of the other folks in the working group and we'll make sure that we get your comments included or work on fixing the permissions for you. Thanks. Cool. Thank you for the fall. The questions that those were great. Hopefully it helped everyone else on the call as well. So now I just want to maybe conclude with, with the timeline so that we are tracking for when we want to hopefully converge and have the final draft ready. So we're in this period between September 2nd and September 23rd, where we're still going through this collaborative review, but we're still going through this. We're still going through this. You know, showing up certain sections that we need and making the appropriate changes. Once that's done, I believe we want to spend some time. Talking about and going over the narrative voice review as well as we are ensuring that we are aligning with the goals of the paper. And then between October 7th and 14th that week, we'll do a final group review. And then we're going to be able to see how we can present this to the broader C and CF leadership team. I don't know if that's the TOC for final adjudication and would obviously depend on their schedules, but I believe we would like to have this paper done by KubeCon. Is that right? Yeah. That's the goal. Yeah. And so that's that. And then maybe I don't know why do we want to do that. I was also thinking maybe JJ and Emily, does it make sense for us to also maybe just brainstorm in terms of, you know, we talked about, there was so much of, there's fantastic content in my opinion. But we also thought that maybe there is a possibility for breaking this up into, you know, secondary papers, if you will, or deep dives from a certain practice perspective. Does it make sense for us to talk about that ? Does that make sense? Or should we defer it to a later point? I think it's worth talking about. JJ. Yeah. No, it's worth talking about. I think the group will end up deciding in terms of like, how to break the content down and into smaller chunks. I did have an initial chat with Brandon about that as well in terms of trying to take a lead on that effort to figure out how to break that content and then help through with that. But happy to brainstorm about it and take inputs and see how we can make that better. But it absolutely needs to be broken down with the amount of content that we already have. Right. Awesome. Yeah. No, go ahead, Sarah. Oh, I was kind of having a side conversation with Brendan earlier this week. We were brainstorming. One of the ideas we came up with was like having somebody who's in the target audience review the paper, like maybe at this narrative voice alignment to goal section. And I'm wondering whether people, like we know people in our network who are in that target audience, so we could be say, Hey, what's a white paper you've really loved? How long do you expect to spend reading away? So we can get a sense of what's the target, like, is there a target length? Or is it just as long as it's readable and some of it is in appendixes, that's fine. You know, so we might look out at for similar works. You know, or look at the other white papers for the six, like it'd be great to find like well loved, similar work that our target audience identifies or just say, Hey, could you take a look at this? And, you know, maybe when it's further along and give us some feedback too long, too short, missing things. Wish it said that. Yeah. So the white paper for anybody that hasn't looked at it yet is last time I checked and I might be wrong, I could have gotten longer was 24 pages long. And that is with a lot of really excellent and fantastic content by all of the contributors. And we don't want to lose any of that content, but we understand that 24 pages is very long. And depending on whether or not our target audience is comfortable sitting for that long period of time, they may not be. We want to make sure that we're breaking it down into an appropriate amount of readability for them. So those are all really good points. I've already reached out to Amy to help and to talk to Cheryl to help us identify who those folks would be that would be ideal to help participate in that final group review for us to make that determination of whether or not it's just right, or if it's too much. That way we can, we can continue to move forward. I could even ask the CISO at my organization if he would be willing to possibly review if that helps. Yeah, the more reviewer, the better. Yeah, from a CISO kind of persona. And I was also thinking maybe does it make sense to actually have an executive summary version? And I know this is maybe part of that whole breakup, but does it make sense to have an executive summary kind of a kind of a version of this, which is maybe two pages, which gives the, you know, which captures the essence and the content for the, you know, the CISO and the CTIO kind of an audience. I would say yes to that. Sort of the template for that is the way NIST does it. There's usually a couple of page summary. It's longer than an abstract, but shorter than the introduction section of the paper itself. So, similarly, Forrester, we're a regular consumer of that content. Forrester does the same, but NIST, usually it's two or three pages at the most. Yeah, I also think that there's, there's sort of like two formats for distribution, right? There's, I've heard people, you know, talk to me, people have approached me when we first started the white paper initiative quite some time ago and said, well, they really want a PDF. They can read on a plane. Right. So that speaks to having long format. It's all together. And then there's, you want the website, which you can browse through quickly to know, do you want to read the long thing? And, and there may be some intermediaries. So I think as we get towards the, we have it in its, you know, long form shape, then the CNCF has resource, like people who can help with, how do we get it out there? And, you know, do edit passes on that. And so I think, you know, like as we get a little farther, we can engage those folks. And I think it sounds like Emily's already started to talk to Amy about that. We have good support. Once we get the content, you know, wrangled and the first set of reviews where we've got all the sections plugged in, I think. I mean, it does seem to have quite a lot of very specific detail, like you should action this thing that don't, but I think maybe it could be taken out into an appendix or something that it's like, rather than principle, because it's going to make some principles and actual concrete recommendations for specific situations. And it kind of reads a bit. It's just differently detailed in different places as well. So I think maybe taking some of the specific recommendations out into an appendix or supporting document. Or I mean, in some cases, there are better external recommendations for specific things for what to do on Kubernetes, for example, as there's maybe material we could link to rather than putting it here and just having more general principles of this is why you need to do the X. Yeah, this is fine. I mean, that's a great idea, Justin. So, you know, as I was just kind of going over this quickly, there are some content in there that, you know, going back to, you know, who the audience is, I think the great content, I think it's going to, some of it's going to potentially either be going above some individual sets or they are going to ask that question of, well, why am I, what is this recommendation and why is it that I've maybe seen something different from a more authoritative source, right, whether whoever, whether it's from a vendor or some sort of technology outlet. So I think having taken that bit and pieces out and linking it to a more of an authoritative source for some of those recommendations might be a great recommendation. I think one of the things that Quentin Poole, who was on the TSC and we sort of first started talking about doing a white paper, I wanted to share his perspective, which I thought was quite good, which was we don't have to, as a group, come to an agreement on everything, like if there are things where there are different practices in the field, you know, maybe different resources that offer different ways of doing things, it's welcome to produce a section that says there are different practices in the field. Here are some references to look at our group, you know, we, you know, we think they're different per situation or this one is innovative and not well prodden, whereas this one is, you know, something that's been in practice in 20 years and maybe needs to be revised, right, like, or whatever, like whatever the group consensus is, even if that consensus is, we do different things. I think it wouldn't be a welcome thing because it helps people understand the space. They're not necessarily, in fact, you know, like, they're not necessarily looking for, this is how you do it, if there isn't a really established common practice. That's a good point because I think when one of the goals of this paper is to provide a framework for securing cloud-native applications, and maybe that's the, the what. And so this paper focuses on the what needs to be done and what needs to be thought about from a security practice. And then there is those, maybe those deep dive papers or the separate practice oriented, which is the house and they could be different versions and formats and we could maybe provide some references to, yeah, we're not being, there's no prescription, but there are many different ways of achieving those what's. Yeah, there is one thing I'd also like to remind this, there is a landscape that's in queue. Yeah, I was just going to mention that. Which I think covers like many of what we are talking about. Sorry, Brandon, I'll let you comment on that. Yeah, so I think, I think, when we were going through the, when I was going through the five paper, there were a lot of things that, a lot of good detail that I think that we will map on the landscape. And I think in the initial discussions, when we were looking at it, we were like the five paper and the landscape kind of would go together. So I think the idea was that the five people would kind of be kind of a document which focuses on concepts high level. And then it would link on to a specific part of the landscape. So at least for folks that one, like a really deep dive into the specific effects of it, they will kind of read the five paper and the landscape kind of side by side. I think that's what we were envisioning with that. Yeah. Also, could I suggest perhaps if we could add also a section called non goals in addition to the goals. For example, if this would be if it is specifically excluding edge type of services edge type of applications, for example, for the under the security umbrella or not, I think that might be helpful to the audiences. It's not clear to me whether it's we are including those or we're not. So there is a section for scope and assumptions and we do identify a few things that are considered out of scope. So if something isn't clear, let us know either by commenting on it or dropping a note and the channel. That way we can get it address. Yeah, I realized that there is a scope there, but I thought maybe if there is a separate heading, also is to if there is such a thing as that things that are not under the scope, maybe to point that out more firmly, that might be helpful to the audiences because, you know, rather than reading through all these things and then finding out, no, this is not quite applicable. Just a suggestion. Yeah, that's fair. We should definitely keep that in mind. Thank you. So that's, that's what I had from this update perspective. If there is any discussions around it. Please feel free to jump in. There is a channel. If you're, if you're not already part of the, if you haven't already joined the, we make sure them seeing the channel name. Right. So, the security white paper channel, a lot of discussions are happening there. If you feel like you want to participate in that discussion or you have things to add or just want to listen in. That'll be a good channel to join. So that's most of what we had in the agenda. Gardi is there. Gardi had contributed quite a bit to the white paper as well. So, a robot added one more thing to the. Next meeting. Okay. Mark also had an update on. Yeah, short thing. Those of you missed it last week we were talking about. Oh, the challenges of using GitHub. forward looking use of GitHub in enterprises where we're concerned about leakage, accidental leakage of credentials, intentional leakage of intellectual property happening in parallel to the need to disseminate, for example, e-commerce APIs, which you want to promote adoption for, and what kind of controls you can stand up around that. So we've had some internal, there's a PR about this, so happy to see more thoughts around this. And one of the facets of this that came up as we talked about it recently is the problem of enterprise metadata management, because if you try to, there's a temptation among the security people to jump in and say, well, we know what we need to protect, you know, this kind of data or this kind of code or this kind of API. And it's dangerously moving toward the SME landscape of either the applications or further behind the application lifecycle, the subject matter of what the app itself is supposed to do. And a way around that is, you know, in the model of the enterprise data management council developing taxonomy or just, you know, regulated metadata of some kind, because then the security tooling can inspect for metadata and assign policies based on access to certain kinds of resources that are in GitHub or that are internal that are going to be controlled through multiple tools. And we have multiple tools that are available to control access. And just for clarification purposes, original thinking was we'll block all uploads to it. So that was kind of the severe initial thought that was around this. So that's another facet of this. I don't think that's going to be possible in smaller enterprises. It's hard to do even if you set that as a goal. It tends to be a big company thing, like standing up a separate QA department or having somebody who's there to answer regulator questions 24 seven. But it is a facet of this that's we're talking about, because the ownership of metadata is one of the crosswalks between security teams and the domains that security is supposed to be protecting. So that's just another facet of this multifaceted problem around using GitHub and enterprises. All done. Thanks, Robert. I mean, thanks, Mark. Robert, do you have do you have a link to that PR that you talked about? Yeah, I think we had it in the meeting from last week, but I'll put it out here. Okay. That's in the meeting notes from last week. Robert, did Brandon say you had some some updates that you want to give? I don't see it I think that's for next week. That's for next week. I just want to point it out so that we can And next week, Emily, do you want to give a brief on what's happening next week? Yeah. So next week, we have originally planned to start an initial conversation about all of the issues that have been submitted regarding assessments and the assessment process, because we're coming up on a time where we really need to do a review of it and make some improvements to the process and seeing the amount of tickets that we have and everybody's great ideas. We want to make sure that we can do it collectively and have a good conversation around it. We are going to reach out to Justin tomorrow to confirm whether or not he's able to make tomorrow's meeting. So depending on his availability, that date might change a little bit. But the idea is that we want to start having the dialogue and then potentially move that into a working group because it's sounding like a pretty large effort. Yeah. I also just wanted to chime in about that. We intentionally did not address these issues until we had experienced doing a lot of security assessments and our goal was to complete five. I think we're not, we have at least, we have more than five in process. I'm not sure that we've actually completed them. And so for those new to the group or new in the last six months or so, this may seem like a lot of messy details unattended for a long time. It was uncomfortable to leave those things open, but we didn't want to make decisions on process changes until we had a little experience doing different ones. And it took us a while to get the process to be even a repeatable practice. So just to kind of explain why we've left this open for so long, but yes, I agree with Emily, it's high time. We did our project of the reflection and process improvements for security assessments. I'm very excited. We have gotten to this moment. Yeah. Yeah. A lot of work had gone in from Sarah and team to get an understanding, get the value for all these assessments and then get us to a stage where it's a tremendous value for a lot of people just doing self-assessment. And we've heard a lot of good comments from people in terms of going through this process and understanding their own stuff. And it actually helps the end users as well in terms of the consumption experience for the project. So people who've been involved in assessment, even peripherally, it'll be good to join next week to give your thoughts and inputs in terms of like how we can refine that or formalize the ones that we are doing what work well. Those all will be highly appreciated as we firm up the process on that. Good. So that's mostly what we had for the agenda today. Unless anyone else has anything to add, I think we can call it perhaps anything else Sarah that you want to bring up, nothing. Emily, Brandon, Justin. I'm good. All right. Yeah, I'll go for now. All right. Thanks you all. Thanks for the presentation and thanks Emily for the update on security. Thank you all.