Automate WebApp Security Testing using GitHub Actions (from StackHawk team)

Welcome to Test.js workshop. Invitees and attendees, it's great to see everybody on here. I wanted to welcome you to our little show that we've got, what we're going to do today is. Automate web app security testing using Java and React. Is a web browser.

It helps to have a Discord, the Discord app, we're going to be doing a lot of chatting in discord, and I'll tell you about that in a minute. But what we're going to do basically is we're going to, we're going to fork a repo for a sample application, a node.js application. And what we're doing in this workshop is we're going to ask you guys to submit questions application, a node.js application. And we're going to subject that to an automated build and test routine using GitHub actions, which is GitHub's CICD system that's built into GitHub, and it's free for use for anybody for up to, like, 2000 minutes a month, something like that.

So we're going to build that application, and then we're going to subject it to a bunch of testing, a variety of different security tests. And again, all you really need is a web browser, because everything we're going to be doing is through the GitHub web interface so that we can create files, fork a repo, create file, the files that we need, run the test that we need using GitHub actions and so forth. What you need for this, really, the primary thing that you need to join us is to join our Discord. And to join the October 2022 web app security testing channel in Discord. So, I'm going to post that link here for everybody. So, if you can go to the first link that I provide, the discord.gg.xnmb.. Click that link and you should join our Discord server. And then from there, in the general channel, just give a thumbs up to our welcome message. That'll allow you to see the rest of the channels. Then once you're there, join that October 2022 web app security testing channel. And then when you get into that web app security testing channel, give us a thumbs up there too, so that we know that you're in there.

We already have a question. This is awesome. So, it seems that I cannot check out the repos. Don't worry about that. You can just look at the repo through our website. We're just following along in the readme that's in there. So, I'll show you what that looks like. When you get to this workshop GitHub actions GitHub repo, all you really need from there is this readme, and you can click on links to get to stuff in there.

The first thing we'll be doing when we create the app is we're going to fork another repo. All right. Looks like we've got folks joining in on the discord server. A GitHub link in the discussion panel window. I think we mean this window. So, let me give you this link. So, here's the workbook, or the guide book for the workshop that we'll be going through. If any of this stuff is not working, you should still be able to follow along. Again, really all you need is a web browser and access to GitHub, so a GitHub account. I'm going to go ahead and begin. Feel free to drop questions and help each other out in the Discord chat. And Mimi, if you can help folks along who are running into trouble, that would be awesome. I'll just begin with a slide. Thank you.

All right. So, here we go. We love questions, please drop us a chat in the Discord. We love to help out. My name is Zachary Conger. I'm a solutions architect for StackHawk. I have some hobbies. I really like DevSecOps and this whole workshop is about DevSecOps routines and practices. It's a really fun workshop. You can take everything that you learn from here, it should be really useful in your work life, as well as your own home, personal projects for working on your own applications. Securing them, building them automatically, that sort of thing.

So, I want to tell you a little bit about the cloud, about the company that I work for, StackHawk. It is one of the tools that we'll be using at the end of this workshop. And what we do is we've got a security scanning tool. It's called a DAST utility, that's the class of security scanning tool that it is, which means that it's a dynamic application security tester, which means that it runs against your running application. It actually probes your running application for vulnerabilities by sending in malicious requests and looking at the responses. And that class of utility DAST has been one of the hard ones to automate in CICD. And we believe that we've cracked that difficulty. A couple things about us, we're closer to the code. We are a developer-oriented tool, easy to automate in CICD. We've got great coverage for web applications, as well as APIs. And we've got a really simple configuration that just requires a YAML config. And we'll talk more about that later in the workshop.

Our agenda today is going to be to use GitHub Actions to automatically build a node application. Then we're going to add a bunch of tests to that build process that we're going to set up. So first one is going to be a tool called Dependabot. It's another GitHub tool that can be used to scan your dependencies and look for vulnerabilities in those dependencies. Then step three is going to be we're going to add code, we're going to add CodeQL, which is another GitHub utility. And that's going to scan your code base and look for vulnerable patterns in the actual code of the application and flag anything that looks like it might be dangerous. And then the final step is we're going to add StackHawk, that's our Dask scanner, and it's a dynamic scanner. We'll use that to scan an instance of the running application in the pipeline. So this build pipeline at the end of it is going to build your application, test it with for dependencies, for dependency vulnerabilities, test it for code vulnerabilities, and then finally test it for run time vulnerabilities. All right, so the first step is going to be to set up our GitHub actions.

So GitHub actions, if you haven't heard about it, it is a CI CD system that is built into GitHub, everybody has it available as long as you've got a GitHub account, it's free, so in your free GitHub account you can use this for your own codebases. It uses a simple yaml configuration language, and it's got a huge marketplace of what they call actions, and actions are like Jenkins plugins, if you've ever used Jenkins, they're basically little packages of functionality that make it really easy to put together a build pipeline that does really interesting things. You can use it to build Java applications or node applications, you can use it to run all kinds of various tests and so forth. It's event driven, so you can really put together very complicated and sophisticated pipelines using it, you can hit it via API. It's got built in secrets management, which is really important for security testing and for security in general because there are some things that you want to be pulled into your CI CD pipeline sometimes like maybe passwords or API keys, but you don't want to put that in your GitHub repository because that can be a security vulnerability in itself. For other people, it might come into contact with people who you don't want to know what those secrets are. And finally, it is free, so you can use it for, you get 2000 minutes of build time free per month, which is really quite generous. So to begin, let's just go ahead and do that. So if you should be logged into GitHub and we are going to, what we're going to do is we are going to fork this application called Vulnode Express in the Kaka repository, and we will provide a link to that. Mimi is dropping a link into the Discord and we should probably drop it into the Zoom chat as well, just to be sure. So when you get here, what we're going to do is just fork this application. So from this main page from the Vulnode Express code repository, you'll see, of course, all the files in there. This button up here that says Fork, just click on that and you're going to fork this application over to your own repository, or your own organization. So my organization is called EConger, you might have a couple or your own personal one, just make sure you're pointing at your own repository and hit Create Fork. So again, from this repo, I hit the Fork button and then I entered the name of the repository that I want to copy over. We'll hit Create Fork. And in just a couple of seconds, you should have a fork in your own organization.

