CI/CD and Security Testing Automation with CircleCI and Bright

00:00:01

Speaker 1: Hi everyone, and welcome to today’s webinar where we’ll be covering covering CI/CD and security testing automation with CircleCI and NeuraLegion’s Dynamic Application Security Testing Platform. That’s a handful, and I’m very happy that I pulled this thing off. 

Speaker 2:Yeah, Well done. We practised it 21 times, and you got it right on the 22nd time. So well done. Well done for that. Or DAST, as some of you may, may or may not be more perhaps more familiar with, but. Yeah. Good job. Good job, Zan. 

Speaker 1: Yeah. Anyway, my name is Zan Markan. I’m a developer advocate at CircleCI, and I’m joined here today with Oli from NeuraLegion. 

Speaker 2: Hi, everyone. 

Speaker 1: Um, yeah. So let’s. Let’s crack on. Today. We’ll be covering a few things. First off, we will be looking at what CI/CD is and who we are at CircleCI. And kind of I’ll be explaining a couple of things about what we do, how to set things up and so on. And then I’ll offload to Oli, who will introduce us to NeuraLegion and, you know, talk us through how their product, their DAST product integrates well in a CI/CD pipeline by CircleCI on a practical demo as well. We’ll let a few minutes in the end to answer any of your questions. So if you have any questions, please do use the Q&A feature of Zoom and we will answer you at the end. Anyway, let’s crack on. So CircleCI were all about letting folks go as easy and straightforward as possible, from idea to delivering great software and fulfilling that idea basically. We’ve been around for about ten years, just under ten years now. And we are a global company with employees pretty much all around with major clusters in the US, Canada, UK, Germany, Ireland, Japan and yeah, a bunch of people also everywhere else. And we’re the world’s largest shared CI/CD platform operating at a truly enormous scale. And all of these awesome companies and many, many others are building a bunch of software daily on our platform. In fact, I’m willing to bet that every single one person watching this has used at least one or two pieces of software that have been built, tested or deployed using CircleCI today, from open source tools to proprietary software. Anything. Anyway, what is CI/CD and where do we actually sit in the developer toolchain and the software delivery process. So if you think about the process as something that starts with developers writing code. So on our left hand side, we have this creation tab. People use GitHub or any other VCS provider. They kind of create commits, they review their code. they do all sorts of things. And in order to build up their source code, that ultimately ends up being produced, productionized and deployed to users. On the other hand, we have a…on the other hand, we have the operational logistic side where it’s basically that software that we kind of developed on the on the left side is deployed and actually touches the user that can be deployed anywhere from like AWS, Kubernetes running on AWS to an Android or iOS application that’s available on the on the play or app stores to any other type of software in between, basically. It needs to be deployed. It needs to be operated, it needs to be updated. It needs to be maintained and managed from a security standpoint. And in between we have this orchestration part, which is where all of the essentially automation happens, which is what we’ll be talking about today. So if we’re thinking about what happens when you commit the code, you have written it, you have kind of created that code manually, basically. And then the ideal is to automate everything else between that and actually getting that from the user. And that’s where we, CircleCI and our partners, come into play. So our platform lets you build, test any type of test really from unit tests, integration tests, smoke tests to all the way to advanced security scanning to packaging and deploying that software. And now I will move on from slides to give you a bit of an idea of how this all works. So CircleCI has two aspects. First one actually lives in your repository, and that is this CircleCI configuration file config.yml located in the top CircleCI top level directory. And that’s kind of committed alongside your rest of the code where we define a bunch of things. For example, we define jobs, we define ops and we define workflows. And that basically tells CircleCI what to do, when it… when a new commit is triggered. So in a nutshell, a job is a series of steps that execute in a given environment that can be a Docker container, a virtual machine, and a bunch of other things and the steps are anything from command line instructions to built in steps like checkout, which kind of checks out the code from the from the repository to kind of pre-set collections or configurations of steps that come from these things called orbs. So that’s essentially an orb is a way to share bits of pieces of pre-written configuration, for example. Docker build is pretty standard and we can essentially offload that and hide that away in an orb so that you don’t have to write all the manual steps for it. So that’s a job essentially, a confined environment where things are executed sequentially and a job will either pass or fail at the end, depending on whether it’s been successful or not. You can have a bunch of them and you order and arrange those jobs within a workflow. Workflow is essentially what gets triggered and what gets run. And yeah, as I said, where you arrange all of your jobs, for example, my test job, my build Docker job and my deployment job. And with that you can actually say what needs to happen in parallel, what needs to happen sequentially. For example, my build Docker job that’s part of this workflow requires this test job first. And  you can also set up filtering on branches and stuff like that. So that’s a very kind of quick introduction of how you configure CircleCI, which we’ll be seeing in our demo later. And the other part of the platform is this dashboard that we have, and that’s essentially your single pane of glass view of all your projects, all your pipelines that have been run, which let you see, okay, these projects are running, are building successfully. These projects are failing. What’s happening. You can go see how things are progressing. If something is in progress, you’ll see that, how long for, and a bunch of other things like insights will tell you like averages over time of how long things have run for or how successful they were and so on. So it gives you like this really single pane of glass view of your organization’s software delivery status. I mentioned Orbs. So Orbs are essentially available, there’s hundreds of them available from both ourselves, the CircleCI team like Node.js, Slack, Python to partner Orbs, one of which is actually made by NeuraLegion. And, yeah, they can do everything from showcase how Orbs help with language use to to different platforms, to different kind of tools like for security scanning. And that’s enough about CircleCI. I’ve talked about Orbs a little bit. And yeah, as I said, they are just a set of commands and executor’s jobs that you can package and reuse. So, yeah, this should give you a nice idea of what CircleCI is and how it works so that now Oli can present how NeuraLegion works and how you build, how you integrate NeuraLegion into a CI/CD pipeline. 

