 Hi everyone, thanks for coming today. I'm gonna share with you a little bit more about tech security, what we're doing, the different efforts that we have, what we've been working on, all the cool stuff that we have. And I'm gonna talk a little bit more about how we can get involved, what are some of the security challenges that we're facing today as a community and as a larger industry. My name is Brandon. I am a co-chair for tech security. My co-speaker, Andrew, is unfortunately, something came up and you can't be here today. So I'm gonna go quickly through the slides. Since this is a smaller group, I kind of want to try and do a little bit more engagement. So if you wanna ask questions, focus down on specific areas, we can do that. So just so quickly, who, what, when, where, why, kind of things. So I'm gonna start with, who are we? We are the technical advisory group for the CNCF TOC for security and our task here is really to aid the TOC in terms of helping strengthen the security posture of CNCF projects. So we do both reviewing our projects, kind of helping the TOC understand certain security projects. We also help identify gaps in the ecosystem and try and we write papers, do education, and bring people together and start fostering those collaborations. We basically do everything cloud native. Cloud native security is a work with many meanings because most of the things today are cloud native. So cloud native security does take up a lot of space there's a lot for us to like dig through and talk about. We wanna help in the end develop this mean security requirements and we also wanna be able to kind of get to where we wanna be in terms of auditing compliance. So the group generally works on GitHub. There's a GitHub link there. We are made out of professionals, enthusiasts, people in the community. We like the fresh perspective that everyone brings to the table. So this is our leadership team. So if you see anyone of fellow community members, say hi, myself there with my fellow co-chairs Andrew Martin and Aratna. We have Techleads, Andrews, Ash and Pushka. And we have our newly nominated Techleads, Michael Lieberman, Marina Moore and Raghashree. We are sort of our associate facilitator Matthew and Raghashree is also our community manager. And of course we have our co-chair emeritus, Emily Fox, who is now our TOC liaison. So what do we do? There are two parts that go into what we do. One of them is like creating and breaking things, right? This is where we say, okay, what can we do to help the community? What can we do to kind of like push the boundary of security for organizations and that is creating and breaking. And another aspect of that is also, things we've done with the white paper. So we just launched earlier this week, the V2 white paper, supply chain, secure factory reference architecture and a bunch of all these. So I'm gonna just dive deeper into a couple of these. If you have questions, we can talk about it later. So the first one that I wanted to highlight is the V2 white paper. This was being worked on by the community in the past six months. It's a revision to of the original white paper that we launched, I think about two years ago now. And what we've done is we've really updated it with some of the newer topics. We also added some interesting ideas in which people were struggling to understand some of the concepts. We provided a framework to them. So for example, one of the things that was added to this paper is the mapping to the SSDF. So if you've heard of the NIS secure software development framework, that was a document that was written by NIS partially to kind of provide some guidance in terms of if in the US we have the executive order on security and the SSDF is there to kind of fulfill like some guidance in the area. So as part of that, we do some mapping to say that, okay, if you want to fulfill which parts of the white paper fulfill which particular requirements or controls in the mapping. So that's one of that that's very useful. We have a whole new section on ransomware. You know, we talk about what is ransomware. We talk about ransom cloud. You know, how do you protect yourself against ransomware? And also we have a new section on EU compliance. So a lot of cool things in the new V2 of white paper. I'll check it out. As usual, these things are living documents. So if you read the paper and you see something that's not in there, something that you're really, really interested in, it's like, okay, we need to cover, I don't know, like micro VNs or something like that. You know, we need to cover confidential computing deeper. We can add it to the white paper. Whenever we get kind of like a backlog of topics that we see come up, we then decide, okay, you know, here's the, now is the time to do V3. As V2 launches, also a couple of cool things that have happened is we have now audio book version available of the V1. So if you'd like to just put on something in the modeling, just listen to it, we have audio book that's available. We also have translations of the original white paper in both simplified Chinese and Brazilian Portuguese. And these are kind of important pieces of work that the community has done because, you know, for example, in Portugal, you can't use the document unless it's written in Portuguese. So that's why we had like members of community to the translation. We have a Spanish translation in progress that's being currently led by Carol, one of our contributors. We are still looking for more contributors there. So if you're interested in kind of helping to translate the white paper, you know, all the issue numbers on the slide, so just click in, put your notes there, say that you wanna help out. Another thing that we've been dealing a lot with is supply chain security, right? So back a couple, like a year, a year and a half ago, we first published the best practices white paper which talked about, okay, what should you do in order to get a secure supply chain? Your Ryan and company here have done a great talk during the security call and talking about that's how they used it and that's how they mapped it into 3M and kind of like pushed it out throughout the organization. So the second step of this is that we were working, now it's in progress, it's actually done. So I'm gonna show you what we have is the Secure Software Reference Architecture Paper. So this was just launched 30 minutes ago. So yeah, we had a lot of things churning in the pipeline, so it's gonna, it's a very eventful week. So the Secure Software Factory Paper talks about, it provides a reference architecture, it tells you what are the aspects of a Secure Software Factory, how should they work together? It talks about it in terms of concepts. We don't really dive deep into, oh, this is what technology, you should use and blah, blah, blah, because these things are gonna change. So the idea is we provided a framework, we've provided the language so that people can communicate with each other, so that people can reason about what exactly is this project doing, right? Because a lot of people have projects that say, I solve supply chain security, right? But essentially they are solving part of supply chain security. So it provides a way to communicate about that. We have a couple of authors co-authors here in the room, contributors. So if you're gonna stick it around, we can chat with that. As a side note, there is a project that was built with the reference architecture in mind called SSF, which will be renamed to Fresca. But so I have it linked here. This is actual code implementation using different projects, which provide the open SSF, but all the concepts are all tied from the secure software factory paper. Another quick thing to mention, we have a NIST controls mapping. This was phase one that's now completed and it was launched earlier this week as well. Basically maps everything in the white paper to the NIST controls. So if you're looking to target certain NIST controls in your products or implementation, you can kind of look at this and say, okay, this is how I can do it. We do have a phase two that's coming up and part of being cloud-native and cloud-native security is that we want to have automation. We've understood that we can't do security manually. And so the next step of this is to create container-based compliance. And so one thing that we're looking at is OSCO. And the way we get that is to first figure out what are the evidence that we have to gather, how do we actually audit these controls automatically? And so the phase two of this is gonna come up soon. It's gonna talk about how can we automate all these things and hopefully phase three further along will be implementing that framework. We also have a serverless white paper that's currently in RSC. Talks a little bit about serverless more, focus on the function side, what are the unique security considerations that you have to deal with in terms of access control and management. Also talks a little bit about what goes on in terms of your segregation or your risk transfer into your cloud provider. This is RSC, I think I forgot to put the link in here, but I will update the sites. Cool, so what else do we do besides writing papers? So we engage with other communities within the CNCF as well as outside the CNCF. So we talk to the Kubernetes Policy Working Group, we have six security, we have a cross members, one of the TL's Push Guy is a member of both. Cloud Security Alliance, we talk to them pretty often as well as OpenSSF, SELFSA as regards to the supply chain and reference architecture. Another thing we do is we interact with other CNCF projects. So if you are a CNCF project and you're thinking, okay, I need to do security, like I have a security project and I kind of want to kind of reach into the community, find end users, get some feedback on what should I do, how should I make security better? This is something that we do. We do something called security pals where we have a one-on-community member kind of guide the project along, like how do I create a self-assessment while the security considerations have to think about. And we have self-assessment and joint reviews which are analysis of the security posture of the project. So this usually comes in the project pipeline, although we encourage projects to just come up and do it. You get a very, very well fleshed out document and of it that says if you're interested in using this project and you are thinking about security, this is all you have to know. Track model, what are the considerations you need and really it decreases the barrier entry for groups to just pick out the project and use them. So this was just what I talked about. We have two projects that are coming up for this. We're looking for a security power for flux multi-tenancy. So for those that are not familiar, flux is a multi-tenant Kubernetes multi-custer deployment system. And so one of the things they're doing in graduation is they have this new multi-tenancy proposal. And part of that is we wanna be able to make sure that that's good. So we are looking for security power for that. We also have the captain drawing review which will be coming up soon as well. So nothing that the group has been working on is an event called Global Security Voluntary Summit. I'm pitching an event for another conference. This is gonna be in June next month and Austin together with the Open Source Security Summit. And what we are thinking about here is how do we solve, we always talk about Lock for J, Lock for Shell, all dirty cow, am I affected by this vulnerability? How do I manage this vulnerability? Or even how do I report this vulnerability? How do I get all the data sources and how do I make sense out of that? This is where we see efforts like effects. Like OSB coming out. So this event hopes to gather the community together, talk about it. We have governments involved, certs involved, and boundary-based databases involved. So that's gonna be a good forum. And also, we're looking to future topics like how do you do analysis now? Assuming that I have the graph all together of all the information. Is there any analysis that I can do, differential analysis to find certain classes of bugs or try and pick them out before they happen? Two efforts that are currently going on with supply chain security now, post-reference architecture. The first is obviously S-Bombs is a very hard topic now, but there's some gaps in terms of like, what does S-Bombs mean in certain contexts, right? When you have a piece of, you have a package or you have a software, S-Bombs is pretty well-defined, right? You're defining what's in that package or what's in that binary. But when you talk about cloud-native, when you talk about microservices, you talk about software as a service, infrastructure as a service, what does it mean to have an S-Bombs, right? If I'm hosting a service on a software as a service, it's my S-Bombs, the Python code that runs on it. Is it the container that it runs in? Is it the VM that it's running in, the Kubernetes cluster that it's running in, bad metal machine that it's running in? So you can see kind of like, there is that kind of open questions where we, as a community, we have to come together and provide some guidance for this, right? I think there's gonna be trade-offs, there's probably gonna be your practical guidance that we can provide there. Another part of this is the S-Bombs community and supply chain community kind of have been going on in their own tracks, and we wanna tie a lot of this together because generation of S-Bombs and the use of S-Bombs, right? We talk about generation of S-Bombs, and great, we have them, but do I know they're from the correct place or do they all generate that accurately, or can I trust this S-Bombs? And it's the same with can I trust this binary? If I'm using the S-Bombs as a basis to make my security decisions, I have to trust the S-Bombs as much as I trust the binary. So that's where you see a lot of overlaps with the supply chain practices, and that's where you see kind of cross-pollination there. Also, there's a lot of big open questions in the industry like distribution of S-Bombs, which have not really been talked that much about. Another thing that we're looking to do is to apply the best practices and the reference architecture to CNCF projects, right? So the idea there is to run an instance of the reference architecture that's the project for OpenSSF, and now pick a few CNCF projects to say, okay, we're gonna try to bootstrap you into this. We're gonna say, okay, we're gonna figure out how this works, how we can get there. And hopefully, based on those proof of concepts, try and scale up and kind of make this a thing that CNCF can do. We need to put money into security and open-source security, but no one knows how to use the money. Or we don't know how to efficiently do it. So that's the idea, and I think hopefully, also can influence OpenSSF alpha or mega project where we say, okay, look, we've provided some ideas that we have been able to execute in the CNCF context. How can we take this and bring it to other projects that may not have the kind of same kind of practices or the same kind of tooling and pipelines? Cool, so if any of these interests you that we have multiple avenues that can get in contact with us, we have a mailing list, like say everything that we do is GitHub, everything is issues, anything that we talk about goes into issues. We do meet every week on Wednesday. Right now is 10 a.m. UTC minus seven. I think that's probably about 7 p.m. this time, but I think what we are thinking about doing as well is we're thinking about starting up at EU meetings, so we may kind of bounce between those two. If you're interested in hosting one of these tech meetings, please do contact us as well. We're looking for people that really, you know, we are looking for people that want to drive the community here as well, because we can set up a meeting, but really it is the people that are there, that are on the ground, that really provide the context for the work that's done. We have a roadmap as well as we are on Twitter, so you can follow us, so you get news on the different papers that we are publishing, the different efforts that are going on, so you can get involved. And yeah, that's all we have for today. Thank you. So we don't have any questions online, but if you have any questions in the room, I'll run over, raise your hand, I'll run over with the microphone. So I saw a presentation yesterday talking about the different types of S-bombs and maybe some relational links between them and how they could come with packages of evidence and other things. So I noticed you had a line that says, give guidance on how people should be using, consuming these S-bombs, because we don't want to just generate them and have people go, oh, thanks, and check a box, right? Yeah. They should be machine-readable and other things. Any efforts along those lines that you're working on? So from the perspective of the CNCF, we are trying to start that up. There are other efforts that are going around in the community, so there is the S-bombs coalition, which is part of the cybersecurity group that's providing some guidance. We are going to have a workshop, so we have at the risk of self-promoting, we have this, no, it's not this one. So this is part of the coalition group. We just published a policy paper a week ago. Can't seem to find it now, but we published a policy paper about a week or two ago. So this talks about, okay, as a, this is more for like NIST OMB to provide guidance so high-level, what are the problems that we have to work on? Too many standards, distribution is a problem. What does S-bomb mean? I think it was also kind of like three of the main takeaways. And then we have kind of these specific technical problems, which is storage and distribution of S-bombs, using the S-bombs to answer the security question, implementation of S-bombs throughout the ecosystem, as well as like a clarity of what S-bombs mean. And SPX, for example, we have a, so within the SPX community, we have a built profile group, we have a defects group. So we are looking at kind of like these different pockets of documents and how they link together. But I think eventually what we're seeing in SPX 3.0 is like how to bring all these things together. So yeah, I think the S-bomb coalition is a good group from the how to consume this part of it. It is also the VEX working group, which I think is a great one to be at. That's really, how do I take S-bomb plus CV data plus VEX data equals policy engine and action. So they're looking at the action part of it, right? So VEX talks about affected, not affected. Not affected means zero, nothing to do. And if you're affected, they provide guidance on like what you have to do or how are you affected. So that really ties in to your consumption question, right? How do we eventually get to, how do we take action on these things? Yeah. Any other questions? Hi, I was just wondering if there'd been any activity in tag security and considering the use of trusted execution environments and the impacts on whatever, maybe this is something we can talk more about later, but I was just curious if there'd been anything so far. Yeah, yeah, so we talked about this and I remember like about, this is about two years ago, you know, Ava was coming in and talking about it. And obviously I know the work that you all do with the confidential containers in my previous life. So we have a couple of interesting use cases. I think one of them obviously is a regulatory use cases. I think we have a very interesting set of use cases with identity. I think the Spire community is kind of looking at that. Initially, they're looking at SGX, how do they securely provide identity into the microservice, right? I think that's a very big use case for us. I think the isolation use cases we are also looking at in supply chain. So this is something that we talked about in the supply chain reference architecture paper. But we didn't include that much in this one because the technology wasn't really there yet. So we couldn't really talk about it that much. So I think there are valid use cases. I think it'll be nice. I know that you all have done a lot of great work. I think it'll be nice to share the community. We can also help talk about some use cases, maybe write a blog post or something about. Yeah, some use cases and then kind of spread it within the community, get some more feedback and maybe get more users around that. Yeah. That sounds good. I mean, we're keen from the confidential containers side to clarify our use cases, but also to relate what we're exploring back to the documents and the work from the tag security. So I can follow up. Thanks. Go both ways. Hi, Prenton, a quick question from my side. It's also a bit in the contrast of confidential containers. Do you have ideas use cases to use HSMs? Okay. For security modules, specifically local, for security modules at scale to improve security, key management, or go even into, let me say, secure keys and rep keys. I didn't quite get all of that. HSMs, scaling key management. Exactly. Local HSMs, not specifically talking about network attached to the HSMs, but specifically locally available to, for example, for containers exclusively. Is this kind of like, you have a amount of HSM and you use PKCS 11? For example, for payment crate transactions and key management. Yeah. I think we do talk about HSMs in the cloud native security file paper. I don't think we dive deep into the different deployment models of HSM, although I think that's interesting, right? Because essentially you're creating a trap model based on the authorization of the key and who is access to it, right? So I think there'll be interesting thing to discuss. And I think we can add more guidance. And I don't know whether there would be, I guess there will be specific recommendations on like when do you want a local HSM versus a remote HSM? And it's also like, you know, the security usability leave as well, right? Yeah, awesome. Okay, thank you. Any other questions? Brandon, can you describe to everybody what it's like being in a leadership position within tag security? You see a lot of things. No, being a leader in tag security is very great. You get to talk with a lot of people. You get to see different perspectives of security. You obviously get to work with a great community. There is also like, especially in open source, you learn a lot about how open source ecosystems work. Like how do you get contributors? How do you keep contributors? What are the factors that matter? And it kind of like, for me, it's benefited me in a way that like, the way I operate in open source is a lot more intentional. Like I understand, okay, these are what matters in open source community. This is how we get there. Here are all the factors. And so like, as like, you know, initially from contributors to project leads to tag leads and to now chat, you kind of like see the different levels of it. I feel like it's a very good experience and also great networking. And I know the security reviews are extra critical within the CNCF because it helps products prepare for those code audits. And I can see that there's not a lot of security experts within the ecosystem. What is the biggest challenge when performing a security review? Is it finding people to assist or is it the technical part of that review? It is exactly the point. Like finding people to assist with the security reviews is something that has been difficult, right? We already have tried to scale down. We noticed that people that come into open source that want to work on a specific project attention span is like three to four weeks. So we've scaled down like the review to two weeks. It's really bite-sized, it's really simple. And we are looking for people and whether you're super deep, a security review can be going deep into, okay, let's take a look at what parcels they're using to kind of let's look at how they're handling security events, how they, do they have a CICG pipeline, what are they generating, the S-Bombs and things like that. And so I think it's a good gateway project because they're involved in the tech. I know that was the first project I worked on. This was initially we were starting out these reviews for like Intel and things like that. I will encourage everyone, it's a very low commitment way to like get into the tech, learn about a new project that you're interested in. And that's what I did, right? I needed to work on Spire for one of my work projects. So I was like, okay, I'll do the Spire review. And that way you get, you know, you learn about the project, you get direct access to maintainers, right? And then you make friends with them, right? You create the connections there. So yeah, I will encourage everyone to do that. I would say, you know, put it on one of the security review issues or, you know, you can contact any of the leadership directly and say that I'm interested in doing XYZ, you know, there may not be something right now, but when we, when something comes up, we can, we can talk to you and you'll get you involved in what you want to do. Yeah, let me show you how our usual processes, you know. If you wanna, if you wanna, if you are interested in doing something, you just hit new issue. Or if you want to do a presentation, new issue, get started, fill in all the details, proposal, suggestion, if you want to do something to group, you know, you can go to here, look at all the assessments, go to this, scroll down, command, and then you're set. Yeah, cool, yeah. So, any more questions? And I don't think we have any more online, so I think that's it for questions. Thank you. Thanks everyone.