So now I've copied it from Kaka to my own org, EConger. It's called Vulnode Express, and it tells me that this was forked from Kaka, Vulnode Express. And Mimi, let me know if there's any questions if you need me to back up or anything and go over something. Totally. I think we're all good so far. I'm answering a couple of questions in the chat. And, everyone, if you could give a thumbs up to each step in the Discord along the way when you've completed it, just so that we know you're good and so that we can custom the pace to know if we need to slow down or clarify anything for you along the way. Cool. All right. So from here, what we're going to do is I'm going to refer back to this guidebook. So we've already forked the Vuln Node Express app. Now we're going to go into the code section and we're going to create this new file. The file is called, it's in the.github directory slash workflows slash build and test dot YAML. And we're going to copy the contents of this file and just drop it in there. So I am actually just going to copy and paste from here, first thing I'm going to do is create this file. To do that from the Vuln Node Express fork that I created, go to add file, create new file and paste in the name of that file and it should fill it in for you. So.github. So remember the dot at the beginning of that slash workflows, slash build and test. This directory structure, by the way, is special to GitHub. GitHub puts a lot of different files that it may look for in the process of GitHub operations. And this special directory.github slash workflows, any file that GitHub finds in there, it's going to regard as a GitHub Actions workflow and it will try and run it. So when it sees this file that I'm about to copy the contents of, you just hit copy there and drop that in there. So when it sees this file, it's going to try and determine if it is actually a workflow. And if it is, it's going to try and honor it and do what the workflow says it should do. And let me describe exactly what the workflow says it's going to do. So the workflow is called Build and Test, it's a GitHub Actions workflow. And this build and test workflow is going to be triggered anytime we have a push to the main branch, or any pull request at all. So if we do pull requests to main or any other branch, this whole workflow should kick off. What does this workflow do? It's got one job, and you could have multiple jobs, but this one's just got a single job called Build and Test. And it runs on an Ubuntu 20.04 instance, this is a full VM, it's got about 7 gigs of memory, it's got some additional disk and it has a ton of different tools, so generally it's a very well populated server that's got a lot of different tools that you might find handy for building and testing code. Then we're going to go through a number of tests, steps, and these steps use actions and actions again are like these plugins, these packets of functionality that GitHub provides. First one is called Checkout v3, and so anything that starts with actions, if it's a GitHub action, this is actually a GitHub created action, so it's one of their standard actions and all it does is check out your codebase and it figures out the right place to check out your codebase. I have a question, can I repeat how to find the path to that file you're showing right now? This file? So if you're from the reading, it's under step one and it's called.github.workflows build and test and so you're just going to create that file from the GitHub UI and I'll go back and step through it in a minute. So thanks for that question. Anyway, so we check out the code and then we're going to install Node.js14x so that we can build our Node.js application and again we're using a GitHub official action called set up node and it just goes through the difficulty of getting the right version of Node installed, which can be a hassle getting the right version of NPM installed. Then we're going to install dependencies and this is going to go through NPM install, just like it says, and then we're going to run unit tests if there are any and spoiler, we don't actually have any unit tests, but if we did, that's what this step would do. So now, if I scroll to the bottom and hit commit new file, we will have created that file under.github workflows. The build and test file is now there and now you should be able to go over to actions and see that that workflow is running. This would be a good checkpoint if you can let us know if you are seeing your own workflow running. Should be called create build and test. I will go into build and test. This is the commit message that we made, and if I jump in here, you can see that the one job that it has called build and test is running and you can click on there and see more details about what it's doing. So, it set up the job, it checked out some code, spinning out a bunch of garbage. It installed Node.js and NPM as well as running a single step, so it's installing dependencies, and that really is all that it's going to do. And then, it will run unit tests, but we don't have any, so that step should go pretty quickly. So, I'm going to step back and just walk through that process that I just did one more time. So, we've got the workshop guidebook, and I'm just copying and pasting from it. And then, I'm going to select your forked repo, this should be your organization name, whatever your name is in Github, bulnodexpress. I'm adding a file. That file name is.github slash workflows slash build and test.yaml.

And then once you do that and start filling it in, I'll click Go From Here, then you can hit Commit New File to create it. And just by having committed that, you will have fulfilled one of the, you will actually run that workflow because once you commit something to the main branch, this workflow says that Github Actually should run this workflow. So once you put this file in, and we'll see that it's got a job that it needs to do, it'll read through the steps and it will run them in Github Actions. So by now if you've gone through all of that it usually takes a couple of minutes, but you should have a complete job, should've completed successfully, and you'll have a green checkmark. Again, to see your Actions running, you go over to this Actions tab, the workflows that you've set up for this repo, and you can see individual runs. So as we run more jobs in here, you're going to see this list fill in with more and more commits that kick off more and more builds.

All right. How's everybody doing? It's alive. Excellent. Cool. Is it alive for everyone else? Give us a thumbs up. Awesome. Does it appear twice? That's interesting. If you did two commits, I think you might have done two commits, which is okay. Every time you do a commit to the main branch, you'll see another action run. It doesn't matter how small the change is. You can do even empty commits, and those will cause the workflow to run.

