Oh, look at this. You just ran your first scan. Um, yeah. I completely forgot about this over here. Let's see, dependent bot, we went through that. CodeQL. Scans code, adds patterns. Basically, yeah, they just... Oh, it's open source, so you can go look at those patterns if you want. Stackhawk. I think we covered a lot of this stuff. You know, one of the things I didn't talk about was our integrations. So we integrate with a whole bunch of different stuff, so you can have, including like things like Jira, so you can create issues directly in Stackhawk for finding. So if you imagine that SQL vulnerability, if you have the Jira integration hooked up, you can go in there and say, oh, you know what? Send to Jira, and then it will create the Jira ticket for you and tie it back. That's super helpful. We also have these sort of more notification based stuff where you can do send me a Slack every time a scan fails, that kind of thing. Same with Teams. We have a generic web hook, so we can send out events as things happen in our scanner, if you wanna get the payload, if you wanna load them in, if you wanna automatically drop things into some sort of, you know, database so you can keep track of these things on your own, you can do that. I think that was kinda it for the, oh, there's sneak preview custom variables. So this is a new feature that we are releasing like now, I think, or next week, maybe, not sure. No, it's available, but we're gonna do an official launch next week with lots of resources and just materials to help people get up and running with custom variables for GraphQL API's. So what this does is it allows you to put in custom variables in a specific format. So if you have an email field here, you can say, you know what, I wanna inject some fake data in the form of an email, and it will create like a random email-looking string and use that as part of that, like you saw, where did the cat etsy password, it will start putting those kinds of things in those places. So it's really, really great for basically running through your data checks, cause I mean I've written lots of code where you sort of assume it's gonna be an email and then you handle one pattern, but then there's some other thing that comes in you hadn't thought of. So what this does is it lets you inject those in, so you can do it, there's a whole range of them. So there's like emails, phones, UUID, all that kind of stuff. And it will look like pretty, it's realistic looking data that will come in. It really stretches the application. It's great to have. Topher, correct me if I'm wrong, you can supply your own variables too if you wanna test something like a password reset? And yeah, so that's another really useful option. Yep, so yeah, so right above that is the, if you don't wanna use the Faker library, if you don't want, if you know that there's a string that you wanna look for, like let's say you had a password or there's some string that if you had a bug where you know it caused a specific problem and you wanna force that string, you can do that here. So you can specify these custom variables and then it will use those as part of the tests. So a couple of different options here, you can either specify hard-coded strings, like if you know that there's a problem string or like I said, if it's a password, if you really need that, or if you just wanna generate a smart fake-looking data, you can do that as well. And we talked a little bit about the GraphQL configuration, there's a lot of options here. So our docs are trying to be pretty thorough. This workshop is really just about setting up those three types of security scanners. And with those three, I think, yeah, so for this application, now we have three different types of security scanning enabled. We've got the software composition analysis using Dependabot, tells us about dependencies. We've got the SAST, which will go look at the source code for patterns that looks suspicious, and it will alert you to those. And then we have DAST using StackHawk, which ran against the actual running live application and found some issues in there. So we know that those are actual issues and we got to go look at them and triage them, either fix them or say, you know what, we're okay with that for now. But with those three things, we've just added some pretty good tooling around our vulnerable application here, our example application. Going forward, hopefully you can use this to implement this in your own GraphQL service. And then the idea is, you know, once these are in place, when you get a new one, the first time you write it, you're gonna get a bunch of stuff, you go through and you sort of triage and sort of fix stuff and say, no, I don't care about that library or whatever, or I'm going to fix that. And then going forward, whenever you get a new one on any commit, then you know that, oh, hey, that commit changed something and I have to go figure out what the change was and why did this trigger this alert? But, you know, that's a lot better than it going through the whole process and then getting deployed and then, you know, you get an email that says, hey, we found this problem out in your production server. We definitely don't want to do that. So we want to do it as close to the commit as possible. And so I think, let's see next steps. Yeah, so now you basically translate kind of what we did into your environment. So if you're not using GitHub actions, whatever kind of CI CD provider you are using, we StackHawk supports a lot of them.