 Brandon. Hello. How are you doing? Matthew joined. Okay, so he had himself marked into it. So I wasn't sure. Good day. Yeah. Yeah, you're right. I just hopped on right now. Was there anyone that specifically wanted to. I just wanted to make sure there was someone to take the helmet. Sure. No, go for it. Go for it. We'd love for. People. Okay. At some point I'll have to actually start doing some actual security reviews and not just. Facilitating. I just got to find more time in my schedule. That'll be amazing. It's also. Boring for the community to hear my and Brandon's boring voice all the time. Mix it up. Zoom video filters kind of needs the green screen effect. It's creating like a halation effect around your hair sort of thing. It's like the hair is moving in waves in the wind. Okay. I'll quickly pull up the. The plan meeting notes and just formulaically go through the. Usual. Yeah. So I think I did that. But I think we were playing if we have time after the review, which I'm guessing we probably will. I think right now it's on and then she can talk about. Some of the stuff that. For CSA that she did measure couple of the last time. Sure. Happy to Brandon. Thank you. Awesome. Doesn't people on. I'll just wonder two more minutes. At the same time, they'll give you a chance to put it up for today's meeting. Sit up for. It's on Diego. The passcode. Okay. Looks like we've got critical mass. Good day, everyone. Today's CNCF. Six security meeting. My name is Matt. I'm a security manager. My name is Matt. I'm a security manager. I'm a security manager. I'm a security manager. My name is Matthew. He's a part of the CNCF. Six security meeting. My name is Matthew. I'm an occasional feel. Facilitator here. I've been offline, I think for about a month and a half as we had. Other more interesting. People that handle the. Facilitation and presentations. So before we proceed, I just need to see if we can get a one or two scribes. Oh yes, link to the meeting notes. Be sure to make yourself intense. Thank you. And that's in the chat there. slash minute ticker today. All right, it looks like we've got someone volunteering for the role. Thank you, Ash. Perfect. I generally try and avoid typing while I'm talking just because it can be distracting and I won the largest keyboard award at work with my mechanical keyboard there. So I feel like I'm doing everyone's ears a favor and whatnot, not typing. So, all right, better members here. All right, so then I'm just gonna go through the tenants here and just see what updates we have here. So, Emily's appears to be interesting. Would you care to take the lead, Emily? I do so. And as far as the cognitive security light paper goes, we've opened it up for community review. JJ, Arana, and myself have, sorry, Amy. JJ, myself and Arana have gone through and done a lot to adjudicate all of the comments that we've been receiving. So if you haven't had a chance to look over the dock, please do so. Awesome, thanks, Emily. Would you be able to throw a link to find up in the chat as well, please? Or is that the one that Brandon posted? Oh, thank you. Okay, now let's just see. Do you have any check-ins from any other SIGs or technical groups? It does not appear to be the case. So I'll just go through this as they see. So, no dates, no dates. Brandon, good day. Do you care to grab the mic? Yeah, sure, thanks. So quick update on the security assessment working group. So we got together for the past two weeks. We got a lot of good feedback on what's some of the problems and ideas. We've consolidated it and put it into different categories in the mirror board, which I'm going to paste in chat. The next step for this is I'm synthesizing all this information and I'm going to create issues around each of the big topics. And then we're hoping that if you see that this is something that you're interested in working on, anyone should feel free to take the lead on any of these issues. Thanks, Brandon. OK, going through the list, let's see if we have. I don't believe I see any updates from individuals and I don't see any SIG or vendor check-ins here. I have a request. Good. Hi, I put in I started annotating people that I knew were SIG co-chairs and tech leads and a couple of people with projects. And please in your attendance, if you are maintaining of a project or work on a project that is in CNCF or another open source project or if you are responsible for your working on something with the SIG, please annotate your attendance with what you are working on so that it helps people get to know each other a little bit because our meetings have gotten fairly big, which is great. But then sometimes it's hard to know who's at the meeting. So if you could self-identify, then people might reach out to you on chat. Awesome. Thank you, sir. Realize I keep providing a thumbs up and my camera's not on, but I'll fix that next time. OK, with that said, I don't see any additional check-ins, but I do see one proposed topic, at least from the very top of the document. The question mark in TOTO, if I got that right, in TOTO incubation review. Is there anyone that would like to grab the mic on that? Yeah, I don't know if you want to take the mic on that, Brendan, or just have me go edit it. Yeah, so I think that the discussion for last week was that we would discuss what kind of since we've had the security assessment, what are some of the changes, what are you looking for, and what's the CNCF kind of asked on the recommendations. And then we can discuss some of this and kind of get a consensus of what we should, one of the coaches should end the document. Right, so to give some context, the in TOTO state security review was the first review, like for those that learn familiar with in TOTO was the first security review or self-assessment that was done on a CNCF project. This was when in TOTO was originally applying for incubation. This was about a year and a couple of months ago. Back then, the recommendation from security was to essentially allow it to get into incubation and probably have the CNCF allocate some funds to help us with some HCI researcher or HCI person, knowledgeable person to help us improve the mental models for users to better use in TOTO. Now, during the application, in TOTO pretty much felt like in the line between incubation and sandbox. So back then, it felt safer to just get into sandbox and then when some time passed in terms of like adoptions and project maturity, collaboration, and such, then to apply for incubation. And well, that all happened. But what feels to me at least in my interpretation is that the original review that was mostly focused on how do we secure a process? Has there been a thorough security analysis of the architecture of the software? How do we manage vulnerabilities? How do we onboard new people? How do we manage trust within their organization and such? Which all of those things haven't changed fundamentally. In fact, I think that the recommendation still is current. We haven't had the resources, particularly because since we got in as a sandbox project, I think the CNCF doesn't support sandbox projects like with money that much, or like as strongly as it would do for an incubation project and perhaps to fund staff to do ACI research. Now also, since we were mostly on the bar for incubation because of adoption and contributor count, I think those are the changes that we have seen on ITOTO in the last year. I don't know if this is the context that's needed for security to review the situation. Now, fast forward a year passes. I speak with Michelle Morale, who's sponsoring us for the incubation review. And part of the process is to actually, I mean a lot of things have changed since, but now we do need security to give a, we saw this project and it looks like a good project or like it has been security audit, well not audit, security self-assessment. So that is part of what we need in the due diligence document, which I shared on the Slack channel. The due diligence document I think all the way the bottom has essentially a slot for somebody on the assessment working to take a look and put the recommendation. My understanding is that, or again, this is my bias position, is that it could be as simple as just taking the old recommendation considering that essentially nothing has changed in that regard to move it forward to the new due diligence document. Now I am not comfortable doing that because there's clearly a conflict of interest there. I'm here with security, but I am also the person who's pushing for incubation. So I was hoping that somebody in the group with enough lack of conflict of interest would be comfortable just taking a look at the old recommendation. I think I should have the slides last week and just either reward it in a way that they're more comfortable with or just move it over. And I think there's a couple of people that I didn't get access and that's my bad. I should have just let it open. But yeah, if there's any questions, I would look here or any points that I missed. So Santiago, this is Vinay here. So from that perspective, I've been part of one of the assessments in the past. I'm curious as to what exactly the ask is and what kind of assistance is needed to remove that bias. So let me chime in here a little bit, I guess. So I think the context is that in the CNCF process, there is a requirement for the sick to give recommendation. And this usually comes in the form of he has a little poverty with OPA. I was like, we said, OK, we did an assessment here with the findings. The team has worked on making progress towards fixing some of these findings. The recommendation still stands. And usually that is some kind of informal sign off by a coach. Yeah, so my interpretation of this is that the sign off by the coach has kind of what creates an unbiased, like certifying the unbiased view. Got it, thank you. Yeah, and I don't think it's just a chime in. It's not just the sign up by the coach here. It's that Santiago is an active member of Six Security and could normally write up a due diligence document that a co-chair would just review and if they're aligned sign off on. However, he's the lead project maintainer. It's not really appropriate for him to write that document. And like you said, we've done most of the legwork anyhow. But so I think that there's the conflict of interest is really just Santiago's dual role as a member of Six Security and active participator and PAC participant and his role in the project. And so that's where Vinay, you could step in and do a short write up that addresses the incubation criteria and then one of the co-chairs could say, yeah, because I think we're all fairly familiar within TOTO, at least JJ and I were very active in this very first security assessment. And so either one of us is familiar with the project enough to probably give that a quick review. While I've got the mic, I did have one quick follow up question, which I don't know whether you've addressed Santiago in your documentation, but I wanted to highlight for the group I put in the chat a link to the summary slide. It's actually got all of the projects or three of the projects that have summary slides, but I moved in TOTO to the top. And one of the things that was like made it be sort of on the fence between sandbox and incubation for us was that there was just one public case study where we understood we just didn't have the, we weren't familiar enough with the CNCF process to understand how important that usage was in this process. And it was actually usage, but for security focused projects, it's a pretty high bar to get somebody to say in public that they're using them. And so in this case, I don't know if there are more public case studies, but certainly it would be appropriate to share in private what's happening. And if there are more companies that we could as a member of security could do a deep dive and learn more about who's using the projects and potentially even speak to one of them if that was a concern. And do that under confidentiality. And then report, yes, there are multiple case studies. So that's another way where a member of security could step up and participate in this due diligence that I think particularly security focused projects have a need for. That's a great point. And I'm glad to brought it up because I didn't even think about it. But I know that Michelle Norale was, and I think this is kind of understood by the TOC that now that some of the case studies can be interviews with companies. So I wonder if we can do both and have like a six security assessment person and the member of the TOC be part of the interview with the company. And that's essentially what I'm arranging now. I think that's a good idea. Should I just bring it up with Michelle maybe? See what she thinks? Yeah, I would add to Sarah's thing, there is precedence to this already in, say, contour with the SIG network that have been, like that's for project verification and validation. So I would just go ahead and do it and let FYI, Michelle. OK, sounds good. Yeah, I'll do that. Another unrelated point that I don't know if there has been a lot of conversation around it, but I feel it feels to me that security projects also have a higher, like it is more difficult for security-focused projects to have as much adoption as, say, core or like network projects. And I wonder what the take of the SIG security is of that when it comes to like recommendation. It feels to me that it is hard to contrast like all of the stars that Kubernetes has on Git repository would like, say, tough. And both of them are graduated projects, but like there's only so many people at security. Yeah. Yeah, I mean, it's. I can't, pardon, go ahead, Sarah. We have a bit of lag on my mic here. So yeah, actually maturity, like that like bullet point in the slide has been the hardest thing for the different projects to say, like, what do you even mean by this, right? And the reason that I felt that it was important to speak to and we got aligned on that being like a thing that was part of the assessment is that when you're assessing the risk of a project, how many other people have adopted it is part of that, right? And it's really not do you adopt the project or not. It's how much are you now a participant in developing the project versus you can just rely on everybody else's already checked the box. So it's and, you know, it's not that it's more that there's validation from multiple companies and different types of projects will have different types of, you know, it's qualitative. It's not quantitative. So, you know, and it doesn't have to be a written case study, right? And, you know, personally, I'm not, I don't care about GitHub stars because that's like popularity contest. It doesn't mean somebody's actually using it. So I care more about is it being used in a substantive way in the way that we can believe that this isn't just, you know, oh, this was adopted. This is a company. This is something that was made. It's been adopted by one company and it's really not going to go anywhere, right? I don't think in totals in this camp. I think, you know, we've seen a lot of traction. The quite the challenge is how do you articulate that that traction in a genuine way that's appropriate to the project in the sector? And so that's just a creative challenge. I agree. It just, I think it's not only for the total context, but I think in a sense it worries me that there's a handicap for security projects in that sense and that it's harder for them to get supported just because they have this limitation that they're somewhat niche to some extent. I don't know if this is like resonating. Well, I think that I would like security projects to be a little less niche than they are. Right, which that's part of the consequence of this like self-fulfilling like feedback loop, right? It is harder for them to get adopted, but then it is harder for them to get visibility because they are not like, they're competing with projects that naturally are a little bit more easy to adopt to say it's somehow. Perhaps it's useful framing, not to think of it as competition, neither as being proportional. But if you think of, you're talking more about public adoption than adoption because there's a confidentiality nature that people are not gonna say out loud. This is what we do for security. Yeah, I also want to bring in for Spiffy and Spire. We had similar questions and Brian Grant at the time who was in the TOC said, well, just flip it around. If any of these companies, and let's talk about in total, you were to remove their supply chain logs, would they be able to run their infrastructure? And if the answer is no, this means this is being used in a meaningful way that is critical for that business operation or for that infrastructure operation. Right, what I mean is you, like I think there's a fundamental difference between, you say you're building Kubernetes, right? And then on top of that, you're securing Kubernetes. Now, one of them predates the other just by like a natural consequence of one of them is a thing, the other one is securing the thing. Now, say that after that, there is something that is Kubernetes plus plus that is likely to get more visibility just because the target audience is everybody. Whereas a security product by itself, it is limited to people that want to provide security properties to a product. And I don't think it is a competition. I think it's just a natural consequence of like security being a subset of the whole world of computing. It would be similar to saying, well, say that both there was like Linux foundation projects like as a big umbrella and you put the Linux kernel to compete with Kubernetes. Early on, I think Kubernetes would have a harder time convincing people that it was as relevant as the Linux kernel. And even today, some people would try to make that argument. And I think this is a really good point, right? Like, and I believe that, from different TOC members and that I've talked to that this is understood, like that if it's a new project that you can just add on to your cloud native deployment, there's probably a higher bar for the quantity of customers or the profile of customer to know that like, oh, this isn't just you got three of your friends to add it on, right? Whereas if it's a security-focused project, three companies may be a huge number, right? Because it has to be, there's a high bar for the company to adopt it. And it's for something like in Toto or like OPA, it's like any of these things, right? Spiffy, these become a core part of the infrastructure, right? So I think that people understand like you don't need a large quantity. It's just that you need to show that it's more than one which could be by private disclosure and that they're different enough, right? That they're not like, oh, these two friends decided to do it at their companies, right? And it's not that I care that if anybody promotes their project through, you know, social interaction and friendship, it's more that we are making a commitment when we move something to incubation and we wanna feel like it's got some traction, whatever that means, like it's proved itself a little bit, right? So that people are relying, multiple people are relying on it and it's likely that another company could use it in the same way. Right, I fully agree. And the reason why I brought it up, not necessarily connected to Intodo, I think Intodo has everything it needs. It is more of me worrying a little bit about the security ecosystem as a whole. And I think, I don't know what the answer is because I don't think, I mean, I feel that in one hand we could say like, oh, security products then have different standards, but I don't think that's fair because I also know that observability has probably its own problems. Say runtime will have its own understanding of what an adopted project is. I also think that there's this like passive understanding as you said, Sarah, that like, a lot of people understand that security products are, have different adoption challenges. I just wanted to bring that up. And yeah, I don't think I can tell for sure. I think you were saying something different too that there's a limit by nature being like a total totally different category or a totally different market where you may only have a size of 10 total people to reach versus Kubernetes may have a thousand. Yeah, so I mean, when I add something to that conversation, so the reason why we formed sick security outside of Kubernetes as a community is precisely to acknowledge and understand that. So security is across getting concerned across multiple infrastructure and its profile and projects and adoptions are gonna look a lot different than what Kubernetes adoption is gonna look like. And I think it's been acknowledged and well understood by CNCF in general, but I think there is still to your point the lack of clarity or lack or incorrect expectations in terms of like what something should look like versus what something is and what something's usefulness of it is. So, and I don't know if you'll be able, if you'll be able to find like a magic answer that says like, okay, we do X at X percentage of Y. This makes sense kind of thing. It is just gonna have to be like this constant conversations like this and then I have some like things like assessment be a guiding force for like why this matters because people that are in security understand the context around this that will be able to assess and validate and push. And now we have this forum to basically do exactly just that. So I think it's going in the right direction to your point, no, it's very less understood, but is there a common consensus and a mechanism to push this through? I think we've started having that part of the security, but your inputs and your quote unquote evangelization around this will also help in terms of trying to move the needle on that. Right, yeah, I agree. Yeah, I think I also don't have a lot of visibility of how DLC we use things. So I assume that also without that knowledge, it's easy for me to catastrophize to some extent. Yeah, exactly. I think like what Sarah was saying, core infra projects will have this challenge. So adoption, Aradnabra has, thing there in terms of adoption of cloud providers. So that will be something that you can double click on. Arad, if you have any stories around it, that will also add to the validation of the project. JJ, one last thing is, I don't think they use one single measuring stick for all projects. And you can always reach out to the members of the TOC. Jokingly, someone has said, hey, treat the TOC as a hit list and just go one by one and talk to them. But they're actually, yeah, they will have different perspectives each. That'd be good for you to figure out what they're all talking. Talking to Michelle about something unrelated tomorrow on SMI, but happy to bridge this too. No, I think that's all good. And I don't, I think, I really appreciate Michelle's perspective. My concern was mostly on having very delineated numbers, for example, say, for the adoption. Again, I think three is a reasonable number for incubation, but at the same time, it also feels that it is a, like it is not a qualitative measure. It is a one in eight of one. All right, I'll... Thank you. That was a matter of detail. Oh, go ahead, JJ, if you had something to say. I was just going to move on to the PR for a wrap-up. No, I was just going to... Okay, so go ahead. Gotcha. All right, so going through, I don't have any issues or PRs for general discussion or any listed that require chair approval. Are there any PRs anyone would like to bring up or bring visibility to right now? If not, we'll move on to just on the floor and wrapping up. So I have one fellow co-chairs. There is an open PR that does need your review and approval. And Brandon, I think you might have already looked at it. It's the most recent one when you look at the queue. Oh, yeah. Andress, do you want to talk about that? It's all your message and chat. Yeah, it looks like you got four away. Oh, yeah. Okay. Emily, which issue are you talking about? Is this the one with changes to the governance? Yeah, it's issue 430 and PR 431. I think we have one outstanding comment that needs to be resolved. Okay, yeah, I got it. Okay, are we going to bring that one up on screen or a wrap for that ticket? Let's take it off, Lane. I think I can move it. Okay, I don't see anything else in the back for today. So I think if there's any... I think Aratna has something to share for CSA if she's in the call today. Yeah, I'm here, Brandon, how are you today? Yeah, I can share what is going on with containers and microservices at CSA and to also talk about the serverless working group that we are working on. So there's a special working group that was created about two years ago, containers and microservices under CSA where they have already published two papers. One is on challenges for operators and users of containers and microservices. And it's already published so you can search for it and download it. And the second one is best practices for microservices and application containers that is also published. Obviously there's evolution so they'll be evolving that paper and research further but those two are available as it is right now. More work to be done there. This year we started a working group as a subset of this particular work stream to work on serverless security. So I can share some slides. Repurposing slide deck from another presentation that I gave a few months ago. So basically this was a presentation given at the CSA EU summit to evangelize the working group and get some volunteers to help with the initiative and efforts. So basically the research is talking about how we have evolved in the infrastructure space. Initially we were all using hosts and servers and then we moved on to virtual machines and what are the challenges with the virtual machines and now we are on containers and Kubernetes and how more and more enterprises are looking at functions to use the functions as full application functionality. So multiple functions orchestrated to build an application functionality and why that is attractive to developers and enterprises. Obviously there's a lot to be done when you're building a container platform as you all know. The intricacies of securing a container platform as well as developers have still have work to do to package all the application and dependencies in the container and deploy them but functions remove that dependency as well. You just purely write business functions and use a functionality provided by the cloud provider to go and deploy the application functionality. Again, then definition of what is serverless. We had a lot of conversation around serverless what does serverless mean? Because there's container as a service offerings. There are container as service offerings from cloud providers which are also serverless technically even though in reality they're not serverless it's just that the functionality is obfuscated from the application owners. So hence we in this paper we are covering container as a service as well as function as a service aspects as well. And then obviously we talk about shared responsibility model for different deployment models. IAS we are all familiar. If we build our own container platform and say AWS we have to do everything including implementation of Kubernetes and orchestration engine hardening of that and also the runtime control plane as well as the data plane as well. And I have seen organizations do that as well. I've seen several people trying to deploy OpenShift in AWS for whatever reasons. And over time cloud providers have matured some of their services. So it really forces people to think why are we even doing that? Why don't we just use container as a service? But again, regulatory organizations where there are regulations they have to meet the kind of visibility and detection and control they need that kind of suffices their justification to do their own container platforms in cloud provider environments as well. And similarly function as a service there's still a stack of controls that the application developers in an enterprise will control. So this is just to visualize that. And then we are also talking about differences between FAAS and CAS. Obviously FAAS is event-driven architecture short lived like Lambda functions that have a maximum time to love 15 minutes. And more agile. They're not as portable. I mean, the whole advantage of building applications and microservices and containers is that you can put them anywhere. Unfortunately, when you use functions as a service from a provider, they are not portable to another platform. Whereas container as a service, obviously it's managed control plane but you can choose the longevity of your service that is going to live in your data plane. And it's more configurable and it's a little more portable. I wouldn't say portability has been much of a need today in the enterprises. Especially in financial services, I've seen multiple enterprises. Application teams have affinities to cloud providers. And I haven't seen them porting their applications from AWS to Azure or Google today. They just build applications in a container platform in a particular provider environment. Maybe in future that situation will come, but right now, and also some of these microservices are using past services in the backend. Imagine building some functions or applications in containers using Aurora RDS, right? How will you port that to SQL Server in Azure? Or similarly, Google databases or any analytics capabilities there. If you are utilizing, you are kind of dependent on a cloud provider. And then we are just talking about why serverless what are the advantages of that in comparison to IS and PAS. This is just a genetic slide, I guess. Architectural changes, obviously. It's a constrained developer environment when you're using personalized service. There's a orchestration of infrastructure in the application platform. Segregation of duties is still important and how to deploy them. But if you need access to the management console and the service and then how would we delegate access to services and how those services. Sorry, I hate to cut off the presenter, but I think someone has a hot mic. I think someone's typing. Could everyone just do a quick mic check there? I see one or two people are unmuted and I think they just, there we go. Sorry, please continue. No worries. So it's hard to get visibility because they're so short-lived and cloud providers today provide some detection capabilities but not to the level of detail that enterprises today need. So there's still a need for capabilities from third-party provider that need to be deployed for serverless deployments. Our friend from Palo Alto can assure that. Basically, there was a company called PureSec which was providing detection capabilities for functions and Palo Alto acquired them as part of their Prisma suite. Now they provide that. And there are several other third-party solutions there still. Service-level agreements are still uncertain because in the shared responsibility model, how a function is being codified is up to an application developer. So cloud providers are not providing any service-level agreements. None of the three major cloud providers are providing any SLAs around function as a service and their performance. Boundaries are not there anymore. There are no network choke points that exist per se. And applications are not here. They can be dynamic distributed anywhere. And integrations can be very wide. So boundaries in terms of application functions are entrusted. So a Lambda function could be talking an EMR instance or a Redshift instance and so on and so forth. In data manipulation functions, there are special concerns about integrity of the data, not just confidentiality and how do you validate the integrity of data eventually if you're using functions to update your databases or doing any data manipulation activities. So in terms of inherent weaknesses, I mean obviously no performance guarantees, limited security controls, state management is hard. Like I said, monitoring and logging is critical but a lot of it depends on the developer what they want to log as well. And that is true for any application. So in terms of maturity, there are still organizations who have banned functions or use our functions for certain types of activities. For example, in financial services because of the regulatory environment, we do not allow today data manipulation activities using functions because of all the concerns that I just mentioned. And also auditability, regardless of what service provider we use, we have to be able to provide audit logs and trails of all the financial transactions to our regulators. So that kind of limits some of the capabilities we can leverage. And then tooling maturity, still it's evolving in the market. And then we have some pictures which we are still kind of fine tuning. This is just a random picture showing that all the security controls and integrations that we need to build in authentication, authorization, vulnerability management, even triggers, et cetera, for function as a service. And then in container as a service, we just kind of depicting the additional controls that our tenant is responsible for when it comes to container as a service control plane as well as the data plane. Even in the control plane, cloud providers do provide some flexibility for tenants to be able to go configure some of the configurations there, what images to use, et cetera. So in terms of security challenges, I mean, we've had a lot of discussions around threat model around this. And we have since this presentation, we have evolved our threat model in the paper quite a bit. And I'm happy to share the link with all of you so you can read and apply it on it as well and provide input. Basically misconfigurations. These are distributed applications. Imagine updating stock prices on a website, right? All the functions that will go into that and the criticality of the data and inputs and validation and confidentiality around that until the final price is published. So being distributed, there are a lot of policy enforcement challenges and configuration challenges as well. And testing, right? Obviously need an environment where you can test it before you actually implement it in production. Improper authentication authorizations are a big concern. Concerned basically because of our entrusted boundaries and functions can go and talk to a lot of other services. And so appropriate authentication authorization and implementation that is critical. Policy violations as we've talked, the function is written inaccurately there are misconfigurations of the deployment of the function and there'll be challenges in policy enforcement and the policy violations will be detected but the function is just so short-lived that you may not even be able to fix it in the time. Code vulnerabilities still can happen. I mean, this is application functionality. Even triggers can be the injections, SQL injections as well as even data injections that can affect the capabilities of a function what it can execute to. Runtime issues obviously because of code injections and denial of service can happen. Malicious traffic could impact the resources that you're utilizing in the function may not be able to execute just because the resources finished before the function could execute the full functionality detection. We've talked about the numerous challenges in that space just getting logs from different components that a function is using and aggregating them and then doing detection on them is kind of challenging. And in an event-driven orchestrated system failure detection can be after the fact like after the event has failed you might detect it. So imagine five different functions running and one of them failing all the subsequent functions will fail as well. And then we were just talking about threats, right? These threats you're all familiar with related to applications and they all apply to functions as a service as well. And after the threat model and detailed threats discussion we are working on security controls that we need to deploy in a secure function as a service deployment. Not just function as a service but also container as a service. So there are two parts to that section, that chapter we're gonna discuss all the controls required and with an architecture diagram showing how all the threats we have talked about are going to be mitigated for a fast implementation as well as container as a service implementation. And then also talking a little bit about future detection and where this is headed as cloud providers improve their capabilities or to mitigate some of these threats and provide more visibility to talents. So this is in short, what we are working on in CSS as part of the serverless working group. Thank you for listening. Are there any questions? Thank you for your presentation. Yeah, that was great. All right, now these slides, would you be able to make them available as well? Yeah, I'm happy to ship this to you. This is public data. Okay, great. Not regulated. Yeah, I like this list of the threats that you're talking about. It kind of speaks a lot of what we're doing in the community. Right. Thank you so much for those slides. I had two questions and probably the first one is a little dumb and I apologize if I missed it. But can you talk a little bit more about the CSA and what is it? Sure, Cloud Security Alliance actually was accepted in 2007 and I've been part of CSS since then when all the cloud providers were just coming out with initial services. AWS was really small. So they do a lot of work in building best practices for cloud in general. And that is IaaS, SaaS and they have slowly expanded into internet of things and mobile security. And it's a standard body that does work around security as well. A complementary to CNCF. And I've been part of CSA since then. I was part of the first CSA and best practices guide that came out in 2008 timeframe. Now they also provide certifications to cloud providers. I mean, not everybody can get a FedRAMP certification, right? If you know FedRAMP, it's quite complicated to get a FedRAMP certification. So a lot of small time SaaS providers and past providers, they go to CSA for getting their services certified from a security controls perspective. And they have a cloud controls metrics as well which is mapped to NIST 800-53. But at the same time, it's written in a different flavor. It's also mapped to ISO standards. But again, the due diligence that goes into FedRAMP and validation of controls of providers is slightly more deep and in-depth compared to CSA audits and assessments. But still it does provide some level of assurance of a provider's security posture and framework that they are using operational best practices as well. But there's a lot of research available. I'm happy to share the link of CSA research and guidance that they've published so far. There are a lot of working groups where you can participate and volunteer and share your knowledge as well. And you're welcome to join the serverless working group as well, since you are all working on the cloud native stuff. And serverless is cloud native, so. Thank you so much. I had a follow-up question. I was mostly curious. You had this taxonomy in the end of threats and you put insecure repositories as a separate thing as supply chain compromises. Do you know why you decided to separate them or? That is basically where you're getting your code. If you're integrating any third party libraries, you're maybe pointing to insecure libraries GitHub's, you know, you three codes where you're downloading software from. That's why to me, at least conceptually, and again, this is just my mental model. Not everybody has the same, but it felt that the supply chain compromises includes insecure repositories as well. Yeah. Like I said, these slides are both quickly for the presentation. No, it's not a criticism. I was just curious to know. It's always good to hear the various perspectives. And sometimes it's like, oh, there's a fundamental difference there. You're right. That is covered in third party. Cool. Thank you so much. I really enjoyed the presentation. Some compromise to Node.js. Right. Please continue. No, I was just saying that I really enjoyed it. Thank you. I was just gonna say Node.js, I think, is recently in the news. That's an example of both of those compromised repos and supply chains. I think it's the first time we do. Yeah, that's a good point. Node.js is perfect for saying like, look at how scary things can get if you take care of it. I'm just trying to fashion Node.js. It just happens to be such a big repository. We're doing analysis of their supply chain dependency graph to understand what we call the supply chain dependencies. And it's millions and millions of packages. And many of them, like, there's a couple of very big offenders of theirs, they make a package for the color red, and then they make a package for ANSI colors, and then they make a package for coloring things. So you have these very long tales of packages that can be compromised, and all of them essentially inject code. So it is a very interesting ecosystem, to say the least. I just wanna say a message to you. I have a quick question on that presentation. You mentioned, you touched on the FedRAM. And I'm curious, I think you were suggesting probably that the CSA certification could be a precursor or a step towards going towards the FedRAM. Can you elaborate on that one and how if there is any official link up on that as to getting the FedRAM certification through the CSA, or is this totally decoupled and just an exercise in getting that? So honestly, a FedRAM certification is only given by the government at ATO, right? But the controls that CSA validates as part of the CCM are mapped to FedRAM and nest 800-53 as well. I know nest works closely with CSA as well. So there's interdependencies there and they share data between each other, all the controls, et cetera. But what I'm saying is FedRAM audit process is quite stringent. I talked to Microsoft Azure team and they have auditors sitting on their site 24-7365 days. So you can imagine the number of resources Microsoft has to spend to continually keep their FedRAM certification. It's not practical for a small-time SaaS provider to do that, right? It's expensive in terms of resources, in terms of effort that they have to put in place. So if I'm a small application provider that is now providing it as a software as a service, I don't have time and money and resources to have FedRAM auditors sitting and enforcing all those nest 800-53 controls 24-7365 days. And I may not even have resources to secure everything as per nest 800-53. I mean, even large enterprises are having challenges just meeting the nest 800-53 controls. So we can't expect that our small-time SaaS providers or medium-sized enterprises as well. So they use CCM, the CSA audit results to show that their practices are still secure even if they are not up to the level of FedRAM certification. So is it... Let me check myself, clear? Yeah, are those audits then from the CSA recognized by the FedRAM as the acceptable? No, FedRAM doesn't accept anything other than FedRAM, right? Okay. Everybody can speak to that. So yeah, I was just wondering whether there is any advantage or leverage one could draw by doing this. Well, they're actually working towards the FedRAM, getting the FedRAM certification. But the CSA audit works for other organizations, right? I look for a financial services organization for every SaaS solution. I would validate whether they have FedRAM or they have ISO or they have CSA, either of the three and that gives me some level of assurance of their security practices. And then I can do more due diligence based on my assessment from their audit findings if I need to do that, right? So all baseline control, at least you get some sense off. I'm just going to step in. We've got about two minutes on the clock before hard stop. And I just want to offer, if anyone wants to continue this discussion, either if you want to post your contact details in chat or a link to a message in Slack if anyone wants to continue. I was just going to save the very last minute and ask if there are any attendees today that would like to quickly introduce themselves before we wrap up. All right, so then I'll just conclude with Emily put a note here in the chat by all means hop onto the CNCS Slack during the SIG Security Analyst. And if anyone would like to continue this discussion there. And thank you for that. So it looks like we've got all the pieces needed to continue this offline. So anyone to stay on the call, please feel free to, but at least at this moment we're officially ending the meeting. Have a great day, everyone, and stay healthy. Thank you very much. Have a good day. Thank you. Thanks, Matt.