Security Testing Automation for Developers on Every Build

Speaker 1: Hey. Hey, Ma. Can you hear me?

Speaker 2: Can you hear me?

Speaker 1: Yes. Now I can hear you. Hi. And in.

Speaker 2: Can you allow me also to video?

Speaker 1: You should be able to do it. Let me promote you to co-host. So now you have the same rights as I do.

Speaker 2: All right. Nice. Okay. Same. Thank you very much. And I think that Oliver should be joining in in a minute. Let me just.

Speaker 1: Ensure. Okay.

Speaker 2: We’re starting in 7 minutes, right?

Speaker 1: Correct. Yeah. Okay. Hey, Ali.

Speaker 2: Let me promote.

Speaker 1: You. Okay. Okay.

Speaker 2: Hayley And I’ll also change you to co-host as well. I can’t, Daria, Because you’re a host.

Speaker 1: Yeah.

Speaker 2: Hayley. Do you have your mute? Do you have video now?

Speaker 1: Yes.

Speaker 2: Okay. Good. Nice.

Speaker 1: Very good.

Speaker 2: Hello. How are you?

Speaker 1: Doing well. How are you?

Speaker 2: Yeah, good, thank you.

Speaker 1: Right.

Speaker 2: Hopefully we’re going to have. Are there people joining now? Can they hear us or.

Speaker 1: Yeah, they can.

Speaker 2: Okay.

Speaker 1: Hello, everyone.

Speaker 2: You have Thomas, Eric, now only Thomas. I wish to have some time.

Speaker 1: Usually there is some time for our. Thomas is super early. Good for.

Speaker 2: You.

Speaker 1: Thomas, I hope you don’t mind, but I’m going to go and make a coffee, if that’s okay. I’m not. I’m not as prepared as I should have been, but I’m just going to go make a quick coffee, if that’s okay. I’ll be back in 3 minutes.

Speaker 2: Absolutely.

Speaker 1: Now, if Thomas has said it’s no problem, that’s what counts. Okay?

Speaker 2: It.

Speaker 1: Daria. That’s the discord link for the nation, right?

Speaker 2: Yep. For the workshop chat, if you want to use it. Usually it’s quite convenient to use it if you have any links repos to share so that they stay there forever and people can return to them because the chat here or it will be saved in the recording. But it’s not as convenient to find the links, the needed materials. Mm hmm.

Speaker 1: Now, that makes sense.

Speaker 2: Hmm. Hi, folks. For those who joined will be starting in a few minutes. So don’t worry that it’s silent here.

Speaker 1: Okay. I am back.

Speaker 2: When it does this green share in the meantime. Yeah. Looks good.

Speaker 1: Yeah. Okay, good.

Speaker 2: Will there be any live coding?

Speaker 1: Um. Yes and no.

Speaker 2: There will be live repository configuration and YAML coding.

Speaker 1: I was just asking because of sometimes the fonts are a little too small in that scene, but usually participants let the speakers know if it’s can be hardly seen. That makes sense. Just bear that in mind. Yeah. So, Zachary, where are you joining us from? Let us know. And let us know if you can hear us well. Lot.

Speaker 2: Well, for those of you waiting, let’s just wait Maybe one or two more minutes just to let people join. And we can we can get cracking. Okay. Right. It’s been 3 minutes. We’ve had some others come in, which is great. You’re absolutely right. I forgot to turn my my video on. So here I am. I don’t know if that’s made it better for you or ruined the show. Oh, that’s a nice background. So thank you to those for joining this workshop on security testing automation for developers on every build. And obviously with this being GraphQL Galaxy, we’re going to have a specific focus on GraphQL. But I suppose for the purpose of this introduction that I’ll start off with and I will actually go through an agenda, So let’s perhaps not ruin that, but my name is Oli Morozov, VP here at News Religion. And we’re joined today by Barb, as you can see, who’s our CTO and co founder. So if you want to say hello, Barb, but hi everyone. There you go. So you can differentiate our voices at the very least. So what are we going to be looking at today? So we’re going to do a very, very brief answer. What we want to do is get very hands on. We want to get technical. We want to jump straight into his hands on technical workshop with you. But let’s just set the scene at the very least. So I’ll give a very, very brief intro into why security testing is important. What is Dev First Dast and the new religion platform and then we’ll just jump straight into into the hands on workshop. So if you do have any questions by the way, do please feel free to put them either in the chat or one thing that I will be keeping an eye on.

Speaker 1: More.