Speaker 2: Yeah. Thank you. Thanks a lot Zan. Let me just share my screen. Make sure I’m sharing the right one. Okay. So just to confirm, you can see the right screen there Zan,right? 

Speaker 1: I certainly can. 

Speaker 2: Yeah. Great. Thank you very much. So, yeah, thank you very much, everyone, for joining. It’s already been a pleasure. I’m sure it will only get better. So let’s start perhaps with an introduction about NeuraLegion. Now, we can’t yet say that there are millions of users of NeuraLegion like there are with CircleCI, but we’re certainly on the way, on the way there. So we provide a very innovative DAST tool. So dynamic application security testing technology, really built for developers. We really want to try and put security testing into the hands of developers to try and enable you as an organization to enhance and cement a culture of security testing across your pipelines, to be secure by design, to detect, prioritize and fix and remediate issues as early as possible. Whether that’s against your web applications, we have full support for API scanning, whether that’s REST, SOAP, if you’re still using that or indeed GraphQL. We’re the only security scanner that has full support for automated web socket security scanning. And we can also test against your server side mobile applications. And we’re all really about that integration and seamlessly integrating across your pipelines, particularly with CircleCI and that I’ll jump on to a demo as Zan has alluded to. But one of the main pain points and bugbears when it comes down to security testing is false positives. And we really look to remove those with no false positive reporting so that you as developers can get immediate actionable results with remediation guidelines, start trusting your tooling so that you can start fixing things early, as early on. And you can see here just a brief selection of company logos. Just to give you an idea of who we’re working with in terms of the size of organizations as well as multiple different industries and indeed sectors, If you’re building anything, it needs to be secure. It should be secure by design and you should be looking for these vulnerabilities as early as possible as part of your pipeline. But just a very, very quick sort of let’s typically, as I mentioned before, security is always sort of been something that’s been the phrase thrown over the fence to security, always, always sort of springs to mind. And, you know, developers and security experts, your security team will view your software very differently and actually want to try and bridge that gap. We know that not everything is perfect. Developers work very, very hard to rapidly release new features, build new things as quickly as possible, speed really, really is key, and security has always been seen as this blocker. You know, everything’s broken. We need to fail this build. We need to put the brakes on everything because we need to test it. And typically that’s been done very, very manually. And actually with DevOps with CI/CD, actually what comes hand in hand with that is actually automation. And when you look at legacy tools on the market with regard to security testing and specifically Dynamic Application Security Testing or DAST tools such as NeuraLegions Tool, they’ve been built for security professionals, they’ve been built for cyber security professionals, not for developers, not as a tool to put that into the hands of developers where developers like to stay within their environment. So this is really something that has historically been done. But NeuraLegion looks to try and bridge that gap to make security testing a seamless part of the developer’s workflow, but more importantly, to remove all the false alerts that typically lends itself to the security testing tools being disabled or the results or the output being ignored. And that’s really something that NeuraLegion is leading the way in, in resolving from a security testing perspective when integrating across your pipelines. And just in case some of you perhaps aren’t aware of DAST tools and where we come in that flow. You know you may be all familiar with your with your SCA checking your dependencies such as Snyk for example, you may be performing static analysis such as SonarQube for example, we look at the runtime application or the API to look at your your targets, look at your assets as if a human tester would. A black or gray box testing to not look or look at the actual specific code, but look at how the application or targets can actually be exploited for security vulnerabilities as if a human would be. And that’s what our technology looks to, looks to automate. So this comes slightly further down in the process, but is actually looking at your microservices, looking at the built application for security issues that are actually there. And as I mentioned before, it’s all about allowing developers to own security testing, be able to leverage the security test, right, leveraging your mock files to do that from your unit testing directly, not to use a UI, but to be able to control the scans via code via configuration files like the ones that Zan has shown us. And I’ll also demonstrate those configuration Yaml files in our demo that I’ll get on to shortly. And again, it’s really about trusting the results that your scanner has and removing the false positives. Developers don’t want the noise. It’s the second time I’ve mentioned false positives and I will mention it again because this really is a fundamental issue when it comes down to security testing and is actually a big blocker in itself to enable you to start shipping secure product into production with your security testing. So let’s look at the sort of five key vectors that NeuraLegion looked at. And DAST is a very, very old security testing technology or methodology of testing. It’s not that we’ve come to the fold with a new way of testing, but actually we reinvented the way that DAST can be performed, not only by security professionals. If there are any security professionals listening today, we do, for example, automate the security testing for security teams, MSSPs and penetration testers. But we’re really there for the developers to do that. And we looked at these five key things to really try and assist. One is the coverage, legacy tools when you look at modern technologies and modern applications, 90% of web traffic is now carried out over APIs, and you need a technology that can seamlessly test not only your web applications, but look at your single page applications. The APIs, as I mentioned, whether they are REST, SOAP, or indeed GraphQL, for example. Web sockets is something that’s really key. So our technology has been built from the ground up to be able to fully support and complement these modern technologies. But I mentioned previously that security testing is typically been the responsibility of the security teams, and the tools are built for security professionals, cyber security experts with very, very complex configuration, very, very complex setups in order to ensure that you get the right the right tests against the right target, but as well also try and minimize the number of false positives, so the output that you’re getting is going to be relevant to the application. And our technology has been built and underpinned with reinforcement learning and machine learning. We have natural language processing in-built into our technology to remove the need for the complex configuration to enable our technology to do all the heavy lifting. So to provide a technology that you can put into the hands of developers or you as a developer can very, very easily use without having to go through that complex configurations. We have multiple scan optimizations out of the box where our platform will look at the target and skip certain tests that are going to be irrelevant, skip certain parameters that aren’t going to have an effect on the on the on the target. And this really all boils down to maximizing scan speeds. These are all about optimizing security testing so that it fits seamlessly into your CI/CD and keeps up with your rapid release cycles and your DevOps speed. And it’s built for developers, as I mentioned. But one key fundamental differentiator of our technology is the fact that our engine goes through a process of automatically validating every exploitable vulnerability that we detect. So we don’t have false positives. And this means that developers, when they get a JIRA ticket open, for example, or if there is a vulnerability that’s been detected, if and I’ll show you soon if your build has broken based on a specific breakpoint of a medium or a high severity issue, you know category that it’s there because our engine has validated it. With other tools, the false positive issue is actually going to be setting off all these false alerts. Your builds are going to be breaking for no reason. They then need to be manually validated by your security team. This takes a lot of time, costs a lot of money, and ultimately will just delay your release. So we’ve removed that with our automatic validation. We have seamless integration for developers that can remain within their environment to carry out the testing. And of course, we have a very, very nice UI for the security team. But ultimately it’s really about the developers being able to utilize our technology to carry out very, very quick tests against every build, every commit or indeed merge to master. It really is up to you with a tool that security trust, but developers love to use. And this all goes down to the speed. And we don’t only rely on crawling functionality, but we have multiple different discovery methods for the attack surface, whether that’s crawling, which I’ll show you in the demo very shortly, we can leverage Har files, HTTP archive files that can be automatically generated. Your QA, for example, may be generating Har files with QA automation tools like Selenium or indeed CyprusIO amongst others. And we can also consume your swagger and postman collections in the form of a JSON or indeed YAML file format. So we’ve made everything very, very easy for developers to remain within their environment and to leverage multiple different tools that you’re already using in order to generate these scans. And if there are any any number crunchers out there, I always like to put a little bit there where we’re really about reducing the TCO. We’re a SaaS based solution, but really it’s about being able to achieve that security testing compliance on every build without the need for the manual validation. Without the need to lean on what can be a very, very overstretched and very small security team in many organizations and also to reduce your reliance on and indeed the cost of manual testing that you may be doing periodically. But from a security testing perspective, it’s all about being secure by design, minimizing your risk, minimizing your exposure to a potential breach. If there are, by the way, any questions, please do feel free to put those into the chat or the Q&A and we can answer those at the end of the demo. But here you can see really how easy it is to integrate and indeed to start automating your dynamic application security tests with NeuraLegion and CircleCI. So in this example, we can see here that the commits via GitHub in this instance CircleCI can be triggered. Our next DAST platform will then start to trigger the tests. It will then pass or fail based on the configuration that’s been set up. We can then go away and open up tickets in JIRA or any other ticketing system. We and indeed Circl CI have integrations with Slack, for example, if you wanted to do any other messaging. And we also have an open API for seamless integration across your environment. So really, regardless of how it is you want to use it, or you can also ultimately use our technology via the UI, which you will see. But for true CI/CD automation using CircleCI and NeuraLegion  is going to enable you to do that in a very, very seamless way. So without further ado, let’s, let’s jump in. So for the purpose of… let me just see if I could move this actually. And…let’s move this out of the way…there we go. So for the purpose of this example, you can see here I’ve got a CircleCI example pipeline. And you can see my projects. We can click on this specific CircleCI example that I have here. And there are certain project settings that you would need to set up initially to integrate CircleCI with our, with our, with our platform. And this would be the Nexploit token and indeed a repeater. And you can see these here. If I just get out of this, we can see these will be form parts of, here’s our CircleCI example in GitHub and we can see here that within the CircleCI example here we have our own config.yml that Zan showed you previously as well. We can see here we have details of the different jobs, indeed the different steps that will be carried out as part of our security testing automation with CircleCI. So we can see here what will be what will be run. We’ll have the install, the Docker compose as well as our Nexploit CLI via an MPM package. You can have full access by the way, for any further reading our knowledge base kb.neuralegion.com where you can see all the multiple different ways of using the Nexploit CLI either via NPM, windows installer, there’s a multitude of different information on how you can get set up and scanning using our, our technology. You can integrate that very, very seamlessly with CircleCI’s account, obviously which is also free. And you have a free account with NeuraLegion if you wanted to get up and scanning, if you if you go to our website and I’ll share the link at the end of the demo. But so we’ll install the Nexploit CLI here and you can see here that we have different commands. So here you’ll see we’ll be using the Nexploit token and indeed the repeater ID to carry out the tests. Once we start to run a scan, once the commit has been carried out in GitHub, for example, we will initiate a scan. We’ll call it CircleCI test. In this example, we’re actually using a local instance of Broken Crystals. Now, Broken Crystals. This is actually an open source, vulnerable benchmark application. Feel free to have a look at this if in fact, if you go to the NeuraLegion GitHub, you can also have access to this open source project. It’s a modern application with many, many different types of vulnerabilities within it. So we’re going to use that for the purpose of this, of this scanning. But please feel free to leverage that repository, our free account and indeed CircleCI to start scanning and playing around. And you can see here that once the scan started, it will be provided with a scan ID, it will poll and wait for issues. And we can see here that we have specific intervals for the polling at 30 seconds, this timeouts at 20 minutes that can be dramatically reduced. You can define that. We’re all about speed of testing and you can see here that our breakpoint is a medium issue. So a medium security vulnerability issue. And once that breakpoints been hit, we have it set to stopping the scan on fail, but that could be removed so that the scan can then continue to be processed, even though the builds failed to try and detect more vulnerabilities within that specific build. So in practice, how does it work? Well, we’re all about automating it. This, by the way, is the Broken Crystals repository under the NeuraLegion GitHub. So please feel free to look at that. But if we go back to this CircleCI example, just to keep things very, very simple, we have a simple read me here. We can see we had multiple bugs in this specific example. Why don’t we just go away and add a few more? And once we commit those changes, we should see that CircleCI has automatically started to build this workflow. This is the branch via the repeater, via the Nexploit CLI, and we can actually now start looking at the build itself. You can see, I must admit one thing that I’ve always been very impressed with CircleCI is the speed at which it works. It really, really does lend itself to automation from a developer’s perspective. And we can see here the different stages that it’s going to go through. It’s setting up the environment variables that I showed previously. It’s now just going to be installed in the Docker compose and it’s going to start polling for results. And here we can see this is the NeuraLegion dashboard. We have this in dark mode here, but just whilst that’s just, whilst that’s going, I’m just going to show you a little bit of what’s under the hood from a, from a scanning perspective. So you can see here for those that perhaps are going to immediately jump off this webinar and sign up for a free account, you can really get up and scaling very, very quickly with our with our standard or indeed quick step scanning process where you can very seamlessly just either add your URL to start scanning, you can upload a Har file and you can do the two conjointly or indeed you can upload an API spec as well, give the scan a name, pick a project which will just be defaulted and you can pretty much start scanning. But let’s look at more advanced options and let’s try and just explain the key features that I mentioned to you previously. So I mentioned here that you can use the crawler or indeed a Har file, an HTTP archive file, which is a recorded interaction with the target application. Your QA will be producing these when they’re doing their functional tests and you can actually begin to leverage their existing scripts to then start carrying out security testing. We also have the open API here where you can upload your swagger, JSON or YAML file format schema or indeed your postman collections to carry out those scans. And you can see here we have the smart scan and static parameter skipping. I’m just going to make that a bit bigger for you so you can actually see what that entails. So this is all about not having to be a security testing professional, a cyber security expert in order to carry out tests, putting comprehensive security testing going very, very deep, going very, very broad within your application to test your to test your assets, but without the need for very, very complex configurations, let our engine do all the heavy lifting. That’s what it’s been built for. So Smart Scan will use very, very smart decisions from our engine parameter skipping detection phases to try and minimize scan speed. You as a developer, you don’t want to be hanging around, you want to release, release, release. And our technology is built to complement that. And we’re always adding even more improvements to our technology to speed up those scan times. And that’s really, really what we’re all about, let alone the fact, again, that we are automatically validating security vulnerabilities so that you’re not having to deal with false positives. So those are some of the optimizations that we have. And for those perhaps from a security testing background, you can see here that we have a multitude of different security tests that will cover your OWASP top ten and Mitre 25 compliance, as well as our own proprietary scenarios, malicious payloads that we can attempt to exploit your vulnerability with. One key thing that I wanted to show here, a real key differentiator of our technology is our ability of carrying out business logic vulnerability tests. So this is not a security test per se or your traditional security testing, but we, leveraging our natural language processing, leveraging the reinforcement learning that we have, enables us to carry out logic based attacks. This is, can I manipulate or can I try and augment or go around the validation process? So, for example, can I withdraw money from a bank account that contains no money in the bank account? Can I withdraw Bitcoin from a wallet or from an account that hasn’t got any Bitcoin in there? That’s actually a real lot, a real case scenario that we demonstrated in a POC previously. Can I sign up for a bronze package? But can I get the benefits of being a gold member? These are all things that have always been done manually and our technology is now leading the way in, in being able to detect these in a fully automated fashion as well. So that’s just jumping into just jumping into the scan setup very lightly, but I’m sure if we go back to here. We can see that, let me see what’s happened there. The demigods were not with us today. Let me just have another look here. Uh, that’s. I’m going to start it again. I don’t know why that’s the case. And. I’m going to just reload. It is a good job that you can always, we can always attempt it again. And let’s see. Let’s see what the issue was. So just whilst that’s running again, there isn’t much. It is very quick, as I mentioned. Let’s actually now look at some example tests that we have and some example results, and I can go back to the results that we have within that specific one. But you can see here that once the build does eventually fail and actually I think we could go to a previous workflow actually and we can see here what you would what you would actually see here is this is one that I did earlier. I feel like I’m on a cooking program where I’ve baked a cake and it hasn’t risen, but this one has. You can see here that when it’s polling that the breakpoint would have been hit, we found a first medium issue. And then the next step, as per the configuration file that I showed you, would then be to actually stop the scan. Now, what would those results look like? So you can see here, this was actually a test that was run against the same target, Broken Crystals. In this instance, it was using a recording Har file and a crawler. They can be used at the same time. If you’ve got a specific, if you’re using a single page application, for example, the crawler won’t find 100% of the, they won’t find 100% of the attack surface. You can then supplement that with a Har file or indeed with the swagger file, you get a progress bar of the scan progress, discovered entry points, a number of parameters. You can see here the data that was sent in this instance. We also use CircleCI as you can see here. You get a full breakdown of the site map, what was detected, what was the attack surface that was leveraged against. And you can see we go very, very granular in terms of the attack surface and the parameters that we would have been exploited against. And then we have details here of the discovered issues. And the nice one to always demonstrate here is a reflective cross site scripting. Everything you see here, by the way, can be generated in a Jira ticket or any other ticketing management system. We’ll provide you with details of the specific vulnerability, and remedy suggestions with further reading. What is an XXS? How do I fix this? Where have I gone wrong? With developer friendly remedy suggestions, and we’re always looking to optimize these. Indeed, if you have any feedback once using it, please feel free to drop us a line and we can make those changes. We’re all about enabling developers to be able to fix things and we want things to not be in security speak. We want them to be in developer speak so that you can actually go away and fix these. And actually, you know what? If you fix it once, if you get pulled up on it early, you then won’t continue to make those mistakes. None of us want to produce vulnerable, vulnerable code. So it works really, really well. We can see here that we have a diff like review of the request, what was added and what was deleted in order to generate that. And all of this can be copied as a Curl. So you can then go and try and reproduce this specific issue, try and debug, remediate and fix. We provide the response, the body and I mentioned previously that we, we validate every vulnerability that we detect and we do this in a multiple of different ways, but we’re very, very active in our scanning approach, whereas typically security testing tools passively crawl, passively try to understand whether or not a security issue is actually going to be exploitable. We are actively scanning. We’re actually using a headless browser, browser automation and actually rendering the page. And here we have an automatically generated screenshot of this specific reflection of this reflective XSS, the specific pop up that came within this specific request. This, if you were a hacker, you could send an unassuming customer to a site that looked like your site and actually then start to do some quite nasty things. But that just gives you as a developer or indeed you as a security professional confidence that this issue is actually there. And you can then actually now start to prioritize your remediation. You can actually run a test against your larger assets, know exactly in real time where your security vulnerabilities are, start to remediate without the need to manually validate these issues. And we know how frustrating that can be. Let’s just have a look and see how we’re doing, by the way, with this specific workflow. There we go. All it needed was a little bit of a refresh. This one actually worked. We can see here that the breakpoint was hit during polling. We found our first medium issue. I can actually go back to our scans. And here you can see here was our CircleCI test. Thank you very much, demigods. And we can see here that we hit our first. We had multiple different issues. The scan time you can see was very, very quick, just over a minute against the number of entry points. You can see the number of requests that were sent. And in this specific issue, we found an open bucket. And again, with this specific example, we’ll provide you with all the information of what was detected. The response so that you have everything that you need in order to go away and remediate. And with CircleCI, you have the option of downloading the specific setup. You have the option here of if we go back to our workflows of re-initiating or rerunning the workflow from the start or indeed rerunning it from where it failed, if you wanted to then go away and remediate. And all of this can be also managed very, very seamlessly through the orb. And just to reconfirm that the NeuraLegion does have an orb with, with CircleCI, I would be showing it today, but our technology has gone through some rather substantial enhancements in terms of scan speed, in terms of detection capabilities, in terms of supporting some very, very complex and multiple different authentication mechanisms that we now need to just update our role. But if you’re watching this recorded, it will probably be done. So go, go ahead, download the Orb and start and start scanning in a very, very automated way. Yeah, all of the scan details, we’re looking at it now through our UI, all of this can be detailed in a ticket. You have the option here of exporting as a JSON or a CSV if that’s indeed what you prefer. Whilst most organizations are trying to move away from PDFs, you can export this as a PDF if you really wanted to, but really stay within your environment. This is showing you what it looks like now as part of the UI. And just as a reminder, again, you can sign up for a free account. This is what you’ll see, but you’ll be able to set up the repeater user utilizing a very, very easy to follow, very, very quick step wizard to take you through the setup process so that you can be up and scanning. And I know more than anyone just how easy it is to do the same with CircleCI as well. So I think I’ve covered most of what I wanted to show you. You can really see truly how easy and seamless that process is. The only thing I probably want to just just finish on, just as a reminder is what you need to automate. So whether you’re using CircleCI already or not, certainly that’s something that you want to be doing in order to automate that CI process. But from a security testing perspective, it’s the multiple discovery methods that I think is really, really important. Whether that’s crawling like I showed you, where you can just point it at a specific URL and let our engine do the rest. You need to be able to leverage your Har files which can be generated per build or commit as well. And this enables you to very, very much define the scope of the test so that you can test a specific feature, specific entry point or specific page of your application or your QA colleagues can then actually also start to use the technology to upload the Har files that they’ll be generating as part of the QA automation. Again, for API, we can support and consume the swagger or indeed postman collections. We have that very, very simple configuration via YAML and the automatic scan optimizations that our engine does so that you’re relying less on your security team, whether that’s against your web applications, single page applications, full support for web socket based architectures and of course the APIs that I’ve mentioned. But the key really is you don’t want noise, you don’t want false alerts going off, you don’t want your builds with CircleCI failing for no reason. You want to fail for a specific reason, a medium or high severity issue that should not categorically be being shipped into production. Something that you can fix quickly without the need to then rely on your security team to get it done, reduce your cybersecurity exposure. And of course we integrate with CircleCI amongst many others. So yeah. And we can move on to a Q&A. Zan I don’t know if you had anything to add, by the way, on that or indeed if there are any specific questions that any of the listeners have. 