This is great. It's great to see everybody playing along here. It's always awesome when there's participation. All right, so that's GitHub Actions. So we've got a simple workflow, and now we're going to add some security testing to all of this. So now I want to step back for just a moment and talk about these types of security testing that we're going to do and the characteristic of each one of them and what problems they're designed to solve and what the pros and cons of each approach are. And basically, what I'm going to conclude is that it's really good to have all of these tools in play if you can, but some are better than others at giving you really actionable and information that you can really use to prioritize where you want to focus your efforts, especially in a team setting.

So the first type of security testing that we're going to do is the easiest possible one and that's software composition analysis. And the way software composition analysis works, also known in the industry as SCA, is that it really just looks at your dependencies. So there's a bunch of different tools out there that do this and they can operate from your artifact repository like NPM. The NPM Cloud service has a feature like this built into it. JFrog artifactory has a feature built into it. There's also tools that run in your code base and can check out your dependency file and look very deeply into it and figure out if you're pulling in any dependencies that have known vulnerabilities, basically. So when these utilities run, they're generally really fast and they're really easy to act on. And in fact, a lot of these utilities will provide remediation for you. The one that we're going to use is called Dependabot, it's built into GitHub. And when it finds vulnerabilities in your dependencies, it will generally open a PR to your codebase and say, Hey, I have a fix for this. All you have to do is accept this PR. And when it opens that PR in our case, since we've set up GitHub Actions to rebuild the app, it's actually going to go through the build and test phase and make sure that the change that it's trying to make is okay and doesn't break your code. So that's Dependabot, that's SCA.

The next form of testing is called Static Application Security Testing or SAST. And this is a more sophisticated form of code analysis that actually looks at your static code. So to look at your entire codebase, so it's language dependent. It needs to understand your codebase. And the one that we're going to be using today is called CodeQL. It's this little icon here and CodeQL does understand Node.js as well as Java, TypeScript, it understands C Sharp, it understands a lot of languages. And what it'll do is it'll try and compile it and sort of index it in a searchable form. And it's going to analyze that codebase for patterns that look like they could be vulnerabilities. So for instance, it might look for user inputted variables. And if it see a user inputted variable and you use that inputted value to create a SQL query, then it's going to make sure it's going to look and make sure that you've sanitized that variable before using it in the query. So that so that the user can't inject malicious characters that could be used to do bad things to your SQL database. The cool thing about tools like this, about SaaS utilities in general, is that they can give you really specific information about where the problem is in your code. They can point to the exact file and the exact lines of code where the problem is. And it finds your bugs that you have written, not just bugs in your dependencies. The problem with it is that it has a lot of high false positive. It's kind of a hard thing to do to test for these things. And when it does find findings, even if they are accurate findings, what they're showing you are potential vulnerabilities. They can't really prove that these potential vulnerabilities really exist in the runtime application. So, pros, you can get to the file online where the problem is, and that's a lot of really useful information to developers.

Cons, they might not be real bugs. So, it's hard to prioritize fixes based on results that you get from SaaST. Finally, Dynamic Application Security Testing, or DaaST, is the kind of tool that StackHawk provides. There's a bunch of examples of it out there in the wild. awasp.zap is an open-source type of utility that's completely free for use. There's another one called burp.sweep that you may have heard of. It's sort of the big – it's the big old DaaST utility that most people in this space know about. The way this utility works, or these types of utilities work, they operate on a running code. So, you actually have to stand up your application and then run the scanner against that application. It will send in inputs and it will look for outputs. What it's trying to do is prove that it can exploit, for instance, a SQL injection attack. So, it will try and do a SQL injection attack and gather evidence that that attack was successful. And then if it thinks that it's found vulnerabilities, it will tell you what vulnerabilities it found. And it will show you those input and output details so that you can recreate the problem, and hopefully fix it and be able to verify that you've fixed it. Again, it finds your bugs. It tends to have very low accuracy, it finds your bugs, it tends to have very low false positives. And when it finds problems, it is generally it has confirmed vulnerabilities. It has actually tried to exploit those vulnerabilities and shown that it could exploit those vulnerabilities. So, those are the things that we're going to test and we're going to start with SCA. And I'm going to pause for a moment and see if there's any questions.

We do have one question. It's the Discord link. So, let me give you that. So, I'm copying the Discord link to the Zoom chat. So, join there, give us a thumbs up on the general page. And then please join our October 2022 web app security testing channel. There you go.

Okay, cool. Moving on, our next step is Dependabot. So, this one's going to be really easy to set up. Let's go back into… Actually, let me tell you just briefly about Dependobot. So, Dependobot is a free service for all GitHub repositories. It is enabled by default on any public repository. So, if you just create a public repo, it should be enabled by default. It's also easy to add to private repos, and that's what we're going to do now. Because we forked it, it didn't enable it on it by default. It wants you to enable it explicitly, so we'll do that. And that's exactly the same process you use for a private repo. It's also free on private repos. You can use this on any of your code. As we mentioned, it finds libraries with vulnerabilities, and it automatically issues PRs for any fixes that it thinks that it can do. And those PRs, of course, will run through any automation that you have. So, those PRs will kick off the GitHub Action workflow that we already set up. It does have some false positives in practice. You should definitely always follow its advice if you can and stay up to date. But sometimes it's false positives, just in the sense that your code base may not use enough of the library to expose the vulnerability that is known to be present in the vulnerabilities that it finds or the libraries that it knows are vulnerable.