Speaker 2: Is going to be our discord. And there is a specific GraphQL Galaxy Channel, which I’ve just realized is misspelt. So I’m going to change that because I didn’t spelt a graph wrong. But GraphQL let me save changes and I will just I will just add the link already in there if you haven’t already got it. So we have one. There is the graph shall discord with Git Nation. You can use that. Of course we’ll be monitoring that or indeed the one on the new religion discord. If you look in the chat you should be able to see it there. What else? For those of you that are going to be playing along with us, and I hope that’s going to be all of you, our docs is always going to be a really good resource for you moving forward. If you haven’t already done so, do go to APK your religion dot com forward slash sign up and sign up either now or you can go through that with bar. So Bar and I will be taking you through the whole process step by step. Whenever we do these sorts of workshops. Most people are a few steps ahead of us, but they always have questions and talking about questions, do please put them on the chat. Don’t be shy. I don’t bite. No, no question is silly or stupid in any way. We want to have a conversation. It’s quite a nice small group actually here, so let’s keep the conversation flowing. We’re here to be helpful as much as we can, whether that’s the test your GraphQL schemas or indeed any form of OPSEC testing bar is a fountain of knowledge. So please do feel free to use that I’m not a fountain of knowledge, so don’t try and use me for that. But I will be monitoring the chat and obviously we’ll be able to to answer any questions you have. So just a quick about new religion. For those of you that don’t know, we’ve been going for a few years now. We’ve got a global team of I think it’s about 70 people now or maybe more. We’re always there’s every day there’s a new starter, but very, very passionate about OPSEC, particularly putting security testing into the hands of developers. So developer first or developer focused dast Dynamic application security testing to scan your web apps, your APIs, whether that’s wrist soap or of course GraphQL. Otherwise it be a bit silly today server side mobile applications and of course their corresponding APIs. And we’re all about putting security testing, putting dast into the hands of developers. You probably would have heard of DevOps Devsecops shift left. You have other tools that are in the developers hands. Dast is typically something that’s carried out later on in the process. So we’re all about putting dust into the hands of developers building scatter the scan. Surface from the very first unit test, enabling developers to start or to be able to use dust in an effective way and to maximize adoption seamlessly integrated across your CI CD pipelines. But one of the fundamental pillars of our technology is no false positives. So you’re confident and can start trusting the reports and the output that our engine is giving. And unlike other other dust engines or dust scanners, you don’t need to go through that manual validation. You get clear actionable results as each vulnerability is detected with remediation guidelines. So you can so you can start to remediate accordingly or at the very least prioritize, because prioritization is often probably one of the biggest issues that people have when it comes down to security testing. A select customer list. We’re going to go through the names. But what I do want to say is that whether you’re a startup or whether you’re an enterprise organization with 1000 developers, people are moving away from their traditional desk tools to new religion. Many might be using fantastic open source technology as well. And but actually want to couple it with with Oz or a moving completely away from the traditional desk tools to start using to start using NeuraLegion. And this is for a multiple of different reasons which we perhaps will get onto. And like I said, I’m not going to be talking for too long about this. We want to start getting hands on as soon as as soon as possible. Why is security testing so important? Well, applications are and continue to be the weakest link. Right. But actually, it’s the rise in APIs that’s really resulting in an exponentially growing threat model and attack surface. And actually, when you look at GraphQL in particular. The majority of the tools out there do not provide support for this. Right. So when it comes down to security testing, you may find that a lot of this is going to be happening in a manual and a manual way. Actually, what we want to do is to give you the ability to test your GraphQL schemas as early and as often as possible. Developers aren’t stopping security con either. This is where everyone talks about the need for security testing to keep up with your rapid release cycles, to keep up with the speed of DevOps, to keep up and maintain that speed, to keep up with your sicced. And traditional dust tools are built for security professionals, but actually those silos need to be broken down now. Security testing needs to be put into the hands of developer, which is that shift left methodology. Um, and dust predominantly has been the missing part of that shift. Left side of things. Security must match developer speed with integration at all phases, pushing pre-release testing earlier in the SDLC. Any questions so far, By the way, don’t be shy. Feel free to interrupt me as often as you like. So there are different security testing out there. So this is really to set the scene. You may be familiar with your software composition analysis like snake or white sauce with the log log for J. That’s happened recently. This is where, you know, these things are really going to come into into the fold. They’re checking your dependencies, checking your libraries, making sure they’re all up to date and patched. You may be using static analysis SAS tools Sonic Cube GitHub Code Shell has one built in, for example, where a dynamic application security testing tool, a dev first test tool that looks at the built compiled application, looking at it from the outside in performing what is theoretically an ethical hack against it. But looking at it from the same perspective as a an ethical hacker, looking at it in its almost like three dimensional form with all the microservices and APIs working together, whereas static analysis is looking at things in a relatively one dimensional space, looking at the source code, but not really understanding how each of the different parts or microservices are working together and functioning together as a built compiled application. And that’s really what you want to be able to test. This is what you may be spending a lot of money on periodic annual penetration tests. Your death toll is going to be looking at the application layer in an automated in an automated way bar. I don’t know if I’ve missed anything there or if there’s anything you want to add. You can just say no and I can move on.

Speaker 1: Sounds pretty good. You do your job well. Good job.

Speaker 2: Only I need to. I need to start getting paid more, I think. Right. The I get promoted to a panelist before and now I’m doing my job co host. Anyway, let’s just look at very, very briefly because we’re not here to sell and pitch. We’re just we’re here to go into into a nice workshop. So why do security trust us and why does the developers love us? So I will need you in a second because I want you to delve into things in a bit more bar. But there are a number of things that we looked at with security testing, looked at other DAS tools that have been around for 20 years plus. But there are lots of pain points, lots of limitations, particularly when it comes down to security testing for developers with these modern DevOps methodologies. CI CD, one of which is coverage, and this really is very pertinent to GraphQL. So you want to be able to test your web apps, your internal apps, the APIs, whether they’re GraphQL rests. So for example, microservices with these modern technologies, modern modern architecture, sorry of application need to be handled effectively. Authentication is a really, really big aspect and Bar will go through the multiple different authentication mechanisms that we can that we can handle. But what you really need is multiple ways of discovering the attack surface. So you’ll see it, we’ll go through it. We support crawler where we crawl the application, detect the entry points, extract the parameters and build the attack surface. We support half files, HTTP archive files which you may be producing already with your automation. So if you’re using things like Selenium or Cypress IO for your functional scripts, these can all be exported as a half file and we can use these to then also scan your applications. The benefit of this is actually very scoped defined because what’s ever included, whatever is included in the HA file. Let’s say if you interacted with a search field or a specific entry form that will define the scope of the test and this will enable you to run tests for many very few minutes instead of several hours. And perhaps more pertinent to this call, full support for swagger or open API and postman collection schemas. So we can we can get on to that usability and adoption. We will show you the multiple different scan optimizations that are built into our technology. Having been to meetups pretty much across the globe on DevOps, on developer focused ones, obviously with a focus on security testing, even penetration testing, even penetration testing meetups, they all have the same problem with dust. They’re hard to use, they’re hard to configure. They’ve got far too much noise. The results just are not trustworthy at all. The tools get disabled or it needs a lot of manual validation to understand whether these issues are really here. So we’ll show you the in-built scan optimizations that we have within our technology, really removing the heavy lifting from you, the developer. If you are a developer. And in fact, it’d be great for the few people that are online just to put in the chat. Are you a developer? Use an architect. You are you in security? Let’s try and understand.

Speaker 1: Your.

Speaker 2: Who we got here.

