 Hello, everyone. I'm Emily Fox. For those of you that are familiar with me, you probably see me pop up in a lot of different open source communities in addition to the Cloud Native Computing Foundation. Today, though, I'm going to talk to you a little bit about the history behind this event. For those of you that have been in the Cloud Native Security for a while now, you'll know this event is very near and dear to me. It's basically my baby. I love this event because it was my first big project that I volunteered to assist with when I joined the open source community, and it was also kind of the first time I had heard of the Security Technical Advisory Group. However, at the time, they were called the Special Interest Group for Security. It was 2019. I was in Barcelona attending KubeCon Cloud Native Con Europe, and it was there that I was introduced to Cloud Native Security and this group. They were evaluating the security posture of several Cloud Native projects I was researching at the time for a project that I was working on. It was there that I attended a talk from Justin Cormack on project security reviews. In addition to kindly answering all of my barrage of questions, both on camera and off camera, he mentioned to me that I should probably check out this group. They were still young in the Cloud Native space. The foundation was still kind of growing and ramping up. They were looking to break new ground and develop new practices to allow us to apply traditional security practices into Cloud Native technology stacks and really drive what mattered in this growing community space. And as always, open source is always looking for contributors, and technical advisory groups and special interest groups are no exception. So you'll hear me refer to them as the security tag or security throughout this talk, but ultimately it's the same group of fabulous people. So I started lurking in their meetings, just like dialing into the Zoom sessions, trying to understand a little bit more about what they were talking about, what they're trying to accomplish, reading their docs, asking clarifying questions to make sure that I understood the direction that this group was heading in. They had a huge ask to fulfill their mission and their charter, but everyone was welcoming, enthusiastic, encouraging, and flexible in understanding like we're still trying to figure a lot of this stuff out. But ultimately what we needed to do is figure out how do we prevent unauthorized access for Cloud Native applications and workloads in a way that makes sense for all of the adopters in addition to the maintainers of these projects. And as long as our work aligned underneath of the three primary focus areas of the charter, we were unstoppable. The charter was set up so that the tag could fill the gap in security guidance, instruction, and tooling, and we'll just generally provide information that wasn't there at the time. Organizations were leveraging heritage and checklist security requirements completely ignorant of all the possibilities that Cloud Native could provide from a security perspective. So we set out to define how to protect workloads to ensure that they're still usable, where security is not a noticeable hindrance to the user or the engineer's workflow. We also needed to figure out how can we take the existing security control bodies and apply those principles to establish a common understanding and corresponding tooling to help developers really meet those security requirements. But perhaps the hardest and most complex yet that we're still trying to solve is how do we break down the complexity in audit? Because auditors really need to have an understanding of how Cloud Native architectures are supposed to be developed, built, and operated in a secure manner. Oh, and do that for every single domain because Kubernetes is just one of the many facets of Cloud Native security. And you can make an argument that due to the natural complexity that Kubernetes has, it is its own domain of expertise. The stickers on this slide are just a couple of the domains that we still need to do explore at the time, and they are their own domain expertise areas. Oh, and we hadn't, we couldn't really fit all of those into the KubeCon Cloud NativeCon security track and talk about Kubernetes at the same time. There just wasn't enough space. And many of these domains hadn't been approached from a security perspective in 2019. We needed an avenue and a place to explore and kind of drive content along these areas to inform adopters and maintainers about how we should be doing security in these specific areas. We needed that avenue to build up security in Cloud Native because it is more than just Kubernetes. It is a multi-objective, multi-constrained problem space with a lot of different domains, it spans the entire SDLC, and whatever comes next, we have to be prepared for it. So Michael Ducey, one of our community members at the time, who he had previously been running some local DevOps days and was really into the open space scene, he filed issue number 209 in June of 2019 to propose a one-day event that went beyond the current security track at KubeCon. There were 14 of us that jumped on board for that issue and we started planning. We used the GitHub issue to plan all of our meeting notes and a Trello board to figure out how the heck do you run a conference and how the heck do you figure out what an open space schedule should look like for a security conference. We had a lot of amazing submissions and we were able to pull together an amazing day of talks as well as a full open space schedule to really drive a lot of discussions. Ian Coldwater and Duffy Cooley started our day off as a throwback to Kubernetes, talking about Kubernetes defaults and how do we move forward in that space. If you look back at the first open space schedule in the first SIG security day talks, you'll find a lot of the same topics that we talked about in 2019 are still being talked about here today. But the difference is that now that we know more, we can share a lot of those learnings with our peers and colleagues and build on top of each other's learnings. And you'll also find out we talked about software supply chain security attacks before it was cool. We talked about defaults, we talked about compliance and machine learning, and it was a lot to cover in just a single day event. It was a huge success. The program committee and myself and the other colleagues were stoked to hold another one and make it bigger, make it better. So in 2020, we held one for Europe because we wanted to ensure that the European audiences security concerns and care about were similar or at least addressed within this conference. And then later that year, because that one was a success, we did the same thing for North America in 2020. What we did, though, is after that initial event, we performed a retrospective to really understand going from day one to the second event and the third event to get community members feedback. We had a lot of interest from folks. The Twitter chatter was strong, excellent discussions by community members in the open space arena, and then we got a little hint that people wanted something a little bit more hands-on. They wanted workshops, they wanted tutorials, they wanted something to allow them to take the theory of cloud-native security and apply it into practice. So that's what we decided to do with that North America. We held a CTF and it was fabulous. If you were here yesterday, you heard Andy and Andres talk about how we executed those CTFs and how our community members responded. And that's kind of been the thing with a lot of this, is partnering with new community members on what we can do to make this a positive experience for everyone, making sure that they have those lessons learned and that they can take them back with them to their companies and organizations with the correct skills to uplift their overall security, showing how attackers can compromise containers in a fun and engaging way. And it's not just the attendees that get a lot of value from this event. Individuals that run these events and participate in the open source community, they're leveling up their skills. They're able to identify gaps and challenges being experienced by adopters through discussions with their colleagues and peers in hallway tracks or in open space talks. They're also able to strategically leverage some of that event content to drive attendees like you to talk to each other, figure out what's going on in API security, how did you all solve this most recent vulnerability? What are you doing to improve your software supply chain and what is the evolution of that look like for your company over the past four or five years? Because ultimately we're all trying to do the same thing, uplift security. And we've been able to increase industry's attention to security and cloud native over these past four years because and we're going to continue doing it because there was and continues to be a gap. And while that gap is significantly smaller, we're still growing this space and learning and uncovering new areas to explore. You can see from the metrics on this slide, we've doubled the amount of security projects and products in the cloud native computing foundation's landscape. We've increased the amount of security reviews on projects that we had. We even had a major review process revision and we're talking about doing another one to really drive more value to maintainers as well as adopters. And it's because of the first security day and all the security days that came after involving into this conference that allowed us to provide a place for security practitioners to exchange, learn in a way that was not addressed by the previous security conferences. This conference is an avenue to share your experience and to learn from others. I would like to see it continue to expand beyond just cloud native security into open source security because both of these are complementary fields. And as we see more maturity in cloud native security tools, projects, guides, documentation and resources, we're seeing them applied outside of cloud native architectures. This event has grown because of attendees like you and those that came before you, but it was started because of the cloud native security community and in particular the volunteers and passionate members of the security technical advisory group who have driven more content from their work into this conference. And this is the work that moves cloud native security forward, connecting members, solving problems, establishing best practices and sharing what we've learned. I want you all to take this opportunity to network with your peers, talk about some of the challenges you're experiencing and how you've solved them as a throwback to the original open space and collaborative nature that this conference started from. Thank you.