Let's move on. So, what we're going to do is go over to the... I see how I described it in here, because there's a couple different ways to get into this. We'll go to the Settings section of the repo. We're going to find the Code Security and Analysis section. And then we're going to enable the dependency graph, dependency alerts, and dependable security updates. So, from your cloned repo or your forked repo, go over to the Settings tab, and then find the Code Security and Analysis section. We're going to turn on the dependency graph. So, this is the feature that's going to allow GitHub to look for and find your dependencies file. And in this case, it's the... what is it called? Package.json file and the package lock.json file, so it can understand what dependencies we're trying to pull in. Then, we're going to turn on dependable alerts so it can let us know when it finds vulnerabilities. And then we're going to turn on dependable security updates, so this is what's going to allow GitHub to open PRS for any vulnerabilities that it finds. If you want, you can also turn on version updates, so not only is it going to look for vulnerable libraries, it's just going to look for, hey, is there a new version of any of these libraries that you've pulled in. I don't turn that on myself, but you're welcome to it'll find a lot more stuff in that case. Let's skip code scanning for now, we'll come back to that in a minute. So if you've done this, and again, the path to get here is, go to settings, and then code security and analysis, and then turn on the dependency graph, depend about alerts, and depend upon security updates. And if you have done that, then you should already see some security updates because it's so fast, it was already able to determine that I've got a bunch of libraries that are problematic. So come over to your security tab, where you should have a badge says 18 or so in my case it's 18. And then we're going to go into the dependent bot section over here. And we can see what those problems are. And there's really quite a few critical and high security issues. I'm going to stop for a moment and see where folks are at.

I'm going to stop for a moment and see where folks are at. Got a couple chats in the zoom. Looks like we're good. Awesome. Looks like a bunch of people are catching up here. This is great.

Okay, so, a couple things to notice from this page. First, we've got, like, alerts for issues that we're finding. So we've got prototype pollution in Minimist. So I've got a library called Minimist, that's an npm package. There is a critical vulnerability in that. Over here, you see this pull request indication, so it's already opened a pull request for that issue. And we're not going to merge those pull requests right now, but later on, after the workshop, feel free to try merging in some of those pull requests. I walked through this workshop just yesterday and found that all those pull requests were pretty safe to apply. But I'll show you what that looks like in just a sec. So you can drop into these and they'll give you even more detail typically and link out to other information for these issues, and obviously, you should definitely address any critical issues in your own code and high issues as well. Moderate and low is also good to keep up on, but not quite as important.

So I'm going to click on one of these. So this is showing me what PR this opened up to try and fix this vulnerability. And you can see it actually created a pull request, and I've got a bunch of pull requests now. And it's tried to merge this into the code base, and then it ran any tests that were applicable. So you can show all checks. And this is our workflow that we use. And this is our workflow that we set up in our first step. And it ran through it and found that there were no problems. Nothing broke. All of the tests succeeded. So you could just merge this in. I won't, but if you do, it will kick off that workflow again and try and run all of those tests. Backing up into the whole pull requests section, you can see that there are a bunch of pull requests. They all have this tag dependency. And they were all opened by Dependabot. And just to round out, you know, what we're seeing here, if I go over to actions, you can see all of these new actions, workflow, runs. Each one of these has tried, you know, updating the code based on the PR changes. And then it ran through the workflow again. Built out our Node express application, tried running all of the unit tests. That's basically all there is to it. As you can see, it's really super easy to work with. So now I want to move on, unless we've got any blockers out there that we need to address. I'm sure Mimi will let me know if there's anything critical I need to back up and repeat. Yeah, looks like no questions at the moment. So I think we can keep going. Nice. Okay. Next step, CodeQL. So again, this is the SAST utility. It's a code analysis engine. And what it's going to do is compile our code, really in our case since it's JavaScript, it doesn't even need to compile it. And it's going to try and run through the code and look for vulnerable patterns.

And it's going to try and run through the code and look for vulnerable patterns. We'll see if it finds anything. A couple things about CodeQL, it is free for use for public repositories and our repository is public since we forked it from a public repo. So we're going to be able to turn this on for free and use it. If you want to use it on private repos, you do need to use the GitHub security license and that does cost extra. But if you've got any public repos, your own personal projects, you can use it as much as you like. It will use GitHub Actions. It's going to add a GitHub Actions workflow to go through its own testing. So you do use minutes on GitHub Actions, but again, they bake in a lot of minutes per month for free. So it's pretty cheap to operate on public repos.

Okay, so let's do it. So, again, actually this time, we're going to go to the security section of our repo. We're going to click on a button called set up code scanning. And then there should be a big green button that we can use to configure code QL alerts. And I think this path has changed just slightly but we'll work through it together. It's going to create this new workflow in the same directory as our old workflow, called CodeQL analysis. And then it's going to run it as soon as we commit that to the repo.

So from your forked repo, Volnode Express, head over to the security section and then go into the code scanning section and configure scanning tool. When I do that, it used to be that the default was to just do code QL analysis, but they're trying to show that there's really a bunch of security tools that are available here from other companies, from the open source community, and so forth. We even have one in here that you can use. I think we're down here somewhere. Anyway, we're in there somewhere, but today we're gonna just use code QL analysis. So hit configure here on the code QL. And that'll take you over to this new code QL.yaml workflow file. So this is another just standard GitHub Actions workflow. And what this is going to do is it's going to operate any time we try and push to the main branch or open a pull request to the main branch. And here's another kind of cool feature of GitHub Actions. It's also going to run this manual, so once a week it's going to run this whole code QL analysis. Those are the triggers. And then the job that it's got is just a single job called analyze, and it's going to use some more advanced features of GitHub Actions. So it's going to use a matrix strategy. And this comes in handy if you've got multiple code basis, but it only found one language in our code base, JavaScript. And so it's just going to run that. But if you found, but if we found, like, some JavaScript and some Java and some Go, it would create this matrix and run all of the analyses for all of those in parallel in a sort of matrix run configuration. Just kind of a standard CI-CD concept. But they do it in a really nice, simple way. So anyway, it's just going to run that. And it's going to do this with a single type of endpoint. So anyway, it's just going to run against our JavaScript code. It's going to check out the repository. It's going to initialize code too well. Again, through this matrix of languages, it's only going to find JavaScript. It's going to try and build that. It's got an auto build routine that tries to discover and understand how to build our app. In our case, it's going to be really easy. Then it is going to run the analysis. And finally, let us know again through the security tab if it's found any problems. So I'm going to hit commit. And once that file is committed, again, and don't worry, you don't need to do any changes. Once that's committed, we should be running the action for it. So over in the actions tab, you should see you got two new jobs running. One of them is our build and test job, and the other is the CodeQL job with a CodeQL workflow. So we could click into the CodeQL workflow specifically and see how that's coming. So we've gotten to the part where we've initialized CodeQL, we ran autobuild and now we're running the analysis, at least in my case. And this can take a couple of minutes. It's a bit more complex and compute intensive than SCA checking. So just watch your action and let's see how long it takes to finish. And then at the end of it should have a couple of results for us and we can go check on those. Hopefully it won't take too long. I should have some nice whole music now.