Speaker 1: Who we got here. Understand your your thought process and we can we can tailor little pieces to specific people, but more importantly, built for developers, right? How you can configure the scans directly from the CLI, use the multiple command lists that we have in our in our docs to hook, to call to schedule, to retest. Really controlling the scans via code individually or indeed using a global YAML configuration file. But the no false positives really is one of our fundamental pillars of security love all the hyperbolic, all the edge cases. We want to know everything. We want to go through engine logs all day and all night and try and find everything. This is not sustainable, scalable for development. This is not scalable for developers. To match your rapid release cycles. Developers want fact. You want to be able to run a very quick test that’s going to last a few minutes against your or against your application using your schema. For example, with GraphQL, you want to understand if the if the issues actually there and then you want to be able to prioritize, which ones are we going to fix now? Which ones are we going to accept the risk and perhaps which ones are we going to do later? But more importantly, that’s what can we fix now so that we’re pushing secure product into production? You can’t do this with other DAS tools. Because they produce too many false positives. You need that manual validation. And going back to that customer list, if you’re a startup, you haven’t got the time or the inclination to start finding which ones. Am I real True positives. If you’re a massive enterprise with 1000 developers, it gets even worse. You’ve got 1000 developers pushing new commits into production every single day. The amount of technical debt as a cause of the security debt and the manual validation requirements really is insurmountable in many times. So we’ve our engine automatically validates every issue and you can start trusting the results. And this means that you can start to action. These now chip away at your technical debt, but more importantly, whatever you test, you know, is going to be there. And it’s real seamlessly integrated across your pipeline. And we can go through the integrations speed again, we don’t slow developers down short, small incremental tests that run for minutes, not days. Adjusting the scans scope with each test or each commit. And in terms of payloads, we scan for the regular sort of technical rs10 the might of 25, but we’re also the only automated tool that can test for and detect business logic tests, and we’ll go through that as well. This alludes to the fact that our engine that was built off the back of an AI guided, fuzzing technology actually understands the responses we’re getting back. We have natural language processing. We’re looking at the responses we’re getting back. We can understand what we’re looking at, and we can use this to manipulate our tests to carry out logic based attacks. It’s all about reducing your reliance on manual testing, shoving that straight into your pipeline. Let’s try and find as much as we can before they go to production. So you’re producing secure product as early and often as possible and then generating the right test for the right targets. This all goes around our scan optimizations, which will which will get on to during the workshop. Are there any questions so far, by the way, I haven’t even been looking at Discord, so apologies for that. I did say I would be. Any questions for me yet? Nope. Okay, no problem. I can see we’ve had a few of you joining the Discord, which is great. Do go to do go to events and then GraphQL Galaxy 2021. And let’s use that channel for any questions. Unless you’re using the.

Speaker 2: Okay.

Speaker 1: Are you honestly using the get the get one then feel free to use that as well. I’ll flick between the two. So this is what it should look like. Traditionally, dast has been used at stages four and five. We’re really about doing it as early as possible. PUSH commits to GitHub, Trigger the PSI or the PSI even run a scan build will pass or fail. How many? How many of your builds are failing because of false positives? Is that going to happen with with us? Open a ticket automatically. You can’t sometimes do that because you can’t automatically open a ticket because you don’t know if it’s an actual issue. Well, actually, with new religion, you can because, you know, it’s a validated issue and then you can start to prioritize. And we have integrations with Slack and a whole host of others. But if there are no questions, which it appears there are not, let’s let’s get cracking with the workshop. Are you ready?

Speaker 2: Let’s do it.

Speaker 1: Okay, great. One thing I do want to know from everyone that’s joined is. If you’re joining in with us, I really want to know who is signing in. Who’s playing along. So I’m just going to stop sharing now. By the way, it’s going to be over to you. All right. Who’s playing along? Who’s. Yeah. Who’s playing along, basically. So. Don’t be shy. Like I said, we’re here to have an open conversation and discussion and of course, to help you out as we’re going along. So you’ll feel free to do feel free to.

Speaker 2: To let us know what’s.

Speaker 1: Going on and let us know. Yeah.

Speaker 2: So before we go in, there are three things that we’re going to work with today. One is, of course, our app.neuralegion.com. All you will if you didn’t didn’t do it yet, you will now send it again in the chat and also in discord. So it will be very obvious where you need to go. We’re going to work with the NeuraLegion  example actions repository specifically. And I will note that again, the GraphQL branch, which is why we’re here today, right, working with GraphQL. And we’re going to be testing and running against the then vulnerable GraphQL application, which for the time of this workshop will leave in vigor new religion dot com. Don’t worry, it doesn’t matter where it is. It’s already set up and configured in the repository. But just so you know what we’re going to scan, this is, of course, just an open and open project on GitHub. You can just get it from the EFF, the Invulnerable GraphQL application and spin your own for testing and just, you know, learning about GraphQL vulnerabilities. The first thing we’re going to do is to sign up for a free account in your religion. You can do it either by going to the main application and in the login just go down. You don’t you don’t have an account. So click. Try it for free, or you can just go directly to the sign up part, which will of course just bring you here directly. Because, I don’t know, maybe you like shortcuts. You can sign up with your GitHub, you can sign up with your Google. I’m going to use the sign up with your email. Now, you know a few things You need to put your full name. You need to full name. You see full name. And I don’t actually put my full name. That’s a problem. So full name email. Mm hmm. So I’m putting my email here. Password, Please use super secure the awesome password.

Speaker 1: And, uh. Mm hmm. Mm hmm.

Speaker 2: All right. And click on Create a Free account.

Speaker 1: Woo hoo!

Speaker 2: If you’re here, you should have gotten a free account. Basically, you should have an email waiting for you in your inbox with the Please verify your email. And you can just click on the button, which will open the page, allowing you to login, basically taking you back to that login. But now you actually do have an account.

Speaker 1: Is everyone good with that? We all signed up, signed in, etc..

Speaker 2: Let us know if at any point you want me to take it a bit slower. If you want me to go over some kind of step again. Anything. We are here. Meanwhile, I’m just going to click on the sign in and I’ll give you a moment to catch up or to tell me. Let’s go.

Speaker 1: Yeah, I think just looking here, I think, um.

Speaker 2: The people are.

Speaker 1: Advanced. I can see.

Speaker 2: I already have a user. I already finished the workshop.

Speaker 1: They’ve basically done it so over to everyone else to give me a bar, the workshop, and we’ll be tested. You’ll be tested at the end.

Speaker 2: All right.

Speaker 1: I think we’re good to go.

Speaker 2: All right, so I’m creating a new organization. I’m giving it a name. Yeah, you can just use bars. Org. No, don’t use. That’s mine. I’m going to create bugs or two because I don’t have it. Now, organization is basically your workspace, allowing you to share information, scan results, and just collaborate with your friends. So or colleagues obviously. So just create whatever you want. You can change the name afterward so it isn’t a big decision. Once you click on Create, we will start the Wizard. Now the Wizard here is a few steps to set up the repeater, the repeater, and next point, CLY is a tool that will allow you to scan a local instances or local development environments or even in the city context to scan stuff inside of closed networks like Docker compose or just things that happened inside the second machine, which isn’t rooted to the outside world. So it’s going to be pretty quick to set it up. You can choose between using Docker and PM or the Windows installer. I don’t know if you like that sort of thing. You can just copy the Docker, run command and paste it in your terminal. I’m going to go with Docker if you want. You can use the NPM, of course, or the Windows installer. Once you get that in, you can click next, which will ask us. Yeah. Are you sure you did it? Yes. Yes, we did. Now you will see that the wizard has automatically generated for us a repeater ID and a token for us, and you can just copy that and take it to the cloud again and paste it. If everything is okay and everything is working very quickly, you should be able to click on refresh status and you will see it connected. When this is done, it means we can go forward. Just click done and we are in. So this is where I want everyone to be. So just let me know that you are right there with us because our next part is over at the GitHub. And so before we start forking and cloning and the YAML editing, I just want to ensure that you’re all on the same page.

