 Good morning, everyone. I'm Dave. I work in AWS, and I work on the Open Search Security team. Today, I want to talk about things that we're doing to bring transparency to security processes that it's kind of tricky, something that is not super easy to talk about. So I'm going to give it a try. For those of you who don't know Open Search, Open Search is an analytics suite. It's open source, of course. It's Apache 2.0, and it's derived from Elasticsearch and Kibana. So to get some context to where we started in 2021, we found ourselves in a very tricky situation. So on the one hand, we had a very established, mature code base, very complex code base. But on the other hand, we were a little bit like a newborn open source project. And there were a lot of the things that we did security-wise in AWS, internal processes like pentesting, secure reviews, aggressive vulnerability remediation, and all those things didn't quite have a counterpart for the open source project. So as we set out to put all those in the open, some of the challenges that we kept in mind where, first, we needed to be mindful of the diverse install base. When we do things internally, we know more or less how we deploy things, how we run things. And in terms of security, it gives us some context for whether things are dangerous, not as dangerous. But we really need to be mindful that people are very creative. People deploy these in many different ways. So when we look at security, we really need to consider the population of the install base that is very diverse. The other thing that we need to think about, too, is we have an ecosystem of partners and vendors that really depend on us doing a very good job at this. So definitely, the stakes are super high, and we need to be very careful. Then there's also the trade-offs between speed and correctness. We have a security issue. We want to rush to go fix it and just put the fix out there as soon as possible. But in doing so, we're also disclosing the issue. So we really want to make sure that we've got things right and we are very confident in the fix before we just put things out there. So there's always that tension there. And then finally, because we have this bias for openness, everything is in the open, GitHub, Slack, Zoom, all these meetings, there's a great opportunity for someone to just freely and openly talk about something that ends up being a security issue. So how do we do that? Well, the first thing that we put in place was we put a security vulnerability disclosure process. We did this with the community, so we created a GitHub issue and invited conversation to get it to a good place. And well, this is basically a handbook for how do we do from report to disclosure and everything in between to make sure that we're respectful and responsible in the way that we treat security issues. One important addition to this was the pre-disclosure list. So we have a list of partners that people can apply for and they get notified in advance when we're gonna publish one of the security issues so they can better get ready for them. And then the other thing that we did was opening up already existing processes that we were doing in AWS and just being more transparent about the things that we were doing already. One example of that is the internal security reviews. When we do a feature, we put it through extensive testing. One of the benefits of doing that publicly in the open and just tell people that that's what's happening, first, it gives us confidence, it gives the community confidence that we are actually raising the bar for what we put out there in terms of security. And then the other thing is it also gives us the transparency for maybe sometimes when features don't quite make it to a given version because the security review hasn't completed, it gives us better mechanisms to involve the community in that discussion too. And now finally, we committed publicly to follow OpenSSF's best practices for vulnerability remediation, but we commit to every release that we put out there, we remediate medium and above vulnerabilities that are aging. So what have we seen so far? We've seen this process exercise, we published our first CVEs. We also got incoming reports from the community, so it truly takes a village to raise the security bar. And then this is hot off the press, but on Monday yesterday, there was a report from an independent security audit that where the reporters said that they were impressed with the state of the code base, especially with such a large code base and how little they were able to find, fingers crossed. So join us, how can you join us first? If you see something, say something. So we have this security intake process, please send us reports if you find something. If you know how to fix them, help us fix them. We can collaborate in private works. And then now finally, these are just by the first two security processes, we have more coming, so please engage with us on GitHub and help us make open search better for everyone. Thank you. I'm done. Thank you.