 By now, we've had a lot of great sessions about observability, but I want to take the next five minutes to talk to you about security. I want to explain how you can use tools and frameworks for observability in order to improve your application security and maybe to reveal another aspect of observability. So let's start. My name is Yosef Arbiv. I'm an engineering group leader at Outshift, which is a part of Cisco. My group was previously working on open telemetry and now we are a part of a bigger team that works on Panoptika. Panoptika is our solution for cloud native application security and as a part of this solution, we have an API security solution. So what are the basics features in API security? The most basic feature that all of our customers are talking about and asking us for is just to list all of their APIs. Many companies and organizations do not know what are their exposed APIs. So the first thing that we need to secure your APIs is to know what are the APIs. So this is the first thing that everyone is asking for. The second thing is to compare our APIs in reality to the documentation. Many times there are differences between what's documented and what's happening in real life. And this can be an indication for problems and security issues. And the third thing is to let our customers know when their systems are under attack. We want to detect when your APIs are being targeted, when attack is taking place and to let our customers know about it. So in order to deliver all of these features, we created API Clarity. API Clarity is an open source project that does all of this by the following. We install a trace generator plugin in the API Gateway inside the customer's Kubernetes cluster. This plugin generates traces from the actual API calls and sends those traces to a controller. The controller is also running inside the customer's cluster. This controller gets the traces from the plugin, analyzes traces, creates security insights and sends those insights to the backend and then the customer can view it using the UI. So when we first built API Clarity, open telemetry wasn't that popular and it didn't have all of the functionality that we needed to create those security insights. So we decided to create our own plugins with our own trace format and we needed to develop a plugin for each Gateway that we wanted to support. As the time went by, we understood that this was a mistake. Open telemetry became more popular and many Gateways support open telemetry out of the box. So in order to support all of those Gateways, we decided that we need to support open telemetry but we didn't want it to rewrite all of our project. So we created an open telemetry collector that converts open telemetry traces to our own proprietary format. In this way, we were able to support basic functionality for a lot of Gateways without having to write a plugin for each one of them. But this allowed us only basic support because open telemetry still doesn't collect the body of the request and in order to create the more advanced security insight such that includes data on the parameters and the content of the parameters of the request, we needed the data from the body of the request. So in order to do that, we extended open telemetry, collected the body in the open telemetry extension and added the body of the request to the trace. And what's even more interesting on this was that for some Gateways, open telemetry extensions can be done within the Gateways configuration. And that means that we can activate open telemetry traces and extend those traces to collect the body of the request without having to install anything external on the customer's Gateway. And this allows us to deliver great value to our customers with very simple onboarding process. So to wrap things up, I want to focus on three key takeaways from this talk. The first thing is that it is so great to see that open telemetry becomes really popular with framework developers and it makes the life of all of us much, much easier. The second thing is that we need body in our traces. We've known it from our experience in observability. Now we've seen it in security as well. And as I go on, I see more and more people that support it so I really hope that in the future we'll be able to see this support natively in open telemetry. And the last thing is that although security and observability are not the same thing, they have a lot to do with each other. And when we are building tools and frameworks for observability and when we make our systems more observable, we also make them more secure. So thank you very much for listening. And I will really appreciate it if you can take a moment to scan this QR code and provide me some feedback on this talk. Thank you very much.