Speaker 1: Are we all there? Everyone. Sarkis is ready. Nice brain vision. All set? Of course it is. Got a brain. And the vision.

Speaker 2: You have the vision.

Speaker 1: I think it’s brain invasion.

Speaker 2: No, that would be good. But is in vision.

Speaker 1: In vision.

Speaker 2: Ray. What? Oh, brah, it’s actually. Brah, brah. Envision.

Speaker 1: Hmm. Hmm. You didn’t think.

Speaker 2: That one through, did.

Speaker 1: You?

Speaker 2: Mark in his bra? The. Okay, so we got Mark, We’ve got Sarkis, and I’m assuming others old tricks. So are you still with us, Avinash? I just want to make sure people are up to speed. And we can move on.

Speaker 1: All right. So, as I said, our next step is to forge the repository. Just go to new religion example actions and click on fork. Obviously, fork it wherever you can. And once it’s done, we just have something to do. So we’re going to go to actions, which is the most important part. Understand the workflows, blah, blah, blah. Go ahead, enable them. Don’t worry about that. Click on.

Speaker 2: This.

Speaker 1: And then in the CI part, you need to again click enable workflow.

Speaker 2: Yeah, it’s very important.

Speaker 1: Yeah. So usually it’s just one click, but GitHub changed it, so it’s two clicks. You need to enable that twice. So again, go to actions in your fork, enable actions and then go to the actual workflow and enable the workflow. Once you got that all set up and ready, remember that what we’re working with is the GraphQL branch. That’s what is interesting for.

Speaker 2: Us.

Speaker 1: For this demo. And this workshop. So I will say, okay, I guess we’re all set for this workflow to work. We need two things. We need the repeater.

Speaker 2: To zoom in a little bit more just.

Speaker 1: To.

Speaker 2: So for this to work, we need two things. We need the repeater secret setup and the exploit token. Secret setup. You remember in the wizard when it gives us the the token and repeater it did auto generated that. So those are the things we need, but we’re not going to use the ones that repeat that the wizard has generated. We’re going to create new ones because we need a different a different scope for the test. So how do we actually get those things and where do we actually put them? First, let’s go to Settings. And go to two secrets. Here. We want to add new repository secret. The first one will be the repeater. Where do we get this value from? We go back to the new religion. Your legion.

Speaker 1: Up.

Speaker 2: We go to repeaters. We’re going to create a new repeater. You can even give it a specific name so you will remember it. So c i, c.

Speaker 1: D repeat the O.

Speaker 2: And click create. Then we can just take copy the ID of that repeater that we just created and put it here. All right. Once this is set, we are almost done. We have just one more thing to put here. So, new repository secret. The next one is next. Project token. All right. So next play, Token. And we’re going to take that from going to our. Uh, user settings. All the way down. We have create API key. Now let’s give our API key some kind of a name. We can call it c i, c i c d. And there is specific things that we actually need here. So we need the scan, start scans, read all kind of things. But for this purpose, let’s just select all because we really just want to get this thing running. Also, it’s really super not secure to do that, but again, you can just delete it or you can use the knowledge base to see which exact scope you want. But again, for this example, you don’t need anything extra, so just will click create. Now you will see this screen. You need to copy that before you close it. Go to Action Secrets. Paste that value here. Make sure that everything seems to be okay and click add secret. Now you can close that. Once we know that everything is okay, because once this is closed, it can’t be recreated. But you can just create a new API key. All right. So it’s not a big deal if if something happened to it. Once those two things are set up, we can go.

Speaker 1: Let’s just make sure all those two things set up with everyone. Just a yes or a no or some form of. Some form of interaction just so that we’re not moving too quickly, too slowly. If we are moving too slowly, then tell us to get on with it. This is easy, but. They’re all typing at the same time, which is good.

Speaker 2: Uh oh.

Speaker 1: Is that the correct key exploit underscore token? Yes. I created for people with the idea of the repeater. Great. Do you need us to go back to any specific points? And the other picks. Point taken. Okay.

Speaker 2: Good job, everyone.

Speaker 1: So, Sarkis, are you good? Serkis. All set.

Speaker 2: Great. All right.

Speaker 1: So there’s a little bit of work to do at the front. But actually, now, once it’s done, it’s done. So. So. Yeah. Good.

Speaker 2: All right. So once this is done, we have just one more thing to do. So we go back to our fork repository. We need to choose the GraphQL branch. Right. Because that’s the actual one that we want to run the test with. We’re going to go into workflows. The bit just to talk about what is actually happening here. So we’re going to start a scan based on any push to the GraphQL branch, and we’re going to spin up a testing environment. We’re going to install some dependencies, install our next little tool. Then we’re going to set up those things as environment variables based on the secrets that we got here. Then we’re going to start a new scan. We’re going to test specifically for header security. We could, of course, add more and more and more tests, but just we want it to run fast so we can get the information and just see what’s going on. The target, as I said, is this one. That’s the DVR NeuraLegion dot com. So we’re going to scan that and you can see that we’re using the repeater that will be spin up as part of the repository setup and we’re going to use that token that we configured. Then we’re going to wait on the scan. While it’s while it’s running, we’re going to test it, the status every 30 seconds. We’re going to have a timeout of 10 minutes. We have our token being used and we’re going to break it any kind of issue. So the moment and.

Speaker 1: Hmm.

Speaker 2: So we’re going to use the breakpoint here, which is basically, if there is any issue, just stop everything.

Speaker 1: Sorry, Mohammed has just asked. Can you just share I’m assuming he’s meaning the.

Speaker 2: They use the.

Speaker 1: Resource actions that we’re.

Speaker 2: Using.

Speaker 1: Somehow. Mohammed, if you look above you have you should have the link to set up an account. I follow the follow the thing. But I think he’s looking for the GitHub repo to fork.