So once we see results, they should show up in this code scanning section of the security tab. So I'm going to find my product and install. Still running that CodeQL workflow on my side. All right. And then I'll loop back around and see if anybody else got the same results. So again, go to the security tab, code scanning section, and in here you should see one finding, database query built from user controlled sources. And what it tells us is that it found in our service slash search.js file on line six, this line and this exact section of code that it doesn't like very much. So what we've done here is we are creating a SQL query that we're going to submit to our database back end, and as part of that query, we're dropping in some search text that the user inputted. And that search text is built from a user provided variable, and the code analysis has determined that all we did was accept that text from the user, put it in the variable, and then use it in this SQL search. We didn't do anything, it didn't find any other instance of that variable where we were checking for problematic characters, like percent quote, which is an escape character that can be used to inject another SQL command into the query. And so it's possible for users to use that to inject other potentially malicious MySQL queries. And we'll see later on that this is a real bug that CodeQL turned up. This really is something that you should pay attention to. But the other cool thing to notice is that it's telling you exactly what you need to do. If a database query such as a SQL or NoSQL query is built from a user-provided data without sufficient support from a SQL service, with sufficient sanitization, a malicious user may be able to run malicious database queries. And that is totally true, and you can with this application.

All right, I will stop for just a quick moment and see if there's any other questions or see if folks have caught up. Looks like we're doing good. Nice. Awesome. People are seeing the same thing I am. Supercool. All right. Let's go on, then, to the next step. And of course, pull me back if there's anything I need to go back up and show.

So the final step is StackHawk. And again, StackHawk is the company that Mimi and I work for. We think it's a great tool. Obviously, we're biased, but it really is a unique tool in this space because DAST is kind of one of the old standard types of security tests. And it's often considered to be a gold standard style of testing because it operates against your running code. And it actually tries to exploit vulnerabilities and gathers evidence that it was able to exploit those vulnerabilities. So when you find vulnerabilities with a DAST utility, you know that they are worth prioritizing because they are for real. And if you run these applications in public, you're going to get people trying to attack and exploit those vulnerabilities. So it's a really useful tool for prioritizing what you're going to work on in a team setting in terms of security bugs. But in the past, you know, with the older utilities, it's kind of hard to work with. They tend to be these big applications that are time consuming to configure and operate, and they generally have been run manually. So the same kind of tool that penetration testers will use when they do a penetration testing engagement. And so they tend to run on the same sort of frequency. People will use them once a month, or maybe once a quarter. And the problem with that is that it's very infrequent, and when they find vulnerabilities, then it's hard to go find where those vulnerabilities are.

StackHawk's approach is to create this portable scanner that's really easy to run and easy to run in automation. And that's what we're trying to get to, is just like those other tests are tests that can run on every PR, we want DAST to be a test that you can run on PRs as well. Because if you can catch a new vulnerability on PR, you know that a PR generally tends to be just a small amount of code change. If you run a DAST scan and see, hey, I've got a new vulnerability on this 20, 30 lines of code that I just wrote, then you're in the best position to find and eliminate that vulnerability and retest and see if you actually got rid of it.

So to that end, StackHawk, it's a portable scanner. It's based on the open source tool, OWASP Zap, but we've added an online SAS platform so that you can track all of your scan results scan after scan. Really makes it more usable, especially in a team setting. It's got a simple YAML configuration as opposed to ZAPS generally GUI driven configuration, and it's really easy to integrate into CICD. We also have a bunch of other integrations and one of the big ones is the JIRA integration so that as you find vulnerabilities, if you can't fix them in real time, at least you can create tickets out of them so that you can prioritize them and have other people work on them later. We've also got a bunch of deep API and graph QL testing capabilities that we've added to this, which we think is pretty unique. So you can do really interesting API fuzzing things and inject your own data or inject really realistic fake data into your API scans. And we've got a free developer account for one app. So let's just jump into it. So what we're going to do is we will go over to app.stackhawk.com and sign up for an account, and this is going to be a free account. But all you have to do is go to app.stackhawk.com, and Mimi is typing in that address so you can follow along. And you can set up a new account. You could use your GitHub credentials or your Google credentials, which I'll use today, or you can set it up with your email address. If you set it up with your email address, it's going to ask you to create a new password and then it's going to send you a verification email, so you need to go check your email and verify. I recommend Google or GitHub just for ease of use. All right. And I'm going to use my personal account. And when you set up your account in GitHub, the first thing that you're going to see… hang on, let me check the chat. Cool. Okay, so the first thing you'll see is this if you've used Google or GitHub. So it just says, hey, here's what I know about you. Here's your organization name.

