 So this is the security dashboard. So let's say that the security team wants to see the latest status of the master branch of a project or a project manager wants to assess where the project stands overall from a security standpoint. The dashboard can be found in the project menu up here. Project menu of the project side navigation here. It provides a summary of vulnerabilities and other out of policy indications found in the project from all of the security tests run on each merge request. Here on the dashboard, that includes SAS, DAS, container and dependency scanning. It doesn't yet include license management. That's kind of an open issue of whether or not license management should be part of the security dashboard or not. So if you've got some thoughts on that, feel free to provide some feedback here. Now it's an interactive dashboard. So the security pro can look at vulnerabilities where the developer may have been unsure whether to dismiss it or create an issue. So here, let's drill into one. You can choose to dismiss the vulnerability or create a new issue right from here. Now I can also drill down and see where the actual code is that has the issue. And this is really gonna help with collaboration between the application security person and the developer. It's sort of the single source of truth. Everybody's looking at the same thing, right? Now, the developer might use the dashboard, but it's really intended more for the security person. And the individual developer is probably going to use the security report that's in the merge request. So let me pop over to the merge request view and have a look at what the developer would see. So this is for a specific branch that they're working on. And one thing to note here in terms of workflow, you could add a security person as an approver if you wanted. Our philosophy is that security vulnerabilities should not block the build. That may not be everybody's policy and direction. And so you've got the flexibility here to add a security prover if you wanted to. Now, excuse me, here you can see that 63 new vulnerabilities are detected. Now this is on a branch, so you would expect that the developer is gonna see a lot of vulnerabilities and deal with them before it gets to the master. That's kind of the intent here. So I can see my SAS, my DAS, dependency, container scanning and license management here from that individual merge request view. And again, once again, I can drill down and as a developer I can choose to dismiss this vulnerability or create an issue. So you've kind of got two lines of defense or process here, right? So the individual developer is gonna look at the vulnerabilities in their merge requests and deal with what they can. Now, because security is not always easy, you've got the dashboard where the security professional can look at things that are getting merged into the main branch and look at that and decide if there's others that need to be dismissed or escalated through an issue. So with GitLab, you really can scan all your code every time. We make it seamless for the developer and you don't have to buy a bunch of tools and integrate them and everybody can get on the same page. So this is how you can scale application security for DevOps feed. It really is a different approach. We solve the problem not by throwing more tools at it but making it a natural part of the developer's workflow. All these tests are automated with every merge request. So you no longer need to choose between risk, cost and agility and because it's one tool for the software development lifecycle, you can use it on every code commit. I know I sound like I'm harping, but it really is different because you can run it on everything, automatically every time.