Speaker 2: So so the original GitHub is this one, right? So it’s new legion slash examples, but let me just share it here again. Right. So you just need to fork that. That’s the repository. So once we understand what we’re doing, we can go back to the main repository. Remember the GraphQL branch, right? And then we’re going to click edit here. And we’re going to, I don’t know, add the bug through the system. You can do any kind of edit or change to the redmi really, or even one of the YAML files if you know what you’re doing. Anything that will just push directly to the GraphQL branch and start the build process. Once you click on Commit changes you should see. Here. That there is a bill running, right? There is a CIA job being run. And the moment it will start running, we will also see it here. So here you can go to scans, the ones we hit, the part where we’re actually having the the call to start the scan. We will see our scan running here. And now it’s just building the container, grabbing some resources, environment variables, all kind of DevOps magic. And once we hit the start, next point can we will be able to see the scan running also in the UI. Any questions meanwhile?

Speaker 1: Well, Mohammed says that it’s the same GitHub link as previous workshop. Yes, but we’re using a different branch.

Speaker 2: Yeah. So we’re showing the GraphQL version now. So that’s going to take a few more seconds.

Speaker 1: Meanwhile, sorry, just quickly, Mark, and says he’s quite a bit behind. Where is the API key? Sure. So you go to the top right hand side with the profile figure, maybe bar you can show him.

Speaker 2: And you click. Yeah, so you click user settings and here you can create an API key. Just give it any kind of a name is to not waste too much time. Just select all in the sense of scopes and click create. This is where you get the value for the API key and for the the repeaters. Just take it from here. Go to the repeaters tab, click on create Repeater and you can just give it any name and you will have the ID here as well.

Speaker 1: Yeah. And just to say, just for those, there are two places to get an API key. One is in your organization tab on the left, but that’s if you have one of our pro tier licenses. I can’t know which one it is, but that will give you an organizational level key. This is user a user API key. So there is a difference. So obviously you’ll be able to use that. But obviously when you want to start working on more sort of expanded projects and collaborate, etc. with other teams and colleagues, then obviously you need an organization key, but that is the difference. So if you are looking in the docs, there is a difference between a user API key and an organization API. So here in this example we’re using the user API key, not the organizational one, just, just in case that comes up.

Speaker 2: So meanwhile, while we were explaining that our our CI, at least for me, the CI has reached the point where we are starting the scan. You can see that you also get the direct link for your scan here. You can just click on that. It will take you to two B and there is the pulling starting weighting on issues using all of the configurations that we have. So in a few moments you could see that the scan has started and we will be able to see all kind of interesting information about it. Right now you can go to configuration and you can already see all of the settings that we made through the through the PSI, which is pretty cool. So the scanned hosts, you can see who initiated it, which would be you, not me. Hopefully you will see the crawler target. And of course, the test that we actually wanted to run and of course all kind of configurations and also your repeater, Right. So that’s your repeater ID just so you know, which repeater was actually used to run that scan while the. Yeah. So for me it’s now in the running state, it moved from pending, which means it’s already in progress. We’re using the crawler so it will now start to look for pages to scan. It will map the target. It will find all kind of URLs. It’s looking at all the forums. And the most important part is that it will go over the GraphQL parts, which as we know, is the interesting thing. So as you most likely know, GraphQL is a bit interesting because unlike other schemas like Crest, etc., this is a query language, which means that we send some kind of a query and we can set some kind of parameters. You can really play around with this with this vulnerable app if you want. It has some very good information attached to it about how to actually secure GraphQL. There is good, good resources here. The GraphQL 40 minutes is very interesting video as well. So all of that is part of OWASP is pretty amazing. And so this this is still running. Let me just see if we get some information. Cool. All right. So a bit about what we can now start seeing here. So in the scan itself, other than just seeing the request every page and the discovery of entry points, we see also parsed parameters, which is all of the parameters which we detected that can be tested. You can see inside map all of the pages that we already found. So you can see all kind of resources. You can see the GraphQL endpoint, which I guess is the most interesting one for us. And I think that one of the most important things about our capabilities is that while other tools look at something like a GraphQL query and say, okay, it’s like some kind of maybe a JSON, maybe not, maybe it’s just this random string. We actually know how to detect it and pass it correctly. And I don’t just mean like JSON where we have some kind of some kind of parameters. All right, cool. But, you know, GraphQL has its own schema with its own way of configuring and its own names. So you can see that we really know how to break all of those down so that we can do those kind of tests and those kind of verifications to the lowest and most complex levels which are possible. So if you’re using GraphQL. You are, you can rest assured, knowing that we know what GraphQL is, how it actually looks like, how it actually works. Right? We know how to parse it and we know how to scan it because right, as you can see and this is all from crawling, you don’t need to import any schema. You don’t need to do anything like that. We find that those part of your application automatically, we will map them, we will find them, and we will show them here for you as well so you can actually see what we’re doing. So a bit about there.

Speaker 1: Any questions? Actually just about what bar I mentioned just now. Seconds. We have several GraphQL endpoints that we stitch together in the FE. How can test them all in one go here. In the Dischord under GraphQL.

Speaker 2: So we have several GraphQL and points that we stitch together in the front end. How can we test them all in one go here? So the beautiful thing is that you don’t need to do anything. We can we will detect. Also in this application, there are multiple entry points of GraphQL, right? So you can see that we we found. We found.

Speaker 1: Oh, let me just show you.

Speaker 2: Right. So we have multiple GraphQL endpoints here.

Speaker 1: And find an item. GraphQL I think it will come up with all the ones.

Speaker 2: Yeah, that’s, that’s, that’s, that’s most likely also true. So you just refresh.

Speaker 1: That and.

Speaker 2: GraphQL, right. So we’re still crawling the target. But anyway, I think it has like four or six GraphQL endpoints. And once we finish scanning, you will see all of them mapped here. So for each one of them, there is like a unique, a unique amount of parameters that you can verify and query and see that we have found them correctly. But that’s not the situation which is problematic for us. We created the logic around usually everyone just uses the slash GraphQL and that’s the main point for all the GraphQL queries and it’s just the query syntax which is changing. So we shouldn’t be any problem skin wise. And so that’s the scan. It will run. It will find some stuff and it will be done. And when that will happen, we will see that our scan is either done in a failure if we found the issue or it will be done just by hitting the timeout because this application is quite large. So the passing might might take a bit more time.