I'm going to call it my workshop org to keep it distinct from I have a couple of accounts. And then just hit continue here. Next up, choose your adventure. Let's go with the default, scan my application, because we're going to just scan the application that we've already been testing. You can, you know, you can go with Google firing range that just injects a bunch of sample data so that you can start looking at Scan results without actually having to run a scan. But we will pick our stack scan my application and hit continue. And then now you should see this. So this first step in this setup wizard, is basically telling you how to install the stack clock CLI. If you want to, we don't need to worry about this today and we've got documentation on how to do this. So you don't have to worry about this step, but you do need this API key. Because again, we're just going to run this in CI CD, we're going to add a step to our GitHub Actions workflow that will just run this for us. But we do need this API key. So grab a copy of that, stash it locally so that you can come back to it. And what we want to do is we're going to set this API key up. Thank you, stack hop helper. By the way, that chat bubble actually does go to people behind the scenes who can help you out if you have any trouble. Okay, so I'm going to grab a copy of this API key, and then let's go back to your repository and go into settings and we're going to stash that API key as a secret. So under Settings, way down at the bottom, under Secrets, you should find an actions section. And we are going to add an actions secret. And I'll step through this one more time. So we'll create a new repository secret. Please call it hawk, all uppercase, hawk API key, hawk underscore API key and paste your value in there. And that's just because our canned configuration is going to refer to this secret to inject, to use this API key in the future. So I'll add that secret. And again, the path to get there was from your fourth repo, go to settings, secrets and actions, and then hit new repository secret. Give us a thumbs up if you've caught up. And now, I'll go back to this StackHawk application and continue. We'll hit next. Let's give it a name, I'm just going to call it the same thing as my repo, bone node express. And I'm going to call it the development environment. And the point of this environment name is really, you can scan a single app across multiple environments. And we just bucket scan results by environment. You may have different characteristics in different environments that would give you different scan results. And that's why we do that. This application is going to be running on local host port 3000 in the build pipeline that we're going to set up. So, just enter HTTP local host 3000. I'm going to paste this in. That's the name of your host that you should be entering in the host section here. Important thing to note, it's HTTP not HTTPS. The scan will fail if you do HTTPS. Because when we bring up the application, it's just going to be listening on clear text. Next. And then the application type. You can actually just say skip for now or don't know. The other options will sort of ask more questions. Like if it's an API, we can pull in various information to know more about that API. Or if it's GraphQL, we can, you know, we can ask you if you've got a schema file or if you can point to an introspection endpoint. So, these are the two options. If it's a linux environment, it's basically say, you can point to an introspection endpoint, and so forth. We'll just skip it for now.

We're going to do a very basic scan. Hit next. And then in the final step, you should have this sample stackhawk.yml configuration file. And really it's just these basically four lines of code that are important for that configuration file. And in it, we've got the application ID, which is the ID of this application in the stackhawk system, the environment development, and then the host that we're going to scan. So that just tells the scanner everything it needs to know about the scan that it's about to run.

We'll copy that. And we're going to paste that into a stackhawk.yml configuration file in our project. And again, we're just going to go through the web browser in GitHub and go set this file up. To go back to the code section, I'm going to add a file, create a new file. File is called stackhawk.yml. YML, not YAML, although I think actually both will work. And then just copy the contents of that file in. And yours should look pretty much like this. First thing I'm going to do is create a new filename. And I'm going to call this app, application ID, environment, and host. And then what I hit, we'll commit this file. And that'll kick off our workflow, but it's not scanning quite yet. We need to add something to our workflow file for this to work.

So we've made sure that the application exists in the system, and we're ready to scan. So again, I just created a new file called StackHawk.yaml, pasted those contents in and committed this file. And now to get that to run as an action and to get it to actually scan the application in the pipeline, we need to go into GitHub workflows. And add a step to our build and test configuration file.

Before we move on to that, Zach, it looks like we're still waiting for people to finish the setup of the StackHawk account. So we'll give you guys a couple more seconds and please drop any questions or give a thumbs up. Oh, the thumbs ups are rolling in now. Nice. Yeah, I'm just going to race through that one more time. In case anybody missed a step. So that configuration wizard is going to look pretty much exactly like what I'm about to do now. If I hit add an app, I just called it the Vuln Node Express in the development environment against host HTTP localhost 3000. localhost 3000. Then I called it skip for now I don't know. And copied and pasted that into a new configuration file stackhawk.yml in your code repo. I'm going to remove this new application, though actually I don't know if I can, I'm going to leave it. I don't attempt fate. Don't attempt the demo gods OK so we got a question in the chat about stackhawk accounts that says the website says free trial is 14 days and you had mentioned it's free for one app. Can you provide a little clarity on that sock? Yeah, absolutely. So when you set up your new account it is set to a 14 day format. The free trial of the enterprise feature set which provides a whole bunch of additional functionality. So there's. There's things like SSO login so you can hook it up to if you use Octa or Auth0 for SSO something like that you can use that. It opens up API access so you can grab information about scans and applications in the system via our API if you want to program against your application or your platform. I think the enterprise account also supports web hooks so you can send scan data as web hooks to a web hook endpoint. It's just a bunch of advanced features, but after your 14 day trial you still have access to one app and you can continue to work with it indefinitely. Run as many scans as you want.

OK. So in the dynamic app scanning with Stackhawk section of the of the workbook, we're going to add these lines. to our existing the first actions workflow that we set up. So I'm just going to copy these lines and add them to the end of the file that we created in the file that we created in our first step.

