 Hello, everyone. Yes, my name is Emily Fox. I'm a security engineer at Apple. And today, I'm going to talk to you all about the cloud native chasm. So we've heard a lot already about security in cloud native communities. And guess what? I'm a security engineer. That's what I'm going to talk about. So let's get started. It's a jungle out there. Whenever we try to go somewhere new, like starting a cloud native project, for instance, there's not always a path before us. We need someone to lead the way. What we need is a guide. It could be a mentor. It could be one of our colleagues. Another project, perhaps even ourselves. These guides, they navigate the path. But our guides, ourselves, we're probably stumbling through the cloud native landscape because it's super complex and massive. And we're terrified because we don't know what it is exactly that we're doing. But we are so excited at this idea that we have. What our cloud native project can actually bring to the community and what kind of impact it can have. But the path is going to be rough. Like I said, it's a jungle out there. But we've got vulnerabilities jumping out at us from our code bases and our dependencies. We have whole tribes of adopters that are demanding features and changes of our projects. And half of our exploration crew, you know what? They're probably tied up behind a desk somewhere trying to fix a bug that's blocking our next release. Then there's the maintainers. These people work really hard. And you know what? They're dragging everyone forward with them. They're fighting off somebody trying to take over their GitHub account. And they're still trying to graduate before KubeCon, cloud native, cloud North America. You see, not everyone and not every project is going to cross the chasm the same way. There is a lot of work that needs to be done and it's going to be project specific. The bigger your project's impact or our project's impact, the bigger the impact on the ecosystem is going to be. Because no matter what, the larger the vulnerabilities we inherit or create will affect the world because no one and no project is without its flaws. It could be that we miss something. The jungle is in the way. We got swept up in all the excitement, but now it's before us. It's staring us in the face, waiting, silent, demanding for a decision. So what is this mountain of work that I'm talking about? What is this inevitable decision that's before us? In 2018 at OSCON, Josh Brescher set it best. It's no secret, if you read the news, everything is on fire. And even security people don't add security in on day one. This is shocking, right? Security person saying we don't add it in on day one. But when we think about it, we first need to focus on what is our project? What is it going to do? And how is it going to do it? Only then can we consider the security mechanisms that are going to be appropriate for it, for its particular environment, and how we're going to deploy it. From there, we can consider the kind of bridge that we're going to build. Is it going to have guardrails? Are we going to do security faults? Those kinds of things. In the past 20 years, technology has made a huge shift and so has security. Distribution, ephemerality, immutability, these are all natural extensions that are building on top of the fundamentals of our core security principles from decades past. Confidentiality, integrity, and availability. But it's how we apply these principles and controls in security ecosystems, like cloud native, and it's going to vary from project to project to project to deployment over time. Just like with software development, we cannot set these things and just forget them. What was critical 20 years ago for security is quite literally a thing of the past. Our risk tolerances, our implementation, our technology usage, these all change. This means we are required to iterate, refine, refresh, and reevaluate our past decisions. The worst mindset that we can have as we move forward in this space is that we've always done it this way, and that is why everything is on fire. Daniel Miesler said, periodically step back, ask yourself what success looks like, and ask yourself if you're taking a direct enough path to get there. That bridge that we started to build, is it still the right one? We need to think about who our potential adopters are. What are our intentions with the project? What kind of attacks are we going to be facing? Threats are not the same decade after decade or even year after year. We're in a new era of security where the pace of vulnerability exploitation and weaponization is on the rise. Throughout this conference, you'll hear there's a hyper focus on security, especially on supply chain security. Sometimes though, when industry focuses on a particular area, it can lead to misconceptions, it can lead to cargo cults, buzz wording, and pile on publicity for whatever that project is. It can create whole new classes of issues from overloading leverage points with gateways and excessive security tooling that we actually don't need. It may not actually solve the root problem either. It could just be treating a symptom. And from there, it can start creating whole new classes of security problems that we never knew existed. And then I'm gonna be back here on this stage in 20 years, giving the same talk. We need to perform independent due diligence against our own environments, our projects, and our deployments. Only then are we gonna know where we're going and how we're going to get there. It's important that we try to, that we need to think about things and understand what we're trying to achieve with security controls, because a bridge to nowhere is useless. Security controls are not going to apply everywhere. Adding them in for the sake of checking a box will just leave you with frustrated engineers and a broken project. Security mechanisms, controls, processes, these things need to be specific to your environment, your application, your data, your users, and how it's going to be used. We need to think about not only how these projects can be abused by an adversary, but also how it can be misused by your adopters. Every project has at least one function or operation that will make or break your project's ability to protect data. Tag it and track it. Tracking these areas of your project allows you to identify those security features and checkpoints where they exist so that when you're introducing changes into your project, you know what that impact is going to look like. And building a secure high-impact project is a lot of work. It requires help. That does not mean if I show up to your working group meetings, Emily Fox is a security engineer. She gets all the security issues. Don't do that. It's not going to work. But you, in your capacity as a project maintainer or contributor, you have the same rhetoric and engineering mindset that's required to design a secure solution. You can apply that same principle, that analysis to whatever your security problem is. Are you thinking about doing multi-tenancy, for instance? How have others accomplished this in this space? What security mechanisms did they use? Have they had any issues with it? Do they actually have true tenant isolation without traversal or lateral movement within that environment? Use cases that have been designed for that particular multi-tenant instance, are they similar to ours or are they different? We will never actually know what our adopters are doing. As maintainers, developers and contributors to projects, we have our own perceptions of how our project should work and the expected interactions from someone or some service. But regardless, at some point, it's going to be used in a way that we didn't intend for. It can be malicious, it can be opportune, it can be unintended. It could be that we will be exposed to changing uses and new use cases of the project that we have never considered before. These same events could reveal an inherent weakness or where our security assumptions are no longer entirely valid. It could be a headache or a dumpster fire. We need to plan for this. We need to think about every function, every process, and every trigger as a toddler. We need to ensure that we're putting in gates, guards, checking in with them, guidance, and establishing structure to make sure that our project is moving forward safely. And all of us are responsible for these things. Our goal is to reduce the impact when every design flaw and missing input validation is found, because inevitably, they will be. What seemed like a non-impactful design decision several years ago is probably going to introduce a problem for us that we realized wasn't a side effect until now and could make an existing problem even worse. It could cause a denial of service by pulling in a newly weaponized dependency that expel traits and then deletes your adopter's data. Security through obscurity is often a common fallback in these situations, but it doesn't work for everyone. Building your projects and moving an idea to a commodity requires public discussion and clearly documented decisions and justifications. Well-defined roadmaps with clear outcomes show potential adopters and contributors the care and consideration that you have poured into your project and provide an avenue for future health and ways of engagement so you or us as maintainers aren't doing all of the work all the time, multiple times over. Precedence and provenance are what's key here. It could be that we chose to include an embedded web server within our product, but not all of our adopters are going to need it. So we purposely require it to be explicitly enabled. This is a secure by default design decision that prevents your customers from arbitrarily serving or receiving HTTP calls. The CNCF has a variety of projects, working groups, technical advisory groups, materials. All of these things are available to adopters, projects, contributors. We've heard about some of them here today. In the cloud native security community specifically, cloud native eight security controls catalog, security reviews and joint assessments and self assessment are just starting points for you to join in and learn more about how to secure your project. Participate in a review. Volunteer within the tag security or Kubernetes SIG security. These are all excellent ways that you can be introduced to the security concepts to help reframe your thinking, create more secure structure and build that bridge to cross the chasm. Thank you for your time.