Speaker 1: Yeah, I think just just to add to what Bob mentioned, we use the crawler here, which obviously is going to provide the most automation. If you were however to upload the schema bar, then that would.

Speaker 2: Be.

Speaker 1: A lot quicker, right?

Speaker 2: Yeah.

Speaker 1: So we want to show you both aspects so that you can understand that you’ve got a lot of automation there, but then you can also define the scope of the test by uploading the schema. I don’t know if we’ve got that here available.

Speaker 2: Yeah, So, so I’ll show you that as well. So just taking another resource into into this example. So we have broken crystals. That’s a vulnerable application that you can also use in your tests if you want to play around with that. It sits in the same example elections. You just change to the broken Crystal’s branch. You already set up the secret, you already set up the repeaters, or there is nothing for you to do. In that case, you can just also click on the on the little pencil, you know, change something and do the do the commit. And that will also start a broken crystal build and run against that, which will also like show you a kind of vulnerabilities. So it’s pretty cool. Anyway, if you want to do an API test and you don’t have a UI or you just want to test the backend or the API is directly a nice option that we have is when you choose the target, instead of doing automatic crawling here, you can just do via API schema for API endpoint. In that way you can just go to the actual schema. I’m just going to get the JSON and I’m going here.

Speaker 1: Just to sorry, just to slow it down a little bit. So you can see here there’s there’s three. Things. You can upload it from a file, from a disk, you can use a pre upload.

Speaker 2: Upload it file.

Speaker 1: Or you link to the file, which if you’ve got the documentation that’s going to be publicly available like bars showing now you can just literally.

Speaker 2: Add and click import which will get it and automatically pass all of the API. By the way, we support both open API swagger and also Postman collection and you can even go into the schema itself and edit that on the fly. So for example, if you have if you want to let’s say scan only this post to API render and you want to even edit that while before doing the actual scan, then you can do that all from here. You don’t need to do anything special. It’s like all here ready for you. You can just take it away and have fun with it. So that’s a pretty neat feature. Again, open API swagger and postman. You can use any of those. Other than that, we also have, of course, the code which we just showed, where you can just put the URL of what you want to scan and it will automatically map and scan it. And there’s the HA file. The HA file allows you to do a recording with your browser or with selenium or any kind of automation so that you can create a specific scenario recorded and then scan that again and again, allowing you to really pinpoint specific parts of your of your application that you want to test and scan. It’s especially useful if you have things like, okay, we just added a new feature that allows you to do some context as form. You don’t want to go into scanning the whole application again and again. You just want to pinpoint those little scenarios. So either you can create that or you can import the scan and just choose this new endpoint. Or you can ask your automation people to just slap that on Cyprus I o or Selenium and just have it all in one go. So all of those are available. One more thing that I just want to maybe show is that. We talked about Heather security in that example action. But that’s just one out of all of the things that we can actually test for. So when you go to the test part, you just have all of the tests that we can actually do, which as you can see, are quite, quite numerous.

Speaker 1: Exhaustive.

Speaker 2: Yep. Yeah. So you can choose which things makes more sense, which things are less relevant. And of course, I think one of the one of your options as well is when you start a new scan, you can start that scan. Sorry, let me just create a new scan. And I can do that. I can create a new scan from where my templates upset settings.

Speaker 1: Yeah. You see the we updated scan. Sorry, we updated the UI.

Speaker 2: Yeah, we’ve updated the UI. And now with the zoom, I can’t find anything, but yeah. So we have templates that you can just use to run the scans. So that’s the you can start from OS top ten, 12, 25 from 2018, 19 and 2020. You can run a light scan, passive scan, deep scan and API scans. Those will automatically choose the relevant tests for your scenario. Right. And will allow you to not waste time. Just test what what is relevant for you.

Speaker 1: You can create your own templates. You don’t need to use the ones that are global, the ones that we’ve created.

Speaker 2: But it is basically like creating a new scan. You can choose, configure and then just use that instead of configuring the whole scan together.

Speaker 1: Can we just sorry, before you show them that, could we please just go through the scan optimizations and the CREATE scan? Because I did say that I would talk about it. Well, actually, I said that. I said that you would talk about it. You haven’t spoken about it yet.

Speaker 2: All right. So attack surface optimization, when you create a new scan, you have this very nice little section that talks about how to optimize the scan so that it will be faster and it will find more things, which is something that we always want. So this part really gives you a lot of control over what you will want, how you want to behave against the target that you’re scanning. So, for example, if the if the target might become unresponsive and in that situation you want to stop the scan automatically, you have this option here, stop scan. If target is not respond for you have the smart scan optimization, which as you can see, uses a lot of automatic decisions based on algorithms and context contextual analysis to decide if you want to scan some stuff and some stuff should we skip? Maybe if you want a more robust scan, you can disable that, but that means that you will pay for that in scan time, right? So the optimizations are always here to try and optimize the scope test, test less, but on what matters. Of course, if you don’t care about time and you’re not doing this in the second, just, you know, Hail Mary open everything and you can also do that Skip skip the static parameters allows you to control if we should skip or not skip parameters. That does not seem to change how the target behaves. So, for example, all kind of values that may be changing them does not seem to affect the target in any way. So we can skip those. And of course, if there are some entry points in the target, which takes longer to respond and we don’t want to waste that time or we say, listen, if it takes more than one second to respond, then just skip it. We have that option here. The last part is about which which parts of the request do we actually want to test? So the default is the body, the URL query in the fragment. You can also add headers, URL path, artificial URL query, an artificial URL fragment. All of those will increase the scope of the scanning, allowing you to test more parts of the target, but of course will take more time to do so. Anything else already that you think we should cover here?

Speaker 1: Yes, I do. Authentications.

Speaker 2: Oh, yeah. I mean, in the CREATE scan, I think we covered everything.

Speaker 1: Right. Sorry. And create scan. Yeah. I mean, you can schedule scans. I mean, these are all things, by the way that you can really, really self explanatory. I’m sure you’ll be able to pick it up.

Speaker 2: Well one of the of the things that you can do is when you click here on your user setting in help, you have both the knowledge base and the API documentation. So everything we’ve done here is fully controlled by API and we have our own swagger that you can just access freely here on the API docs. And also we have our knowledge base which have information about our system, how to use it, about the tests that we can do, how to do things, how to integrate. So for example, if you have a C ICD, you can see that we support a lot of those kinds of integrations. We just demoed the GitHub actions, but we also support Azure Pipelines, Jfrog, Circle CI, Jenkins, CI and GitLab. You can also, in the example actions see here that we have, as you can see a lot of those examples. So we play the we play the one with GraphQL and I just told you about broken crystals, but we have Circle C project set up to show you specifically how to use that kind of YAML. We have a scan with a HA file scan that uses swagger and ID enumeration test, which showcase business logic vulnerability, which is pretty awesome.