So again, that's.GitHub Workflows build and test navigate to that file, hit this little pencil button to edit the file. And then add these new lines in at the end, just like that. And this is YAML, you're probably all familiar with how finicky YAML can be with formatting. So just make sure these steps line up exactly with the steps before it. So we're adding these two new steps. The first is to daemonize the Node API service. So this app that we built, we're going to actually fire it up in the pipeline and run it in the background. So we say npm run start to fire up the web app. And then this ampersand sign in order to put it in the background so we can move on to the next step. So it's up and running. And then the next step is to run Hawk scan using our own GitHub canned action. So you run stackhawk slash hawkscan action, it's going to pull in that API key that we stash in this secret store. And then it's going to start running that scan and post results back to the platform. So we'll be able to go see them in the UI. Commit this change. And once you do that, you should be you should have a new action running. And you'll actually have two, so make sure you're looking at the build and test workflow. And you can watch this as it trundles along. And it's going to run through the install dependencies step, that's probably going to take a minute, minute and a half. Run unit tests that'll take no time, demonize the service will take no time, then it'll start running hox scan, and that's the most interesting bit that we want to focus in on.

While that's running in the background, excuse me, let me just show you around the application a little bit. So this first section is the apps page, and this shows you a list of all the apps that you've set up in StackHawk, including any environments that you're running in. So you'd get one of these cards for each environment. And these cards just show you at a glance, hey, here are your latest scan results at a very high level summary in the development environment. So how many highs, mediums and low severity issues did we find? And also, what issues have been triaged, either assigned to somebody or marked as an acceptable risk or marked as a false positive if we think that the test is in error?

Then under scans, as you run scans, you'll start to see this list fill out. You'll just see scan by scan all of the scans that are in the system, recorded in the system. We'll go take a look at that in a little bit. This section is about continuous... Well, about all of our integrations. So we've got continuous integration, integrations, basically, though, we run on any CICD platform in the world. All you really need for it to work in CICD is either a JDK, because the scanner is a Java application, or a Docker runtime. So you can run it as a Docker container. We also have deeper integrations with GitHub that we are working with, we may get into today, if we can get through this fast enough. We've got an integration, really on many levels with GitHub. So part of what we provide with that is the ability to register Stackhawk as an official PR test, so it'll show up under the list of tests. We can also post PR comments back to an open PR to show a summary of the scan results. And finally, we've got a GitHub Actions integration, so we can... and we're actually using that currently. That's how we set up the scanner step. We also integrate with Sneak Code, that's another really great SAST utility that provides really, really deep analysis of your code. We've got a great integration with that, and hopefully, we'll show you a little bit of what that looks like with our GitHub CodeQL integration. You can send scan results to Slack or Microsoft Teams or to Datadog if you want to track your scan data there, and Jira cloud so you can create tickets from issues that you find.

All right, hopefully I've killed enough time for this to finish. Yes. Good. So if you are seeing that your action is complete too, zoom in on the run HawkScan step. And it will create a lot of output, but sort of the key information that it provides is, at first, it will give you a little summary of the scan that it's going to run. And this is sort of a pre-flight check that it's doing. It's just making sure that it's got a valid configuration file. It'll go through a bunch of other validation steps, like if you've set up authentication, so you authenticate to the app that you're scanning, it'll try that and let you know if that worked. If you set up some API discovery methods, like an OpenAPIConfig or Postman collection that you fed into it, it'll try that and see if it worked. It'll fail fast if any of those steps fail. Once all that is complete, it'll start the scan engine and it will start crawling and discovering the application, give you a little summary of what it found, and then it just starts hitting all the endpoints that it found with every probe that it's got. Once it has completed the scan, it'll give you a quick summary of results. So at a high level, we found two highs, 10 mediums, and 13 lows. And then it'll list out the specific vulnerabilities that it found, in this case, SQL injection, cross-site scripting, and a couple of others. But those are really just a summary for your benefit and this is really useful, especially when you're running local scans, if you're running it from your IDE, for instance, but the real results are going to be back out on the platform. And you can click this link to follow and find it. But if you can't find that link, you can just drop into the scan section and now you should see it listed. Click in there and see in detail what you've got. Now I'm going to pause and make sure everybody else is seeing similar things, make sure we don't have any blockers out there, I'll check the chats. Cool. Looks like folks are following along. Nice. Nice. It's a good crew out there. You guys are keeping up. So this should be, like, one of the hardest parts. If you can get through that section, getting the API key and secrets and getting the workflow updated and everything, this is so much better. And this is really great.

Okay, so now you should see your scan details. This page is showing you a lot of the same things that the other tools have shown us so far. What are the findings that we found? What is the criticality of those findings? These ones up top, highs, are definitely ones you should address. And, again, since this is a DAS utility and we basically collected receipts on the problems we found, you know that you should prioritize these. So let's take a look at this SQL Injection attack as an example. Actually, let's take a look at cross-site scripting because it's a little bit easier to sort of grok what is going on here. A first thing to notice is that, when you click into the findings details, we give you a nice, long description or a concise description, but we're trying to educate users who come across this. So, because not all developers are going to understand all these security issues, we just want to try and explain what it is and how to address the problem. And so, we provide this little summary. We've also got a bunch of cheat sheets that you can go to. And these are basically showing examples of what this type of problem looks like in different languages and frameworks. And also what the fixes look like in those languages and frameworks. And we also show you what paths we found these on. So as we probe the application, this vulnerability was found on the slash search path in the app. On the right side, we've got request and response data. So this is the request that the scanner sent in, including this malicious text that we sent into the search text. And then the response we got back in this case, if you decode this, Here's the evidence. This is what we tried to inject into the search field. A little script tag. And the response that we got back was that script tag. And so in old bad browsers that don't have security checks themselves, this would actually pop back an alert, a JavaScript alert tag. So basically what we're doing is, what we're saying is we're able to inject scripts into the web app, which is terrible. That is a problem that is a high-severity issue that you should address. And we've also created this curl command. So this validate button, if you click on it, will feed you back a curl command. And so if you were running locally, running the same app locally, and you can try this at home later on if you want to, you could actually recreate the attack and see the same response data that the scanner found, and this is a great way to sort of validate that you have fixed the problem once you try and fix the problem. The idea here is that we're trying to surface this information to developers. If you can do this in every PR and let a developer know anytime they've created a new vulnerability, it is amazing. They generally are going to be able to fix that right away. And if they can't, they can triage the issue in some way. So you might assign it, and if you have the Jira integration lit up, it would create a Jira ticket where you could mark it as false positive or risk-accepted.