Speaker 1: Nothing to add on my end. Thank you for a very thorough demo. This was really cool to see all happening practice. We do have a few questions. So first one was, is it going to work with Bitbucket Cloud as a source code as well? Yeah. So CircleCI does work with Bitbucket. So the same as you would sign in like with GitHub, you could do it with Bitbucket and then run your pipelines exactly the same way. And from those pipelines you could call NeuraLegion with your application to initiate the security scanning, which should all work the same. Uh, so that’s one. And the second one was you mentioned free sign up. Can you share the link for this, please? 

Speaker 2: I can, yeah. It’s actually in front of you. Am I still sharing? I am, yeah. You can see it here. So you’ve got details to our knowledge base kb.neuralegion.com. And you’ve then got the free account sign up nexploit.app/signup. Please feel free to sign up. You can literally do it whilst we’re going through the Q&A. There’s a very, very quick step, easy wizard, that it takes you through the process. Let us know, let us know what you think. And actually, whilst I remember and I didn’t put it on here, but maybe I will, or I should have, we also have a discord for any support that you may need, just search NeuraLegion on the discord. And if there’s any questions, if there’s any assistance or support that you may need, feel free to shout out and we’ll be more than happy to assist. 

Speaker 1: Awesome. Yeah. And for CircleCI the same, you go to circleci.com, there is a login and sign up links in the top right corner of that page and you basically just authenticate with your VCS provider. So GitHub inbucket, and that’s essentially signing up for CircleCI. 

Speaker 2L Yeah, great. I can see there’s… I’m not sure if there’s…um, there’s chat, actually, I can see here. Oh, that was Max’s question about Bitbucket. Okay. 

Speaker 1: Exactly. Yeah. So we covered that. 

Speaker 1: Yeah, So I can see. Um. Let’s see. So yeah, I suppose just to, to sign off. Of course, you know, all of the features that you saw within this video can be very, very much seamlessly automated and integrated into your environment. You know, remove uncertainty, start trusting the tools with no false positive reporting of your security testing. We’re really about automation. We know how seamless it can be with our clients that are utilizing our technology with CircleCI. And I’m sure that if you look out in the future, we’ll do perhaps a more in depth workshop around this very, this very example of integrating NeuraLegion and CircleCI. If you do have any questions, please feel free to either reach out to me directly via Twitter at appsecOli and your Zadmarkan I believe on on Twitter and of course yeah and you know in relation to the free sign up if there are any support related issues that you may have or any questions, then please look out for the NeuraLegion Discord Channel. We’d be more than happy to assist wherever we can.