Speaker 1: Which is one thing, by the way, that you didn’t focus on when you went through the scan.

Speaker 2: Right, by the way. Okay, So.

Speaker 1: So maybe I mean, I know I touched upon it before, but maybe you, as the person that built the engine, can give them a little bit more detail. And why why these are so cool, why they’re so important and how we’re leading the way here.

Speaker 2: So basically, we have three things, three sections of vulnerabilities. We have the standard common vulnerability tests, we have the business logic vulnerability test, and the third party.

Speaker 1: Tests.

Speaker 2: The business logic. Vulnerability tests test for things which require much more than just sending the right payload into the right value. We’re looking at the context of the page that we are seeing. We’re evaluating is that the right page to do this kind of test? And then we try to play around with values while keep evaluating what is actually happening from the eyes of a user. So we’re using a lot of context analysis. We’re using some a high AI here if you specifically want to know what kind of AI. So in those cases we use some image recognition for detecting different views, which is pretty awesome, especially when you want to know if something that you did actually changes changes the state of the target. Also, we have our own web driver integration. So we created our own proprietary driver for Headless Firefox, which allows us to do those kind of business logic based vulnerabilities, driving the browser around manually making it execute all kind of actions inside of the pages. So again, that’s pretty cool. And also that’s what allows us in the common vulnerabilities part to be false positive, free, which is also something that all we talked about. But I think again, when we’re discussing CISD and we’re discussing tests that should run quite quick, while also be very precise, having false positives is terrible because it means that we’re just failing for no reason. And this is where really having zero false positives is something that becomes not just nice to have, but really critical for your success. So that was the test. And regarding authentication, so I guess you all have applications that you developed, all of those applications that you developed have some kind of login screens, most likely maybe not. And that’s also cool. But I guess those of you who developed stuff like that also created some kind of a login mechanism testing your website or your application without configuring authentication. Means that you’re just stuck on the loading screen, right? We can’t go farther than that. And this is where the authentication comes into play. We have few forms of authentication, so we’re starting from form authentication, hetero authentication, API call, open ID, connect, custom multi step authentication, browser based authentication, and LTCM. Anything that you might think of. Custom multistep allows you to really script your way through as many steps of authentication calls as you want, while going all the way into embedding parts of the responses into requests. And really, you have free rein on the flow of the authentication. There is also the browser based authentication, which allows you to really easily just put the URL of the page that has the log in the name of the fields and what value should be there and just start scanning. So we support all of those. And of course, if you need any information or any help in regards to to set those things up, then we have again in our documentation, which is quite robust. All of the all of the configuration options with screenshots, some of those even have videos attached to them to show you really step by step how to configure them, how to make them work, what settings should come where and how they should behave. So all of that is available in the documentation.

Speaker 1: Yep. And yeah, we’ve really tried to make it as self service as possible. And we have many users that that don’t reach out to us because the documentation really is clear, simple and easy to read and follow. If you do, however, have any questions, then I don’t know if you can see it on the screen, but you can also reach out to us via live chat and our support engineers are always here to help. We want you to succeed, so please feel free to reach out to us either to support at New Religion dot com or hit the chat. The chat icon in the bottom right hand screen and and yeah, feel free to ask us any questions and if there’s anyone available which there pretty much is 24 hours, then we’ll be able to assist as best you can do. We have conscious that has been talking for a lot but he’s been covering really, really good, good ground. Some really interesting topics that hopefully you guys all wanted to to discuss. But are there any questions at the moment? That you would like answering bra envision is typing. Do these configurations live in your bigger.

Speaker 2: Okay.

Speaker 1: In your platform. He dropped it himself to laugh. Platform. Or do you create a config we can put in our app repo.

Speaker 2: Um, so which configuration.

Speaker 1: Specifically?

Speaker 2: I think he may be talking about the YAML configurations.

Speaker 1: Oh, they are mostly figuration, so you can pretty much just so you can just pretty much copy paste what we did in the example actions, it’s just a very, very simple way to start that. But as we said, you can have all of this information and how to create those kind of things specifically for your application just by following the documentation.

Speaker 2: So even the even.

Speaker 1: So, you have command list and that’s that’s the place where you have all of the all of the options for the command line. So you can just change it. You can see what’s relevant for you, what’s not really what each option actually does. So. What we have is really just is really just an example. Example actions, right. But it just shows a few predefined scenarios. But just changing that to, you know, in the end, Right. If we go into one of those examples actions, the only thing we actually have here, which is of interest I guess to all applications, is just installing our CLI and then showing you how to set up the environment variables running the scan, which is this thing, and then pulling and waiting for issues to show up. That’s it. That’s the only part that you care about. And your target can either be broken crystal or my mega cool or some application or some local thing that is running inside of the Docker compose here inside of the CI context, if that makes sense.

Speaker 2: Makes sense. Thank you. Okay. Just in case you haven’t got that open. No problem. Mark, I’m assuming. Are there any other questions from anyone else? More importantly, has that worked for everyone? And as Bob mentioned, feel free to just run a test against broken crystals. It will find I mean, it is an intentionally vulnerable application. Please don’t send any bug bounty reports to us because they are intentionally in there, but only because we receive probably hundreds every day. And do do. Let us know how you get on. Or we can see here actually that the scan against broken crystals that he did.

Speaker 1: Yeah. It finished quite like after a few seconds.

Speaker 2: Right. Okay.

Speaker 1: So as you can see. Right, so this one is more scoped and it’s more defined. So it really takes 36 seconds to find the first vulnerability, which is the open buckets, vulnerability, basically just access to AWS three, allowing you to list everything that goes in there. You can really see examples of what we found or you can see that we enumerate the information, we show it very nicely. You can see the requests that we made, the responses. So we have a lot of that. The tool in itself, not just the way we pass GraphQL or the way we crawl, also how we give you as developer the information about the about what we did and how we have done it. So all of the details about findings looks a bit like QA report, at least for me. That’s what I was aiming for. So the following is checked during this test and you have like the actual information of what we’re testing, what we’re doing, what are conditions here. And then that’s what happened. And you know why you got this information and why we decided that there is a vulnerability here. Also, I think pretty cool is in again in our docs when you’re going.