Cool. Well, hopefully everybody's gotten a lot out of this, and I'd like to show one more thing since we're doing so good on time, and that is the CodeQL integration. Also want to open it up to questions, like at this point, if anybody's got questions around how any of this stuff works, we can back up and talk about all of that stuff.

But for now, I would like to try and set up the CodeQL integration so we can start to see SAST results. And let me tell you a little bit about this integration before I go there. So, what we've done at StackHawk, and this really is pretty unique to our utility, is we've created a couple of SAST integrations. And I mentioned that there's trade offs with all of these different approaches to testing.

With Dask, we've collected the receipts on every vulnerability that we find, so you know that it is a real vulnerability in your runtime application, and that means you should really prioritize fixing that. But the evidence that we show is a little bit limited. We can show you the request data that we sent in and the response data that we got back, and we can help you validate that, but it would be really handy if you could take a look at the code and understand where in the code base the problem is, and we can't really do that from this outside-in approach to testing.

Conversely, SAST has the exact opposite set of trade offs. So SAST can look at your code and it can find vulnerable patterns and it can point you to exact lines and files where the problem might lie, but it's less accurate. It can't actually tell you if it's a real vulnerability that's really expressed in the runtime application. So the nature of this integration is to try and surface both bits of information at the same time. So you can prioritize it based on DAS results, but get that extra bit of evidence that really helps developers find the exact line of code that they need to look at to fix the problem. So we get that DAST accuracy plus detailed SAST evidence.

So let's see if we can set that up. Head back into the StackHawk application and go to this checker box section, our integration section, and go to the GitHub integration and click on that. And then just hit the enable GitHub button. And point to your organization where you want to install the GitHub app. And then you could light it up for all repos if you want to, or you could just narrow it down to the repo that we're working on today, which is what I'm going to do. So I'll find, it's called vuln NodeExpress and I'll hook it up there. And so it's going to give us, it's going to give the StackHawk app access to the code and metadata and security events and give read and write access to commit statuses and pull requests. So if you went further with this, you can set up the integration that allows it to be an official test in PRs and also that allows it to post scan results back to the PR messages or to PR comments. We're not going to do that today. We're just going to do the code QL integration. So hit install. And I'll use my password. Okay, and once you've installed it, takes a little bit for it to sync up, but then this is what you should see. You can manage the connection, and that will allow you to open up the aperture on what other repos you want it to be installed to. So now that you've got that connection set up, you can add a connected repository. And so what we'll do is connect the GitHub repo of Vuln node express to our Vuln node express repo on this side. And, hopefully, I've picked the right one because I've created two that were the same name. All right, we'll see how this goes. But you should see a similar thing, so hook up your repo to your app on the StackHawk side and hit finish. And now to see this in action, we have to run another scan. So what you could do is just go to your latest build and test run and hit rerun all jobs from GitHub. So under actions, go to your build and test jobs, hit rerun all jobs, kick that scan off. So we'll have to wait for a couple more minutes. While we're waiting, one person in the chat said their authenticator isn't working. Oh, for GitHub, when it asked you to use authenticator? It seems like yes, feel free to drop more clarification in the discord if you have a more specific issue. Yeah, what it's referring to in that case is you must have MFA set up or multi-factor authentication set up for GitHub. And usually it will give you a couple of different options, you might be able to use your GitHub password again if you walk through that flow one more time. But the authenticator, on my phone, I use the LastPass Authenticator. A really popular one is Google Authenticator. But it's that one time token thing and it's looking for... It wants you to go through and hopefully you've set that up on your phone or something and you select your GitHub account and it should give you a six digit code or something that you can pop in there. They have another integration, if you have the GitHub app on your phone, then another option for MFA is to go into your GitHub app and read in the code. They'll give you a little code that you can type in from the web interface as well. Oh, somebody missed how I restart the build and test action.

Let me back up and show that one more time. So from the actions tab, go to the build and test workflow and select your latest workflow. Let's say it was this one. If you if it's all green checkmarks, actually I don't know if you can do it from here. Yeah, just click in on your latest workflow and just say, rerun all jobs. Cool. Okay, let me see. So my building test job is still running. And now it's complete. So let me see if that worked for me. So go back to your scan results, excuse me. And if it worked, your latest scan results should have a new GitHub icon under the SAST column. And when you click in, any findings that it found SAST correlations with should also have that GitHub icon. And then when you click in on those results, then there should be a new tab called GitHub CodeQL. Click on that, and it'll show you, hey, this vulnerability that I found on this side, the SQL rejection attack, has a correlated bit of evidence from GitHub CodeQL. And what they found was that in, that you've got a vulnerability or a vulnerable code pattern, in your search.js file. And you can click out to this to look at it directly. So, now we've clicked out to the GitHub CodeRepo, and it's pointed out this line, and that's where we need to look. A better view, is available if you hit, view CodeQL details. So if you hit this button from the evidence pane, GitHub CodeQL tab, view CodeQL results, then you get this full data about, hey, look in the search.js file. I found this line, where you're trying to put together this query. Yada, yada, yada. It gives you the full rundown of, what the vulnerable code pattern is. So now, to put it all together, you've got a nice little summary of the SQL injection problem, the input output evidence that you can use to recreate the attack, and GitHub CodeQL evidence to show you exactly where in the code base to look for that problem and start fixing it. There we go.