Resource Center > Webinars
Security Testing, Spec by Spec, with Bright
Speaker 1: But thank you very much for joining this this webinar workshop on security testing spec by spec. I’ll let everyone do their own introductions as and when they start, but I’ll joined today by Joe Fish, CTO and co founder of Brite Security. Jeremy Tank, Core core contributor at Lucky. And my name is Ollie, head of product Marketing here at Brite. So just a quick agenda for today, just so that you’re all aware this is being recorded. There will be ample time for questions either via the chat or ideally via the via the Q&A functionality. So what we want this to be is conversational, relaxed. I think Barr and Jeremy will also be having quite a relaxed approach to what is hopefully going to be more of a conversation rather than people talking at you. And hopefully you’ll you’ll agree that we’re going to be showing you some some nice, interesting, cool features when it comes down to security testing, specifically related to the crystal language and of course, the lucky framework. I’ll provide a quick introduction into abstract testing and perhaps why it’s important. I know you’re not probably here to hear that, but I’ll just try and set the tone so we’ll be as quick as possible. Bar will then just run through the step tester itself and how you can use that against your crystal project. And then we’ll move across to Jeremy, who can showcase the lucky framework and the step tester integration and how that can be used as part of your lucky project. So yeah, let’s see. So there were a few more late, late stragglers that have entered, which is great to see you guys. So just just to say it is being recorded and please do feel free to chat away and answer any ask any questions. Sorry. In the Q&A itself. So just a quick intro into Bright, by the way. So we provide a developer focused Dynamic Application security testing scanner to scan web applications, APIs, web socket based architectures, mobile apps. I know this may not be so specific to Crystal itself in some ways, but it would be very relevant in other ways to perhaps other work we’re doing. We’re really about putting security testing earlier into the developers hands, and this is really where the spec tester comes into play. So I’ll let Barr talk about that a bit more seamlessly integrating into your pipelines. Automatically validating every finding that we get. So you do not have false positives, which I don’t think I need to tell you the benefits of that. And really a security scanner that’s been built for developers, for those that aren’t security professionals, to detect, remediate and fix issues as early as possible, as well as providing some really cool capabilities in terms of not just carrying out your trivial injection attacks, but actually trying to break the logic with business logic, vulnerability scanning or testing capabilities as well. Now, why is that so important? The application layer is always and has been and continues to be one of the weakest layers. It’s certainly the one that results in the most number of data breaches that we’ve seen pretty much continually for a number of for a number of years. The attack surface certainly is growing, particularly with the rise in APIs, for example, and it’s really the need for security testing to keep up with developers rapid release cycles. With multiple builds per day comes the introduction of security vulnerabilities at the same pace. And it’s everyone talks about shifting left and putting security testing into the hands of developers, but that security testing needs to match your speed. The developer speed integrated at all phases, but ultimately doing it as early as possible. And this is really where the unit testing part in order to test every spec by spec really, really comes into play and comes into focus. You know, you may want to ask when you’re carrying out security testing, and I know that Jeremy will be able to talk about why he was so keen to introduce security testing into a lucky framework. But typically this is this is an afterthought carried out manually, perhaps maybe with a peer review, But it’s typical that security testing takes very much a backseat. Right. Periodic scanning, periodic testing potentially by a third party. And actually it’s the tools that we use are actually inhibitory that may lack the ability or the agility to carry out these tests quickly against scope, define tests, i.e. against each spec, for example. There’s no feedback to the developers because it comes too late. It can’t integrate very, very well and it lacks that consistency in testing in order to build what is a comprehensive security program so that whatever you’re shipping into production is going to be secure by design. And this is really, really where you need automation. Automation with security testing that I mentioned is going to keep up with those development pipelines seamlessly integrated, but would also enable you to run multiple tests, ideally concurrently, that don’t run for days or weeks, but run 4 seconds or very few minutes so that it’s scalable. I don’t know the size of the organizations that you’re working with. I know that Kristol and Lucky are still obviously a language and a framework that are that are growing and gaining more traction ultimately, where others have failed. Hopefully you can start to succeed early on by adopting the security testing automation now and ensuring that whatever it is that you’re developing in your Crystal or Lucky Framework project has that security in built in, maintain and build that build and maintain a culture of security testing. And we all know that the earlier that we can detect and remediate security vulnerabilities, the easier it is to fix, the cheaper it is, is to fix. And ultimately, it means that you’re not you’re not going to have this context shifting because you need to then go and suddenly fix the security bug, perhaps that you inadvertently introduced one week, one month, one year ago. So. A little bit just to sort of set the scene in terms of what Bright are some of you may be familiar with, say, software composition analysis that looks at your libraries and dependencies to make sure that they’re up to date and patched. You may be familiar with static application security testing that looks at the source code pretty much from a one dimensional perspective, not looking at the running application. But that’s something that you may be familiar with in and around your work. Are a dynamic application security testing tools. So we’re really looking to detect vulnerabilities that would be exploitable in in the wild that would be. And that could be exploitable by a malicious user on the built compiled application. So really looking for things like cross-site scripting, interacting with the application itself to find real life, real real world security issues. And I’m not I know there’s a lot of information here, but I’m just going to go through it very, very quickly. We’ve sort of built our technology around developers, right? Not for security professionals, and that’s the sort of blocker when it comes down to security bar. And Jeremy will be able to talk about this a bit more. But here’s just a brief snapshot of the key aspects that we took on board, built by developers for developers, but obviously for the security, the security focus to test a multitude of different sort of applications. We really wanted to try and make security testing to be intrinsic to the developer’s experience, controlling scans directly from the CLI via configuration files, YAML configuration files. I’ve already mentioned the no false positives, so you can start to trust the output and know that this needs to be fixed, which is great for prioritization of fixes so that you can understand what needs to be remediated. We have seamless integration across the pipeline, very, very scoped defined tests. Anyway, this unit testing part with the SEQ test to be able to test each spec really enables you to define the scope of the test that enables you to run. I’m sure Jeremy will show it Tests that run 4 seconds that aren’t going to slow you down. One key focus for us is ensuring that you can detect as much as possible as early as possible. We’re not here to talk about those capabilities now. However, we have a very, very smart engine that really, really can go above and beyond to detect more and often. Without further ado, I think I’d like to hand the mantle over to backlash against CTO and co-founder here of Bright, and he’ll take you through perhaps more of a traditional look through it for Crystal in general, and then Jeremy will take the mantle thereafter. Thank you.
Speaker 2: Hi, everyone. Good to see you all here. Is that a good size everyone can see?
Speaker 1: Yep. Looks good.
Speaker 2: What’s. Nice. All right. So going from what I always said, the thick tester and just generally doing those kind of security testing in the specs has two parts. The first part is just the generic SDK, which is the sex tester ACR that I’m going to showcase. And then if you are using the Locky framework, there is some very, very sweet integration that Jeremy did, and he’s going to show you basically everything you need to do to get a project with the sex tester all integrated automatically. It’s really great work from his side and the integration is really flawless. So without wasting any other any time, let’s go into what’s the point and the use cases of using the Shard. So obviously, if you’re using Crystal and I’m sure that all of you have already created at least one project in Crystal, just adding it to the dependency obviously is the first step should be very easy installing the shards. The only external dependency that you might notice is the exploit SLA utility that has to be installed into the into the basically the environment that you’re running. So if you’re running the unit testing either locally in your own laptop or you’re running it as part of the PSI, this part will need to happen installing it, which is very simple. And in the end of the redmi there is even an example on how to actually install the CLI inside of the GitHub actions. So really it’s super simple. It just needs to live there. You don’t need to do anything else with it. It’s just a dependency and hopefully it won’t be a dependency for long. The other type that we need to do is to register for a new religion account or a bride account To register is very, very easy. You can just click on the link and let me just once again, sorry. Right.
Speaker 1: So sorry to interrupt. Just to say that this is that those that are joining, if you haven’t already done so, you can do this now as well with Barr, right?
Speaker 2: Yeah. You don’t need to you don’t need to have done that before. If you want to do the workshop with us, if you want to try out the things that we are right now showcasing, just feel free to do it with me. So. Up that new religion dot com. Either log in or sign up. You can either click on the try it free. Right? And then you can just create the account. So I’m going to create a new account just to show you how we’re going to go through this.
Speaker 1: So I would just say sorry to interrupt. We did say this is going to be conversational, so I will be interrupting for those of you, for those eagle eyed viewers of you, you’re thinking, hold on a second. All of us just been talking about brights. Barr is talking about Bright But we’re looking at the word new religion. So just to for any one of you that’s confused, we did go through a name change. We used to be called New religion. We are now called brights. And I’m sure you can all understand that whilst all the marketing stuff has been done with Brite. The last thing to be changed is the is the engine and the everything you see now. So don’t be perplexed or confused about that. This is definitely the right thing and eventually it will change. I just thought I’d just clarify that for everyone.
Speaker 2: So once you get all of that configured set up field, you can just click on Create a free account, You will get a confirmation email. You just need to follow up on that and. Yeah, obviously I have already created that, so I’ll just create. Sorry about that. I never remember which.
Speaker 1: You’re going to have to start getting some. Yeah.
Speaker 2: I always move the. Let’s try this one. I don’t think I have that. Let’s try. Sorry. Right. So my password. Everyone, please look away.
Speaker 1: It’s just password, right?
Speaker 2: Yeah, obviously. Password. One, two, three. You have to be secured. Obviously, you don’t have to put blowfish as your full name or this is this in the email. That’s basically mine. So. Right. Okay. No, we got it. So we’re getting the link verifying. Going in. Now you can create an organization, give it a name. The organization is basically a workspace that you can invite other users to join in. See the the results, see the scans. This is especially helpful if you’re working on, let’s say, an open source project or internal company project, and you want a few people involved to share their thoughts or just to have collaboration around that. Basically, if you want people to actually offload the fixing too, then that’s a great way. Just invite people that you think are going to go and fix the stuff. That’s the best way. So I’m just going to create, as you can see, borrowed. Yeah, and I’m going to create it. Then the next step is to install the next ally. So you can see that we actually have all of the configurations and all of the steps to actually install it here as well. You can just click next and choose whatever whatever way you prefer, either as a Docker container, as an NPM package, or as a Windows installer. We will even automatically create these for you. So we’re going to generate a repeater ID, we’re going to generate a token for you all, so you can just copy that and paste it into the terminal. Once that’s running, you will see that this becomes connected. And then you can click on done. Now, the whole point of that was really just to make sure that everything is okay, you have it installed, etc. so you don’t have to actually install it where it where you want to to have that actually running. It’s just to make sure that everything is working before you start. Now our second step is actually to generate the API key. This is done from our UI. You just click on your user settings. Here. You scroll down all the way. You create an API key. You give it some kind of a name. So let’s call it tech tester, for example. And there is in the knowledge base the exact configuration for what you actually need from that. But just because we really care about security, we’re going to just select all of the scopes. And I’m going to click on Create. Now, obviously, this is a secret. So if you’re doing some kind of a streaming or a workshop, don’t let people see that, right? Because it’s secret, especially if it’s if it’s been recorded and then you share it with others. So don’t let people see that. Once it’s generated, you can just copy that and close. Do note that you won’t have access to the full API key later, so better save it somewhere safe. Obviously there is no limit on the API keys. You can just create as many as one. So even if you forget it, you can just create a new one.
Speaker 1: Yeah. Once that’s closed, you can’t see that value anymore, right?
Speaker 1: Test my WordPress against Lucky.
Speaker 2: So, so for example, this is a good point. So if you’re using Locky, obviously there is no need to test for WordPress, which is exactly why you’re optimizing and choosing the right tests is something that is very important.
Speaker 1: Surprise, I once built a Rails app that was literally half rails, half WordPress all integrated into the same code base.
Speaker 2: That sounds horrifying.
Speaker 1: It was.
Speaker 2: And I guess the last part is about integrating into the CI. So it’s really, really, really easy. You just install a repeater. You set up the exploit token. You set up the Brite token. Sorry. By the way, this is this is incorrect. I’ll also fix that if you want to see an example of how it actually works. You have the six testers own unit testing available so you can see this uses the Brite token. Right? And you can see all of the steps that are actually happening. Not only that, the six testers, your specs are actually spec six this the specs. So you can also see how to use the target, how to set it up. You can see all kind of use cases like testing for X from the rhythm and also testing for other stuff. For example, how to set up specific headers. You can see how to set extra headers in the context. You can see, for example, how to use the severity, the options. And also if you want to start and you scan with extra options, there is an example for that and how to actually do this function thing. Single function test. You can see that there is a definition for my function which basically just returns the same data that it gets. This is specifically relevant for X success because it tests for reflection, but obviously as long as it returns a string or you can just do two X on the response, then we can digest that and try and evaluate if this function is actually a. Susceptible to anything. Last thing before I hand it over to Jeremy. You know what? Two things. So first, if you are not sure. You can always use Neil in Crystal. We really love Neil. So that’s an option if you just pass Neil or don’t defy the. Define the tests. It’s going to use all of the tests. It’s going to take a lot of time. It’s going to be inefficient. But if you want, you can do that as your first step, basically, and then say, Oh, I see that I have those problems from this point on. I’ll just use those specific tests. And basically there is an example of the Shard in action on the Lucky Stick test report. But I’m going to hand it over to Jeremy because that’s basically what he’s going to talk about. And if you want to just play around with it, there is also a CLI that I created to test the library, but it actually has a nice output and allows you to scan a single URL for all of the vulnerabilities. So if you want, before integrating that fully into your workflow, just to get the feeling of like how a scan looks and what it can find, you can just use that. It’s super easy 2 seconds to to start just clone a child, build and use your bright token as the option. That’s it from my side.
Speaker 1: Any questions? Yes. I was just going to say, just before moving to Jeremy, are there any are there any questions for Barr just before.
Speaker 2: So quiet.
Speaker 1: Yeah.
Speaker 2: Yeah. Is anyone. Can anyone hear us?
Speaker 1: Yeah. Alexander says that. Not yet.
Speaker 2: Not yet. Well, that’s obviously Bob. Congratulations. You obviously did a good job.
Speaker 1: Yeah.
Speaker 2: It’s so.
Speaker 1: So obvious and so clear. Well, that’s why we use crystal, right? All right, so I’m stopping my sharing and moving it past to Jeremy.
Speaker 2: So I’m presenter now. Time for me to take over.
Speaker 1: Yeah. Take over.
Speaker 2: All right. Let’s just. Share this whole thing. Participants can now see my screen. All right. So you all can see my screen. Everything.
Speaker 1: Yeah. All good, Jeremy.
Speaker 1: From the get go.
Speaker 2: Yeah, exactly. Exactly. So you go once you’re logged in, you go to your user settings, you create your API key, and then that’s what is going to go in here. You can set that as that value. The next thing we get here is under spec flows. Now, from Lucky, we actually have quite a bit going on here. We have all this testing guides and all this. One of the things we have, though, is called Lucky Flow. And what Lucky Flow does is it tests your front end for just. Um, interactions and UI and whatever. So you can say go to this page, you should see a button that says this or click this button and you should be on what page. So that’s what the lucky flow does. And what we’ve done is we’ve added in the security spec. Now, as you’ve seen, I didn’t write any specs yet, but yet I have several specs already written for me. And that’s because when you generate with that dash with test flag, we’re going to go ahead and give you this. Now, there’s a small caveat to this. The specs themselves actually do take quite a while to run. For me, running these is about. 25 minutes locally on SCI. They they generally tend to run a lot faster, maybe about 15 minutes or so. But yeah, locally for me it runs in about 25 to 30 minutes, somewhere in that range. For that reason we give you the option to basically opt in. So by default, if you just run crystal spec, we’re going to go ahead and skip these. And for another reason too, is because. When you get your account with Brite, they’re going to give you a certain number of what is it, bar scan hours or.
Speaker 1: Yeah, I think. And only you can keep me honest here. But I think. And I think there are like, like ten, right? Ten or something like that. Scan ours. Um, in regards to the free account.
Speaker 2: Yeah. Yeah. So out of the box, you’re going to get a certain number of hours, whatever that is, for your accounts. And as you’re building your application, you don’t want to be running up those hours and spending all this time, right? So it is a nice thing to run locally here and there. Maybe. But the real idea would be to run this in your CI. So when we generate the CI, we actually set it up to where it will automatically add that and they’ll automatically run that for you. So in your CI, it’s automatically going to run those. So I can run crystal spec and funny thing here is so I ran this yesterday and I realized that there is actually a failing spec I must have missed on the last update. So I have to actually update that.
Speaker 1: Just going back. Sorry Jeremy, this is what you’re doing that to the the scan times. I noticed that one of the tests on there was the access testing. If you go back to the flow. So yeah, that’s probably one of that’s probably one of the longest testing cases that you can do using the bright scanner for a multitude of different reasons, which maybe Barkin can go into. But I think the beauty of this is also that. It doesn’t need to be like all or nothing. Right. You can, as you mentioned, refine the testing, perhaps by removing certain tests that might be that might be quicker, you know, giving yourself maybe less coverage from a testing perspective, but at the very least, enable you to run a full suite of tests that perhaps aren’t going to take as long and then perhaps run a longer test later on if if you didn’t want to be slowed down during this process.
Speaker 1: Irma, are you able to. Are you able to make this this screen that you’re working on now bit bigger? Just a comment from Alex on the chat.
Speaker 2: Oh, the code. Oh, here we go. Yeah, sure. How’s that? Perfect. I won’t see that. Okay. Sorry about that. Yeah. So what I’ll do is let me go ahead and I’ll just comment out a couple of these so that way I can run them a little bit faster. And what I want to show is. I’m going to I’m going to actually take this out here. Bar mentioned the severity threshold, but I’m going to show what this looks like when it fails. All right. Those should be all right. Yeah. I’ll come out. This one too. Just so that way these run a little bit faster. And I want to show how this looks when it fails. So if I run Crystal speck, it’s actually not going to run these tests at all, because, like I said, this is going to skip Skip unless I add that flag. But we can see that we have a failing spec that I need to work on. So now I’m going to go ahead and run it with this test. Since I’ve added my environment variable, my my API key in here now it’s going to run those tests. So here it goes. You can see it’s taken a little bit longer.
Speaker 1: The moment it starts, though, it’s pretty awesome because you can already see in the platform in our own UI, the scans are the scans go to pending and you can see the information of the actual scan. So you can see already the scan is bending and the engine starting. If you go into this scan, you can actually see the configuration that you did. You can go to once the scan started, you can go into the entry point information to see exactly how the request looks and how the response looks. You can go into the site map just to figure out exactly like how your rail looks. You can see the target that was set already, which is like the route target, right? So you can see it’s local and there is just like the random port or it’s not the trend or it’s like whatever the lucky dev port, I think it’s 3000, right.
Speaker 2: Yeah, well, locally, I think the specs are running.
Speaker 1: On five 5000. Yeah, I see. 5001. I think maybe you can refresh that. Yeah. Yeah. So as you, as you can see, the kick start of the engine takes around. We can call, I don’t know, between 30 seconds to one minute, depending on the size of the scan. But if you are, one good strategy to save time is to put a few tests inside of the same spec, because then you save time on kick starting multiple engines. We are also working on improving the start time of engines so that starting scans will be quicker because you will see that the actual time for a scan is usually like 50 seconds or something like that. Not talking about the one scan with the new value for this, which obviously takes some time because it scans for everything. But Jeremy, can you click on refresh for a second? I think the scan is done. Yeah. So you can see that it’s already done. If you click on an entry point in the tab. Yeah. So you can actually go in and you can see like real information about the request response, how it actually looks like. In this case, there are no parameters, but you can see like what the, what we sent. You can see what the lucky app actually responded with. So, you know, it’s all there. You can see even the authentication information, you can see the cookie, the session. So you can really drill deep into what we did. It’s not just like some kind of magic. There are there is like real information about it. So, you know, it’s not just a checkmark that goes green and you can actually see that there were tests running. Yeah, I think it already moved to yeah. To start the next one here. You can see that also in tests you can see exactly which tests were were running. In this case, we’re still.
Speaker 2: Loading that fancy animation.
Speaker 1: The power of gifs. Yeah. And if you click on progress once the scan starts, you can also see like where we stand in regards to all of the tests that you configured so you can really play around with it. One more thing that you can do talking about the generic SDK is to actually use that for QA automation. So if you want to test your staging application that’s already up, you can just create a crystal file that runs in your CI and you just set the target to whatever the target of your web application is. In the case of the unit testing example, obviously it’s local and as you saw, it’s very nicely automatically generating the actual target. So like the localhost and whatever is needed. But if you want to look at it in a different way, then. Okay. So you can, by the way, see that we have already findings. And you can also see in Jeremy’s terminal that there is an error showing.
Speaker 2: Yep. So it’s just wrapping up here and we can see that this one here had six low priority issues. Now, one of the the issues that we’re going to see pop up on here is from the cookie security. So it’s recommended that when you have your cookies, you have them set to HTTP only. Right. Or you have them set for secure. Now, when you’re running tests locally or whatever, by default, we’re not going to have luck. He’s not going to have the cookies set to secure. Just because this is going to be based on if your cell handler is turned on, and that’s really only going to happen if you’re in production. So in this case, having your cookies set to run on HTTP. Is sort of a low security priority. We know that those will be enabled in production. So it’s really going to be up to you. You can decide whether or not you want to ignore that or not. So what we do is where do I remove that? Here we go. Is we have the severity threshold where we can actually just set this to medium since it’s a low priority security. Now this the severity threshold. It is an enum. So if you happen to try and type in medium and it doesn’t work, you’ll want to use the tester severity enum. That’s just mainly based on how crystal passes the auto casting from symbol to enum. It doesn’t work when it goes through several wrapper layers of methods like we have on the lucky duster. Okay. There it goes. Here’s the actual failure. This is the one that I was actually waiting on. When we get the failure, we actually get quite a bit of information back from the set tester to let us know things like what happened, how important it was, what the error was. Different details on how you can possibly fix it and everything like that. But this is the way the failures will look. And again, the only reason that failed is because I said go ahead and raise on all severity levels as opposed to just medium. But. I mean, we could probably talk about this all day, but are there any questions? Yeah.
Speaker 1: Let’s see.
Speaker 2: Can I see?
Speaker 1: No questions so far from my side. Alexander I’m pretty sure that you’re the only one that actually listens to us. If there are other people, at least just say hi, like you don’t need, oh, two of us listening. That’s what I’m talking about. All right, so at least two people. Oh, so three people. Awesome. We will also have a topic. We will also have Russell. Everyone is spamming the chat. So we know they’re actually here. Awesome, guys. So we are going to have a recording of that. So if you want to watch it again to hear us talking about it, if you have questions, by the way, the work that we Brite did with Jeremy and Lucky is is a show of trust from the Laki crew to us and from us to them. It’s a real collaboration. So if you need help in regards to that, I’m also in the Lucky Discord all the time. So if you have questions, you can find me there if you want to. We also have our own discord, but again, I’m also giving support in the lucky discord regarding that integration. So bugs, questions, stuff, whatever you need.
Speaker 2: Let us where are we going to post the the link to the video? Probably post it in the Lucky Discord for sure. Maybe in the bright discord. Probably all the social media is if you’re not.
Speaker 1: So also also anyone that registered for the event. You’ll also get an email to the recording. But yes, Jeremy, of course we’ll add it onto the discord. I’m sure Jeremy can find a nice place for it on the on the lucky framework dot org websites as well.
Speaker 2: So that will end up being here.
Speaker 1: Yeah. So, so we can do that. I mean a question I’ve got to those that are listening before they all jump off with their thank yous. Are you using. This already. Have you tried it out? And if not, will you be trying it out after after this talk? That would be that would be what I’d like to know. Did you get enough from this to use Bright and also to look more into Lucky as well? Alexander says it might be worth mentioning that lucky users will be happy if anyone decides to contribute. Absolutely. And yes, Bright are looking for crystal developers. So. You know, if. If you’re interested in working with the future of security testing, then. Then, Yeah. Reach out to us. Okay.
Speaker 2: By the way, David, if you want to test or play with the sex tester and you’re not using crystal and you work in backend, that’s also great because and again, this is we did one workshop around it and it’s still really in.
Speaker 1: Alpha.
Speaker 2: Alpha, but there is also sorry, let me send it to everyone. There is the sex tester. GS which still lack proper, proper documentation, but it’s there. We know that it’s working. Not great yet again. It’s still not a fan, but if you want to try it out to play around with it, then you have that option as well.
Speaker 2: So especially because it’s so close to crystal. And if you take a look at the sector structured source code and it’s again it’s open source obviously mid then you’ll see it’s very slim. It’s just an API around their own backend. So it should be pretty easy to quickly port that to Ruby. We have that in our own roadmap, in bright roadmap. But if anyone is interested, you know, that could be an awesome collaboration project. So I. Well, we would love to play around with stuff like that.
Speaker 1: Yeah, that’d be awesome to see.
Speaker 2: But let’s be honest. Crystal is much better. I’m just kidding. Not starting wars. All right. Awesome. Thank you, everyone, for joining in. And again, if you have questions, as we said being us, let us know. Thank you for everyone who joined. You’re amazing.
Speaker 1: Yeah. Thanks, everyone. And we’ll be hanging around on the discords and such if any other questions happen to pop up?
Speaker 2: Absolutely. Thank you, everyone. Look out for the recording. Keep in touch via the socials, discord, Twitter, etc.. We’re all here for you. Thank you.
Speaker 1: All right.
Speaker 2: Bye bye.