Speaker 2: To and that’s in.

Speaker 1: Not scientist Integration Vulnerabilities Guide. All right. So in the Vulnerability Guide, you have information about all of the possible findings that we have. And inside each and every one of those is information about how to fix them. So, for example, in broken JWT authentication, if you click on that, you really have other than more in depth information about the actual vulnerability you have. In the remedy suggestions, actual code blocks and examples on how to fix something like that and how it should look, what you should do and how to verify all kind of things. So we really go into the developer, we’re talking to you as a developer from developers to developers. That’s the main idea of our tests and over a solution.

Speaker 2: One thing we didn’t show, by the way, just to show them now and you can perhaps show it here is the multiple different ways that you know, it can be copied as a kernel. We can copy the request just to talk about a bit more about debugging mode, for example.

Speaker 1: Sure. So, for example, when I have this kind of finding, I want to be able to verify that. So I can either click on the Modify script, which gives you a curl like capability here inside of the of the UI. But actually if you also want, you can just take the request. You have copy as curl raw request, URL copy headers and you can just copy that and put it inside your terminal and run it. Basically getting the same information here, allowing you to, instead of running a new scan and new scan and a new scan, allowing you to just enter a curl commands until you manage to fix the issue and until you manage to validate that. And then you can just run a new scan allowing you to ensure that indeed there are no more issues.

Speaker 2: Any other questions from from those here? Have you had your scan been successful? Are you all up to speed? More importantly, can you see how this can be used moving forward, whether for GraphQL or indeed not? Everyone’s gone shy. Okay. Anything else that we need to cover? Because I think we know that we like to give people a lot of their a lot of their time back. You can really see how simple, how simple it can be. Again, it can be used either as a standalone scanner or indeed the more importantly, integrated into your pipeline to test every build or every every commit, every pull request. But if there are no specific questions, then there’s one thing that I’d like to show you, and then we can just wrap up with a bit of a summary. But speak now or forever hold your peace, as they say.

Speaker 1: Okay.

Speaker 2: Okay. But if I can just take. Oh, you should let me. Okay, fine. I just wanted to show you, actually, because I do like to show it if you haven’t seen it already. I want to just show you another example here. A finding, and it’s a nice one that touches upon what Bob was mentioning with the proprietary headless browser that we’ve got. Because as developers, the last thing you want is to start chasing or tail chasing ghosts or to coin a joke that I invented my last workshop to join, to follow or chase the tail of a ghost, but with which I’m going to trademark that actually, I think, but reflective, cross-site scripting. And it’s a nice one to show you just because it shows you the levels that the our engine goes through to validate every finding. But you’re not going to get with other Das tools. And this is really why we like to just to to shout about this, actually, because it’s all about accuracy and actionable results for developers. So you can see this particular reflexive exercise. Those have only been found in the query by changing the value of the XML parameter identifies the value that was injected here. Now we give the remedy suggestions that bars are already touched upon. We have further reading for.

Speaker 1: This.

Speaker 2: We have a different view of the request. So what we deleted, what was what we added, We have the headers, we have the response here, the header and the body. But you can see here that we actually provide you an automated screenshot of this pop up executable that was generated with this specific payload. So this is just showing you what bar was was mentioning earlier. We really go very, very far to ensure that everything we detect is validated. If it’s an SQL injection, we’ve exfiltrated the data, the database name and perhaps a little bit more and bar. If I don’t if you want to give some other examples of other validations that we provide, then then feel free to jump in. But we’re running this headless browser. We’re looking for the reflection, we’re taking a screenshot, you know, it’s there, fix it. No false positives really, really is really as important. So hopefully you’ll all agree that’s a very nice a nice feature to have and something for you to. For you to rely on. I’m going to be wrapping up. I just want to just want to go through a summary slide that will take me about two or 3 minutes maybe. But before I do so, have any other questions popped into your heads? Obviously, we’re happy to. We’re happy to answer those. So just as a as a as a wrap up, you’ve hopefully successfully signed up for our free tier account. Do please give it a go. I think you’ve actually for two weeks, you’ve got a super duper account, you’ve got our pro something or other. You would have got an email to confirm which of those accounts you’ve got for two weeks. That gives you a lot more functionality for you and your colleagues and your teammates to use. Don’t forget you got the crawling for seamless automation. That’s what you use in this GraphQL branch. Okay, So we just crawled it. We detected the GraphQL endpoints and we started to test you can upload your open API or swagger documentation as well as your postman collections and the HA files so that you can actually start to leverage your existing automation that they’re carrying out already. Upload the half files, run very, very scoped, defined.

Speaker 1: Tests.

Speaker 2: Simplicity, the simple YAML configuration files and you’re good to go going back to mark or brain visions question you know these you can copy our one and then you can manipulate it for yourself or go to our docs. Look at command list, search for configuration files. All the information is there for you to then start to put together your own configurations really about one, optimizing the automation there. But also we went through and discussed how we have built in scan optimizations within the within the tool, and I hope you’ll all agree there really is not much configuration with the tool. If you look at other Das, there can be hundreds of different configurations. Of course you can get a bit more granular with certain axes, etc. but we really try to make things as easy as possible. Microservices, single page applications, web sockets, of course, APIs are fully supported. We’ve spoken about no false positives, but really as that is one of the fundamental pillars of our technology, we remove those no noise, no alert fatigue, actionable results seamlessly integrated. So do click on organization, look at the integrations that we have or go to our docs. But more importantly, you know, please use and abuse the system to scan your projects accordingly. If you do have any questions or queries, do put those in the discord that you’re already part of either in the GraphQL Galaxy Channel or indeed in our tech support channel under Support on Discord, Email us at support at New Religion dot com and what else? Chat to us. Follow us on Twitter. Do you read our blog, by the way? Because there’s some really useful information about specific vulnerabilities where we provide code examples as well. But if you haven’t already done so, do sign up for the newsletter. We don’t bombard you with spam, but it’s all very, very upset, developer focused stuff that hopefully you’ll find interesting. But if you don’t have any questions, we hope you enjoyed it. We hope you can put the scanner to good use against your GraphQL endpoints as well as others. Bah, I don’t know if I’ve missed anything, but thank you very much to everyone. And yeah, we’ll hopefully see you on the other on the other side and obviously have a great festive period. Whatever your denomination is you have.

Speaker 1: Thank you, everyone.

Speaker 2: Yeah, thanks, everyone. Bye bye.