OK, with that, let's get started by jumping into a <a href="/tags/github-actions">GitHub Actions</a> pipeline that we'll create using this Vuln Node Express project. So the first thing to do, hopefully, you've already done this. I'm going to go ahead and do it myself. We'll fork this into my personal repository. And the first thing we want to do is set up an action, a workflow in <a href="/tags/github-actions">GitHub Actions</a>, and what we're going to do is… Oh, I apologize. I need to pull something up. I'll be right back. I need to pull up my cheat sheet.Okay, so we're in our <a href="/tags/code">code</a> base. We're going to set up a whole… just going to set up one new file and that's our workflow file. This file… by the way, I'm going to be working from the browser entirely and you can follow along in the browser just using the GitHub tools for editing files and committing <a href="/tags/code">code</a>. So the first file I'm going to set up is GitHub. It's at the base of your repository.github.com slash workflows slash builder.yaml. So builder.yaml is the name of the file that I'm creating and it's in the GitHub workflows directory. And I'm just gonna give it a quick name here. Call it build and scan and hopefully you're following along at home. And we're gonna say, let's build this thing every time we push <a href="/tags/code">code</a>. We can also say, every time we do a pull request, we won't do any pull requests today, but good to have that in there. And then we're going to create a single job called build and we're gonna have that build job run on. So we'll say runs on Ubuntu 20.04. So, what this is gonna do is you can have multiple jobs in a workflow. We're just gonna have one and it's gonna run on this Ubuntu 20.04 virtual machine. It's a full virtual machine. It's not a <a href="/tags/containers">Docker</a> container. So you're really not limited. You can reach out to the network, run arbitrary <a href="/tags/code">code</a>. We've also got a bunch of nice built-in utilities. So, within our job called build, we're gonna run several steps. Basically, we're gonna check out our <a href="/tags/code">code</a> base. We're gonna install nodejs14.x, whatever the latest nodejs14 is. And then we're gonna run the <a href="/tags/npm">npm</a> and clean-install to install the dependencies for our utility, which is called node, bone-node-express. So first, checkout <a href="/tags/code">code</a>. And this is gonna use, so, we'll say, uses, which means to use one of the pre-built actions, actions slash checkout at v2. So, this uses, the GitHub actually created this particular action, which just checks out the <a href="/tags/code">code</a> base to the virtual machine. Simple as that. So, anytime it starts with actions, you can tell it came from <a href="/tags/github-actions">GitHub actions</a>. This is the name of the action. And then, at v2 means, let's use version two of this. So, that's typical for these actions. The next one will be to install node. And this will also use an action. This one's called setup node, and we're gonna use version two. And now this one, we need to feed it a parameter or an input. So, we use this with keyword and we're gonna say with node dash version is equal to 14.X. So that tells it that we wanna install version 14.X of <a href="/tags/nodejs">node.js</a>. And then finally, we got one final action we wanna do here. Install our dependencies. And this one, we're just gonna say run. When we say run, that just means run this next thing on the command line in the virtual machine. It's just like running a shell command.

Okay, so that's our three types of <a href="/tags/automated-security">security</a> <a href="/tags/testing">testing</a> that we're going to do today. Now, <a href="/tags/github-actions">GitHub Actions</a>. So we're going to base all of this in <a href="/tags/github-actions">GitHub Actions</a>, which is a <a href="/tags/ci-cd">CI CD</a> system. It's a build system for your <a href="/tags/code">code</a>. And it's built right into GitHub, which is probably where you've got your <a href="/tags/code">code</a> already. It's got a simple YAML configuration language and a huge marketplace of what they call actions. And actions are sort of like Jenkins plugins or CircleCI orbs. They're basically plugins that can unlock potentially complex actions that you want to perform in your <a href="/tags/ci-cd">CI CD</a> pipeline. The <a href="/tags/github-actions">GitHub Actions</a> is event driven, so you can trigger builds off of like <a href="/tags/code">code</a> pushes or pull requests. And also arbitrary webhooks. So there's tons of different triggers that you can set up for kicking off your pipelines. There's also built-in secrets management, which is important if you want to do integration tests within the pipeline. And it's also free. You get 2000 free minutes per month, which makes it great for personal projects. And 2000 free minutes is really quite a lot. One thing another thing that I'll say about <a href="/tags/github-actions">GitHub Actions</a> is the actions themselves, the plugins, essentially, that people build. There's a huge marketplace of them. There's tons of them. And one reason for that is that they're pretty easy to build. You can either string together other actions or use a <a href="/tags/containers">Docker</a> container, or you can write it in the native language of <a href="/tags/nodejs">Node.js</a>, which is, of course, super fast. And here's an example of a workflow file, the YAML configuration for one of them.

And with me today is Zachary Konger, who is our senior <a href="/tags/devops">DevOps</a> engineer, and we are really excited to be kicking off our session on automated application <a href="/tags/automated-security">security</a> <a href="/tags/testing">testing</a> in <a href="/tags/github-actions">Github Actions</a>. Like with all the workshops that the wonderful Git Nation teams puts together, we want this to be super interactive. Zach and I both have the discord pulled up. We will be live in there. The channel we're on is called June 1 JS <a href="/tags/automated-security">security</a> <a href="/tags/testing">testing</a>, and in there, we have posted a couple of prerequisites for people to pull up as we get going. One is the Github account, one is a Github repo, and the last is a StackHawk account. Thanks so much for kicking us off. Thanks to everybody for joining. I hope you get something out of the presentation. There's a lot in it, and we had fun putting it together. So hopefully you can all follow along, and we'll try and get feedback to make sure that you're following along. And if not, please again chat to this court and let us know if we need to slow down or go back over some points.

So this is the <a href="/tags/workshop">workshop</a> on automating application <a href="/tags/automated-security">security</a> <a href="/tags/testing">testing</a> in <a href="/tags/github-actions">GitHub actions</a>. And we are going to light up a couple different <a href="/tags/automated-security">security</a> features in <a href="/tags/github-actions">GitHub actions</a>. And before we do that, of course, I'll give you a quick overview of <a href="/tags/github-actions">GitHub actions</a> itself and how that works. And we'll set up a little workflow.So my name is Zachary Conger. I'm the senior <a href="/tags/devops">DevOps</a> engineer at Stack Hawk. Been doing <a href="/tags/devops">DevOps</a> for quite a while. Kind of an early adopter. Been doing a lot of software development, <a href="/tags/automation">automation</a> <a href="/tags/testing">testing</a>, <a href="/tags/observability">observability</a> stuff, standard <a href="/tags/devops">DevOps</a> stuff. And in my spare time, I like to play <a href="/tags/creativity">music</a>, ride bicycles and do some amateur photography.So to get going today, I hope that you all already have a GitHub account. And if not, go ahead and join up now. It's pretty easy to get that set up. And then once you've gotten into GitHub, I would like you to fork a repository, and Rebecca will paste this into the Discord chat. But there's this application that we're going to be working with called Vuln Node Express. It's a very simple application written in <a href="/tags/nodejs">Node.js</a> with the express <a href="/tags/frameworks">framework</a>. And we'll just need to fork that because we're going to work on our own repositories to build out our <a href="/tags/github-actions">GitHub Actions</a> workflows. So while you're working on that, if you need to fork that repo and get your <a href="/tags/github-actions">GitHub Actions</a>, or get your GitHub account set up, I'll talk about the three kinds of <a href="/tags/automated-security">security</a> <a href="/tags/testing">testing</a> that we're going to be working on today within <a href="/tags/github-actions">GitHub actions</a> once we get our <a href="/tags/github-actions">GitHub Actions</a> workflow set up.So, the first type is called SCA or Software Composition Analysis. And there's several tools out there that do this type of <a href="/tags/automated-security">security</a> work for your application. The one we're going to be using today is called Dependabot, which is built into <a href="/tags/github-actions">GitHub Actions</a>. There's also Snick, which is a pretty famous company. They sort of made it easy for developers to do their own SCA. And Fossa is an open source example. And what software composition analysis is, is basically it's checking your dependencies that you pull into your <a href="/tags/code">code</a>. So, it operates on static <a href="/tags/code">code</a> that looks at your software repository. And it's got its own <a href="/tags/database">database</a> of open source libraries and dependencies that it keeps and it knows which ones have <a href="/tags/automated-security">vulnerabilities</a> associated with them. So, it can quickly go through your <a href="/tags/code">code</a>. It can build out your dependency tree and it can report back on any known <a href="/tags/automated-security">vulnerabilities</a> that it can identify there. It's a fast test. It's really easy to set up, generally. You should definitely have this in your repository, if you don't already. It never really reports false positives, because all the <a href="/tags/automated-security">vulnerabilities</a> that it knows about are real. It's really fast. And the best of those tools actually will offer to fix it for you. In the case of Dependent Bot, it just issues a PR to your software repository and offers to fix it for you.The next kind of tool is called SAST. Which stands for Static Application <a href="/tags/automated-security">Security</a> <a href="/tags/testing">Testing</a>. And examples of this are codeQL, which we will use today. That's a GitHub property. But other famous ones are Sonar Cube and Checkmarks. So SAST, like SCA also operates on static <a href="/tags/code">code</a>, but it behaves differently. So it's not looking so much at your dependencies as it is looking at your <a href="/tags/code">code</a> that you've written. So it's looking for your bugs, not bugs that you've imported from other dependencies. So typically, it will just take your whole codebase and then index it in a <a href="/tags/database">database</a> and search it using queries, and these queries are looking for <a href="/tags/patterns">patterns</a>, coding <a href="/tags/patterns">patterns</a> that indicate that you might have a vulnerability. So it finds your bugs, not dependency bugs. It can have high false positives, and it can be a little bit slow since it's it's gonna do that export and indexing and searching and such. But it's also a valuable tool to have in your arsenal. Um, so CodeQL is the one that we'll be checking out that again is built into <a href="/tags/github-actions">GitHub actions</a>. DAST is the final type of <a href="/tags/automated-security">security</a> <a href="/tags/testing">testing</a> that we'll look at, Dynamic Application <a href="/tags/automated-security">Security</a> <a href="/tags/testing">Testing</a>, and examples of this are StackHot, which is, which is the company that I work for, Oosp Zap, which is the most popular open source DAST utility out there, and then Burp Suite, which is a really popular commercial utility for doing dynamic scanning.

So DAST differs from the other two in that it actually operates on running <a href="/tags/code">code</a>. It doesn't look at your <a href="/tags/code">code</a> base at all, doesn't care what language you wrote your <a href="/tags/code">code</a> in. All it does is it probes your service. So it sends inputs into your service, say it's an API or a web application, and it looks at the responses that it gets back from it. And then based on the responses that it gets back, it determines if you may have a vulnerability, and it will report on those. And like SAST, this is a utility that will find your bugs. It will also find bugs in your dependencies, if they're exposed in your <a href="/tags/code">code</a>. And as such, it has pretty low false positives. It can be a little bit slow because it has to run on your running application. And so depending on where your application is in relationship to the scanner, you know, if it's far, far away across the world, that can make it slow. If it's a slow or large application, that could slow the scan down as well.

So we'll say <a href="/tags/npm">npm</a> install. And that's it. I am gonna go ahead and show you what happens when we add this. So just adding this file that you may still be typing in and checking in. So just by adding this file in this special place, that is actually gonna kick off because we've told it to trigger on pushes, and what I did was essentially just a push. When I go over to actions, I should see that this action is running. And there it is. This is my commit message. When I click into there, I see you might have multiple jobs. We just have one called build, and it's already complete. So it walks through each of those steps that we outlined in the yaml file. We checked out the <a href="/tags/code">code</a>, gives you a little information about that. We installed <a href="/tags/nodejs">Node.js</a>. It did that. And we installed dependencies for the vuln-node express application. And you see it walk through all of that. And this is the longest step for this whole thing. So that's that, that's <a href="/tags/github-actions">GitHub actions</a>. And it looks like a lot of folks are up to speed. If anybody is having trouble, definitely reach out to us in Discord and we can help out.

All right, on to the next step, Dependabot. So Dependabot is the SCA, that's the software composition analysis. And of course, it's a free service for all GitHub repositories. It's enabled by default in public repositories. And it's easy to add to private repositories. Again, this is the utility that finds <a href="/tags/automated-security">vulnerabilities</a> in the libraries that you pull in, in your dependencies, and it automatically issues PRs for fixes.Okay, so this one's pretty simple. Let's just jump right into that one. So to get this one to work again, we're just in the browser, we're looking in our <a href="/tags/code">code</a> base, head over to the <a href="/tags/automated-security">security</a> tab. And in the <a href="/tags/automated-security">security</a> tab there's a bunch of features here, we're not going to go over all of them, <a href="/tags/automated-security">security</a> policy is about letting users know how they can report <a href="/tags/automated-security">vulnerabilities</a> for your <a href="/tags/code">code</a>. <a href="/tags/automated-security">Security</a> advisories is where you can tell users about <a href="/tags/automated-security">security</a> issues that you know about in your <a href="/tags/code">code</a>. And then the one that we're going to work on right now is Dependabot alerts. So, just going to enable this, just hit this button right here to enable it. And we want to light up all of these features so that it can be most effective. So the dependency graph feature that we'll enable allows GitHub to go run through your dependency graph and build it out, because each of your dependencies probably has other dependencies that it will pull in, so it builds that whole thing. So you know how <a href="/tags/npm">NPM</a> is, it just goes out and grabs the world. This allows GitHub to figure that out. Dependabot alerts basically is a way of letting it, letting dependabot tell you about the problems that it finds. So it'll email it to you and it'll give you a little badge on the <a href="/tags/automated-security">security</a> tab here whenever you have an issue. And then finally dependabot <a href="/tags/automated-security">security</a> updates easily upgrade to non vulnerable dependencies. Going to enable that too and this is the future where it actually issues a PR to your <a href="/tags/code">code</a> base to give you an option to fix whatever issues you find. So that's it, dependabot is enabled now. And if we go to the <a href="/tags/automated-security">security</a> tab, we see that it's already got some alerts for us. It found some high and low severity issues that it would like for us to fix. And I'm not gonna fix any of these things. I'm gonna fix some of them myself, just to save time. But you can go back into your repository later and try fixing these things yourselves. So, but I'll click into this one, for instance, PUG, it found a dependency PUG, it would like for us to bump that up to three.01, because it found that vulnerability in two of four. It tells you just exactly how to do it. It's very easy. And it gives you some details about the issue that it found. So you can go and research it on your own. Really pretty straightforward. Another cool thing to notice is that we have a pull request pending that's brand new. And if you're following along in your <a href="/tags/code">code</a> base, you may have the same thing. And basically that issue that it recommended that we fix, it has actually issued a PR for that. And it's willing to do the fix for us if we want to. So, you can just merge the pull requests if you need somebody to review it, you can do that too. You can also see that it's running some checks. And what it's doing is it's running the action that we set up initially. So it's trying to run through our builder workflow that we set up just a moment ago to make sure that nothing breaks. Pretty cool. So that... I think that's all I've got for Dependabot. And again, later on you guys can go and do your PRs and see if you can fix the <a href="/tags/automated-security">vulnerabilities</a> that it found for you. Actually I'll show you one other thing I think. Let's see, GitHub workflows. Nah, nevermind. Okay, so that is Dependabot. In fact, it doesn't look like everybody that was able to run the GitHub Action has been able to set up that Dependabot yet.

So if we just give them another moment or two to make sure everybody can follow along. I know one of the things that I love about that builder file that we just set up is that now whenever we push any type of these <a href="/tags/automated-security">security</a> updates, you don't have to worry about things breaking, as you say, as you mentioned, I think that is a big struggle teams have run into is they add new <a href="/tags/automated-security">security</a> <a href="/tags/tooling">tooling</a> to their pipeline and everything breaks, it is very frustrating for developers. So I think that's one of the duties of <a href="/tags/github-actions">GitHub Actions</a>, I'm sure. It's a big deal for us. But I think the other thing that we need to be thinking, you as a <a href="/tags/devops">DevOps</a> expert, know a lot more about that than I do. I thought that was really neat.Totally agree. Yeah, I really feel like GitHub has created something pretty wonderful with <a href="/tags/github-actions">GitHub Actions</a>. It just makes so much sense for it to be co-located with your <a href="/tags/code">code</a>. And they really did a good job. And I especially love that the actions, the <a href="/tags/community">community</a> that they've built up and all the actions in the marketplace. In fact, I can show that off a little bit. You can click into the <a href="/tags/github-actions">GitHub Actions</a> marketplace. GitHub marketplace. There's just tons of different actions available. And under <a href="/tags/automated-security">security</a> as a matter of fact, there are lots and lots of apps available. You'll find. I'm surprised we're not seeing the big, heavy hitters. So, SNC definitely has one. We've got one. Yeah, and we did get a question in the Discord, Zach, which is if my repo has some dependencies that are not private, so private repos of the same account, will Actions work or should I configure it additionally? On private repos, actually Actions will work on all of your repos unless you turn it off or your organization has turned it off. So, it doesn't matter if they're private or public and you get 2003 minutes whether your repos are private or public. Dependabot is set up by default for public repos, but you have to enable it for private. It is also free for private. And so that will work even if the private repos are within that one public account. There was a little typo in the question, which is it was some dependencies that are not public. But that should work. Yep, that should work. Yeah, everything that we've talked about so far is free or mostly free for public and private repos for your personal account. All right. Well, it looks like we've gotten most folks up to speed with the Dependabot. We may have another part of that question coming in, but if you want to go into CodeQL, we can go back to those questions once you've explained a little bit about SAST. Sounds good. All right. So the next component is CodeQL, and this is our SAST utility. Again, this is the one that looks at your <a href="/tags/code">code</a> to make sure that your <a href="/tags/code">code</a> is secure and it analyzes your <a href="/tags/code">code</a> to look for <a href="/tags/patterns">patterns</a> that could indicate that you've written in some <a href="/tags/automated-security">vulnerabilities</a>. CodeQL has an <a href="/tags/open-source">open-source</a> set of queries for common <a href="/tags/automated-security">vulnerabilities</a>, and that <a href="/tags/open-source">open-source</a> set of queries is growing all the time. It's a great utility. Now, if your <a href="/tags/code">code</a> base is private, this is not a free utility. If it's public, it is free. So on our repository, it's gonna be a free utility. If you have a private account, they do charge for the use of CodeQL, but it's a great utility. I'll come back to those questions. So let me go ahead and pause and answer this question. So if a dependency is not public and cannot be fetched by other users, <a href="/tags/github-actions">GitHub Actions</a> works on behalf of current account or how authorizations. So you'd have to work in the authorization to give <a href="/tags/github-actions">GitHub Actions</a> access to your private repository of dependencies. It probably won't know about any <a href="/tags/automated-security">vulnerabilities</a> that would be found in there. You'd have to use something like CodeQL or StackHop to find those <a href="/tags/automated-security">vulnerabilities</a> in the other library. And to get it access to your private repository, you can use that Secrets function to add like an API key or whatever to get to your <a href="/tags/npm">NPM</a> repository. Okay.

Zack, we did get another question on the findings from dependent bot, which is why do we only get one new PR while we have five open <a href="/tags/automated-security">vulnerabilities</a>? So sometimes it's going to give you PRs for every kind of vulnerability that it can do a PR for, that it knows how to fix it for. Others it won't have success with. What I've found in practice is that it'll catch most of them and give you PRs for most of them. And as you go through and fix one PR, it's gonna be able to figure out how to fix the other problems. We've probably just got some dependencies that are so old and intermingled that it would be too complicated. So it's doing one at a time. It's a good question.All right. So let's set up CodeQL. CodeQL, this is the SAST utility. And if we go down here to the <a href="/tags/automated-security">security</a> tab as before, just go down to <a href="/tags/code">code</a> scanning alerts and say setup <a href="/tags/code">code</a> scanning. And in <a href="/tags/code">code</a> scanning, you'll see that there's a number of other SAST utilities that you can choose from. CodeQL is theirs and it's highlighted of course by GitHub. And that's what we'll set up. Now this one of course, what this is gonna do if you'll notice is it actually sets up another workflow under.githubworkflows, codeqlanalysis. And basically it's gonna check every time we push or do a pull request to main or on a schedule every, I think it's once a week, it will run automatically. And it's gonna fire up an Ubuntu VM and it's going to basically, it understands that we use Java script. So it's only set up that, but if you have other types of <a href="/tags/code">code</a>, it can reckon these other kinds like C++, C Sharp, Go, Java, <a href="/tags/javascript">JavaScript</a>, and Python. Checks out your repository, initializes the utility. Doesn't auto build, this is where it actually tries to figure out how to build your <a href="/tags/code">code</a>, and so it should find our <a href="/tags/npm">npm</a>, our package.json and figure out how to build our <a href="/tags/code">code</a> from there. And then it runs the analysis. So I'm just gonna commit this <a href="/tags/code">code</a> and you should too. And when I do that, it will start running that action immediately and it's gonna start analyzing the <a href="/tags/code">code</a>. So if we go into actions, we should see that we're running our own build and scan workflow as before, but in addition, we're running this note new CodeQL workflow that CodeQL set up for us. Click into there and we can look and see how this is going. Analyze <a href="/tags/javascript">JavaScript</a>. It already ran through the autobuild. Now it's running CodeQL analysis and it's just writing a bunch of queries against our codebase. So, if you've gotten to this part, go ahead and let us know by giving Rebekah a thumbs up on her question. And Zac, someone asked, did you change anything for the CodeQL in the file? I changed nothing. So you can just say enable it. It creates the file. You just commit that file and you're good. That's exactly what I did. And Zac, I mean, watching it here, it looks like it's running pretty quickly. I know some of the concerns we hear from folks about adding <a href="/tags/automated-security">security</a> into <a href="/tags/ci-cd">CI CD</a> is that it's gonna take 15 minutes on every push or something like that. Is this kind of fast scanning pretty consistent for the tools that are able to run in GitHub? It is. So the software composition analysis is typically really fast. This type of static analysis, static <a href="/tags/code">code</a> analysis like this CodeQL is doing, takes a little bit longer. So it's probably, yeah like a minute or two. But if you have a larger <a href="/tags/code">code</a> base, it can take longer. That's the thing is that as you add things it can take longer. But what you can do is have these things run asynchronously. So you can go deeper into <a href="/tags/github-actions">GitHub Actions</a> features and you can set this up so this doesn't block your build at all. And it just runs asynchronously. Maybe it even just runs on a schedule. So it shouldn't slow down your <a href="/tags/code">code</a> commit. Awesome, all right. It looks like folks that have been following along are having pretty good success with CodeQL. If you've run into any problems, again, we're here to help.

I think Zach for the most part we're good to keep going. It's amazing to me that we've set up two <a href="/tags/automated-security">security</a> tools and only created one build file. Just really nice. Yeah, it's good stuff.So I just wanted to show you what the result of CodeQL scanning does. So again, in the <a href="/tags/automated-security">security</a> tab, we've got... We were at five and now we're at six <a href="/tags/automated-security">security</a> issues. And under <a href="/tags/code">code</a> scanning alerts, here's what CodeQL produces, is these kinds of alerts. So if I click into this, <a href="/tags/database">database</a> query built from user controlled sources, it'll tell me a little bit about the thing that it found. So the neat thing about SASS utilities is it points exactly to the file, service slash search JS in my <a href="/tags/code">code</a> base that has the problem and the line and exactly where the problem is. So it says this query depends on a user-provided value. And since I know a little bit about the <a href="/tags/code">code</a> base, I know that it's talking about this. It's creating a SQL query and it's filled in some details on its own, and then it's just taking what the user entered into a search field and adding that into the query. And it hasn't done any sort of sanitization of that request whatsoever. So CodeQL got it right on this one. This is a problem. This text should be searched to make sure that I'm not creating a SQL injection, essentially, which would be bad. So there you go. And it shows you which rule hit this. You can look at the source and it gives you even more detail about how to deal with this problem. There we go. So that is that. That is CodeQL and SAS. Hopefully everybody's got that working. And that is what CodeQL looks like.And now we'll come to the final utility that we're gonna use, which is Stackhawk. So there's other utilities out there. And in fact, Oasp Zap is the most popular open source utility, and Stackhawk is actually based on Oasp Zap. What Stackhawk has done with Oasp Zap, which is a great utility, is we've built a platform around it, as well as a pipeline, and also sends <a href="/tags/data">data</a> back to our web platform so you can keep track of all your scans and all of the applications that you're scanning and all of the environments in which you're scanning them. And you can also work on, you can also triage issues that you find from Stackhawk scans. So you can mark them as false positive or accept the risk or assign them to other developers in say, Jira, for instance. It also has notifications and all kinds of great stuff. And the idea is just to make it so that you can use DAST in a pipeline configuration and make it a tool that is very developer focused so that all the developers can work around it and get good information out of it. There is a free account for developers and that's what we're gonna set up in just a second here. It's got a simple YAML configuration just like everything else that we've looked at today. And let's just give it a shot. Here's an example configuration. Ours is gonna be a lot simpler today. All right. So the first thing to do is go to stackhawk.com. Thanks, Rebecca. So you go to app.stackhawk.com. What did you think? Well, you know, JSON is better, it's more exact. I think YAML is a super set of JSON. So technically, you could also use JSON. So head on over to app.stackhawk.com. That'll redirect you to auth and hit sign up for a new account. And what we're gonna do is I'm gonna just use my Google account. You can also use your GitHub account to log in, or if you prefer, you can set up a whole brand new username and password using email. Google and GitHub obviously are faster.

So that's what I'm gonna do, is Google. So I'll set up z at econger.com and it's gonna create a new organization for me called Zachary Conger's org. I'm authorized through Google. I'm gonna pause here for just a little bit. Let us know as you are getting your account set up that you've gotten to this point. I wanna give some time for people that are using email to get there, you know, verify your email address and everything. So you can give your org any other name that you wish, of course. Later on in the flow, you'll see that you can invite other users. And that's sort of the point, eventually, is that you'd have a team of developers working on stuff. But you can just use a free developer account like we're gonna set up today. And you can use that forever to to scan your app. I'm gonna hit continue. And on this next step, real easy choice. If you choose pro, which you don't have to, it starts you with a 14-day free trial. So it doesn't mean that you start paying immediately. But I think everybody here today should choose the developer account. And of course, you can upgrade to pro if you need to. And from here, we can set up our application and start scanning. I'll hit continue. And on the next page, we have a choice to set up our own application to scan or go to Google Firering Range. Of course, this is still all free. Google Firering Range is a big vulnerable application in the sky that you can scan. And this gives you sample <a href="/tags/data">data</a> to work with. We're not gonna do that. We're gonna scan my application, which we will set up here in a second.

Yeah, I think, Zach, we saw some folks trickling in. So if people are using email to set up just to review what Zach went over, when you get into the platform, you can name your org whatever you want. I know Zach previously has named his Zach talk. Really there's no limits. Whatever you want to name your org, that's up to you. And then for today's purposes, the free plan will work perfectly. You can certainly dig into those differences after the fact. And then you'll just click Scan My Application. So hopefully that gives everybody enough time to kinda get caught up. Looks like we're about everybody that's been following along in Discord is ready for the next step. But if you run into any problems, definitely let us know along the way.

Cool. We have a raised hand. Let's see. Let's see. Oh, it looks like it disappeared. Okay. Okay. I'll continue. Oh, we got some in the chat. Oh, okay. There are other questions I didn't see in the Q and A in Zoom. We'll go back to those there on the <a href="/tags/code">code</a> QL piece. So my apologies for not catching those. We'll revisit those here. Once we get through this DAAS piece. Sorry about that. Okay. Sounds good. All right. Thank you. Okay. Continuing on.Okay. So once we've selected that we're going to scan my app it drops you into this welcome, getting started flow. So we'll just jump into that and it's going to create for us our first stackhawk.YAML configuration file. So we'll get started. And the first thing it says is, okay we've got a new API key. Now you want to take this API key. It won't show it to you again. So you should copy it and, you know save it someplace secure. You can create new API keys. Not a big deal if you lose access to this key cause you can just create more. But for this flow, let's go ahead and copy it. And what I'd like to recommend is that we go back to our GitHub repository and go to settings and under settings, there is a secret section, and under secrets, I'm going to set up a new repository secret. And the name of that secret will be stackhawk-api-key, which is important because we're gonna refer to that later in our configuration for Stackhawk. And we're gonna paste in the API key right there and add this secret. So what this does is creates a secret in our repository that we can access in our GitHub workflows so that they're never exposed to end users and they're not saved in your <a href="/tags/code">code</a> base so that people can't go search through your Git history and find this secret. Okay, so that is done.All right, Zach, let's just give everybody a second to get that put into GitHub's secrets, how about say <a href="/tags/github-actions">GitHub actions</a>, just so folks can follow on since that API key can be a little bit tricky if it's not stored in the secrets piece. Thanks, Rebecca. I get so excited. I know, API keys really, will get me going. It looks like you're having some success. We'll give them just another minute if you're running into any problems, feel free to drop it in the chat. I know not everyone uses GitHub secrets. People may be using <a href="/tags/aws">AWS</a> Secure Store or other pieces. If you're not familiar with the tool and need a little troubleshooting definitely just let us know. Yeah, and just to retrace my steps too. So I went to my repository of Volnode Express, go to the settings tab, and then down to the secrets section on the left and hit new repository secret. Call it hock API key and paste in your key.

Okay, perfect. That little bit of extra time help. Thank you, Zach. Yeah. So then this getting started flow also on the same page, it suggests that you can save your key on the command line using these two commands. And you could just do this, you can just copy this and go to your <a href="/tags/cli">terminal</a> window and just paste those commands in. And what it'll do is it'll save your API key to this file so that you can call it up in the future. And that's useful if you're running this from the command line a lot. We're not gonna do that at all today. So don't worry about that step.

All right, I'm gonna go ahead and move on to the next step, which is to create a new application. And it suggests that we rename it after our repo name. Sounds good to me. So I'll call it mole node express, just like the repo. Under risk level, I'm gonna say low cause it's a silly application. It's just a test. But you can give it your own classification if you wish based on how important it is to your organization. This doesn't actually affect scans. It's just for reporting purposes in the future. And then for <a href="/tags/data">data</a> type, same thing. If you have a <a href="/tags/data">data</a> classification associated with this application, you can add that here. I'm gonna say unknown because we're really not storing any type of sensitive <a href="/tags/data">data</a> in this application. Awesome. And Zach, so if I configure those differently, if I put the risk level as high, will that change anything with the scan or what are the implications of those? Right now, there's really no implications and you can change this in the future. It may show up on reports if you print out like, we have a PDF executive report that you can print out from scans and I think it shows up in that report. Okay. I just thought this will look a bit easier. Just dropped it in, but again. Yep, let us know. It'd be good to keep going on this one. Yep.

Alright, configure environments. So we're gonna configure our environments. So we suggest these names for your environments. And the idea here is that, maybe development is on your workstation as you're developing <a href="/tags/code">code</a> and you're running scans. You might want your scans to show up under the development environment in the platform. In CICD, you might run it pre-production and you may also run it in production. Although we really recommend that you run it in CICD pre-production before it ever goes live. That way you catch bugs before they happen.Also, going to give it a host name. So this is the application that we're actually gonna be scanning. We are at localhost port 3000 and it's actually HTTP, not HTTPS. And let me just double check that because I've got a copy running right here. localhost 3000, yes. There's my app. Okay, so localhost 3000 is the app we're gonna scan and that's HTTP, not HTTPS. I'm gonna paste that in. That's what you should set as your host. And Zach, just for folks that aren't as familiar, so that will be listed in the repo that you're running. Is that the best way to find that? Yeah. So let's see. I can show you where I'm getting that value. When this application fires up, well, it's just the default Node Express port that it listens on is 3000. But you should know what port your application listens on in your environment. So it happens Node Express listens on port 3000 by default. And when we go to scan, we're gonna scan localhost because we're gonna bring this application up in the pipeline on the localhost address. Perfect. So your screen should look like this now. I'm gonna move forward.Finally, it gives us an application ID. So instead of calling this in our configuration file, instead of calling it vulnerability express, we're gonna call it by this giant number right here. So this is a UUID and we just do that so that you can change the name of your app in the future. Okay, so then now it's gonna give us a stackhawk.yaml. This is the configuration file that we will use for our scan. And I'm gonna pop it open. Let's see what's it's gonna open it in for. Oh, good. Apple Xcode, my least favorite IDE. Let's see if we can get a better one. Sorry, this will take five minutes because it's trying to open Xcode. Standby. Not alone in not liking Xcode's stack, it seems like. That's always awesome. Alright, I'm going manual here. I'm gonna grab the stick and open it in Adam, which is marginally better. Okay. So there's a lot in this file but really all we need are these four lines that are highlighted. So we're gonna do a top level app and under that we've got application ID, which is that giant number. This will be unique to your configuration. And then the environment, which we set up as pre-production should be populated. And then the host as we populated in there.

And so yours should look exactly like mine except that you will have a different application ID since it's unique. I'm actually just gonna copy this much of it. I don't need all this extra stuff. That's just a bunch of extra helper text to let you know about different kinds of configuration options. But we've also got great <a href="/tags/documentation">documentation</a>.Okay, so I'm gonna copy this content and I'm gonna create a new file at the base of my repository called stackhawk.yaml. Oh, I'll put it right there. Zach let's give everybody just a minute. It looks like some folks might have gotten stuck in the setup wizard. Not everybody's been able to download that YAML. Oh, okay. If you ran into any problems, please let us know. We wanna help you make sure you can... It was, I know it's a little bit more on the setup side than our other tools. So we definitely wanna help everybody get through that step. Yeah, and I've got an idea for that too. If you get to this part and you've got your application created but you can't download your stackhawk config, we can help you put it together. It's gonna look the same. We're gonna paste out what the configuration looks like and all you need is this piece to make it uniquely yours. So, just copy that. Make sure you've got a copy of this UUID. That's the most important part. And Zach, we did get a question in the Q&amp;A, which is it which I think is stackhawk available on private and public repos. Yes, it is. And that developer account, you can use it on public and private apps. Okay, it looks like we're having a little bit more success with folks that have been able to download the YAML. Again, if you run into any problems with that, feel free to drop those questions in the Q&amp;A or here in Discord. And Zach is also going to be walking through, if you haven't been able to download that YAML, we can get you that text here in the Discord so you can drop it in GitHub Action, that way, as long as you have that application ID Zach pointed out.All right, Zach. Take it away. All right, here we go. Okay, so we're at the base of the Vulnode Express repository, going to add a file, create a new file, the file's called stackhawk.yml. And it's important to use this name because that's the configuration that the scanner is going to look for. By default, you can use other names, but you'd have to refer to them. So just to keep things simple, call it stackhawk.yml and paste your configuration into there. Maybe I'm going to simplify it further. So we've just got the app, super section, application ID, this is your unique number. Environment preproduction, host HTTP localhost 3000. There you go, thanks, thanks, Rebecca. So stash your app ID in there where it says to do so. Now when we check this in, it's going to build our workflow again, but we haven't added to our workflow the Hawk Scan component yet. So let's do that now. And Zach, if you don't mind just giving folks another minute or two to catch up with that push of that StackHawk YAML, that'd be awesome. Let's do that. Nice. Great success. While folks are finishing that step up, let me show you, there's docs.stackhawk.com, and this is where our full <a href="/tags/documentation">documentation</a> set is. Down here, we've got a little brief quick start on how to get this running on your workstation. We've got lots of detailed configuration information, so all of the different sections that you can fill in, but this is the basics. Just adding this much really gets you a long way.

Tons of great information. Jack, we did get a question in the Q&amp;A, which is, where can I get a new API key in StackHawk if someone wasn't able to save that successfully the first time? Yes, yes. And then we will go on to the build file. Okay, I'll close out of that. So go to your name, click on that, and go to settings. And under settings, there's an API keys section. You can create a new one there. Oh, and I've been made a liar by our interface, which actually will show you the key one more time. But after this, I swear it will go away. Except then it proves the rule. All right, perfect. Looks like folks have been able to get that YAML added to our repo. So if you wanna walk through what we're gonna update in the builder file, Zach, so we can get the scan off, that would be great. You got it. So here we go. So under GitHub workflows, go back into our builder.yaml file. And let's edit this file. We're just gonna add one section or actually two sections. So the first thing we need to do is run our application. Run express. So we'll run our application. We'll get it stood up and running in the background so that we can scan it. So check my cheat sheet here, make sure I get this right. So run, and this will just run a shell command as before. I've got a red squiggly line, why is that, tell me. Okay, it can't be null, gotcha. Okay, so we're gonna run <a href="/tags/npm">npm</a> run start, but we want it to run in the background. So we're gonna type ampersand after that, and that makes it run in the background. And then before that, we're gonna type in nohup, and that detaches it from the shell so that we can move on from that step. So, nohup <a href="/tags/npm">npm</a> run start ampersand. With that, our application is running in the background within the pipeline and we can scan it. So now we'll run hawkscan. And hawkscan is gonna use a GitHub action that we have prepackaged called stackhawk slash hawkscan action at V1.2.1. So that's our hawkscan action. That's an action we created to make this even simpler in the pipeline. We'll give it one parameter, one input called API key that's with a capital K and the key that we're gonna give it is the one that we stashed in secrets earlier. So we refer to it in the secrets context hawk API key. And this double brackets with a dollar sign in front of it is sort of the notation for pulling out information from GitHub context, they call them. So you can grab GitHub environment variables and secrets and there's all kinds of other features that you can read about later. So that's it. With that, if I got that right, this should add a scan. Yeah, I just wanna reiterate, Jack. It's just adding those last two name sections, everything below that. Everything above that is the exact same as what we had in that builder file previously in the <a href="/tags/workshop">workshop</a>. Yep, that's right. And that is in the Discord if you would prefer to copy paste. But we'll give folks another minute or two to add that into the GitHub pipeline. Sorry to interrupt, Zach. No, not at all. Thank you.

This is great. It's like we've got a lot of success so far. And once you've added this stuff, that's all I'm gonna add. So you can go ahead and commit your changes. I'm gonna go ahead and do that and start building that action. So in mine, and you guys are... Let us know as you finish. But once you check that in, it's gonna rerun that action just as before. It's gonna, this time, it's gonna bring up your app and it's going to run Hawkscan against it.While you guys are finishing up, I wanna go over to the actions tab and show you what this looks like. Of course, CodeQL is running in the background as it always does. I wanna look at our built-in scan workflow. And in there, under Build, we're still installing dependencies. But then once it's done with that, it'll run our app and run Hawkscan. And over here. Hmm. Yes, Imak, I'll read that question. It looks like you're looking at it too. The question we got in Discord was so this is <a href="/tags/testing">testing</a> a running application, right? How does this work for apps with <a href="/tags/authentication">authentication</a> or apps just running within a company net? What does it test then? Great question. So it does work with <a href="/tags/authentication">authentication</a>. You can configure <a href="/tags/authentication">authentication</a> into it so that you can get access to the protected parts of your application. And yeah, that's exactly right. It's running against a running application. And what kinds of <a href="/tags/authentication">authentication</a> does StackHawk support, Zag? It supports lots of different kinds. They kind of fall into a couple of different categories since we're generally talking about web applications or SOAP or OpenAPI applications. There is like token based, any kind of bearer token or cookie based, any sort of cookie session based session cookies. As for the <a href="/tags/authentication">authentication</a> piece itself, you can have an external <a href="/tags/authentication">authentication</a> provider like Auth0 or Ping or Okta or whatever. Or you can have an internal method. You could have classic <a href="/tags/forms">forms</a> <a href="/tags/authentication">authentication</a> or a <a href="/tags/javascript">JavaScript</a> <a href="/tags/forms">forms</a> <a href="/tags/authentication">authentication</a> that submits a JSON blob to a credential service. So far we haven't found any <a href="/tags/authentication">authentication</a> methods that we haven't been able to handle.So we're watching the work, my workflow, and you're starting to see a hawkscan running against the application. And the first thing it tells you is that it found several endpoints. First thing it does is runs a web spider against your application to see what it can find. And then it starts scanning them, and then it gives you a brief rundown of what it found. Found a SQL injection, cross-site scripting, anti-CSRF tokens check, et cetera. And finally it shows you that you can view the results on the StackHop platform. So if I click through that, I can get to the scan results. This isn't actually a problem with the app. I log into several different sessions and sometimes it has trouble with all the cookies I've got. But if you go to your scans tab over here on the left, you should see your scan results right here. So first off, congratulations to everybody that got that working and got to this point where you've got a scan result coming through. And I'll take a quick pause, and Rebecca could you ask if people are seeing their scanner running, if they're getting results? Yes, definitely. If anyone, I guess if you've gotten an error message, I think that might be helpful. If you paste that into the discord, we will be able to help you troubleshoot that. Zach, I know in other workshops, we've had problems where maybe people haven't been able to engage with the local host. I'm trying to think of that problem we ran into last week in our last <a href="/tags/workshop">workshop</a>. I know that one is an uncommon, oh, it looks like we have folks dropping those in, so those are super helpful. Thank you, Mars Magic, Zach, Donna. Cool, cool. Okay, client request exception.

So I'm curious, Mars Magic, on your client request exception. Did you enter this endpoint into your stackhop.yaml? Or was this when you tried to click through to get to your scan results? There we go, okay. Okay, so this is probably, double check your API key in the StackHawk platform and make sure that that's the same one that you entered as your secret, as your GitHub secret. So it's expecting to find in our configuration, let me just actually just map it through for you, in your stackhawk.yml, or excuse me, in your <a href="/tags/github-actions">GitHub workflow</a> builder.yml, you need to provide API key, secrets-hawk-api-key. So first of all, you know, the with API key, make sure you've got API key with a capital K. Make sure that you've spelled this the same way as you've spelled the secret and make sure that your API key was copied in correctly. And your secrets again are over in the settings tab and the secrets and I created one called hawk-api-key. What other errors are folks running into? And if that didn't resolve the API key error, let us know and we can kinda keep working through that and help you. We got a question, which is not about an error, but does it support <a href="/tags/php">PHP</a>? Yes, yeah totally supports a <a href="/tags/php">PHP</a>. Yeah, as long as it's a web service, or a web API or a soap API, or a graph QL endpoint, it's supported, it doesn't matter what language you write it in. It could be a shell script.

Okay. So, we'll continue to look at these questions and at this point we're a little over, so I just want to kind of finish walking through this really quickly. And I'm able to stick around for questions after this, so I'll take a look at those questions. So in your scan results, I just want to give you a quick overview of what we've got here. We've got one-scan results for Volnode Express in pre-production. It found nine paths, it gives you a summary of the high, medium, and low criticality issues that it found, how many of them, and when it finished. And then when you click in, when you click in Moondog H, I'll help you with that question in just a minute after I do a quick runthrough of this. Thanks for the questions, good question. Yeah, great answers Xeia. So, when you click into your scan results, you get all this additional details. It found a cross-site scripting issue reflected, so what that means is, it sent in some search text. Here, when I click into the cross-site scripted vulnerability in particular, I can get more detail. It says which path it found it on, and it shows me the request evidence that it gathered. So, this is the probe that it sent in. It sent in the request headers, and it entered into the search field, essentially as, hey, do you accept script tags in your search text? And do you reflect it back? Do you reflect it back to me? And the answer is, yes. Yes, it does. It reflects it right back to us which is terrible. So, I'll show you what this does in effect. If I were to enter this same script tag into the application by running search, and it pops up a little <a href="/tags/javascript">JavaScript</a> banner. Which of course is awful. That means that you can run arbitrary <a href="/tags/javascript">JavaScript</a> from within our application, and that's generally regarded as bad <a href="/tags/automated-security">security</a> practice. So, what we can do is, based on this request and response, we can also hit validate. And this gives us a curl command that we can run on the <a href="/tags/cli">console</a>. So, I could just copy this and run it from a <a href="/tags/cli">terminal</a> window. And I should see the same results. And I do, let's see here it is. Script, script, description. Here we go. Yeah, I lost it, in the, oh, here it is. Yeah, H1 script, alert, script. So, this is just a nice utility for developers that were working on this to validate the findings that the scanner is finding. So, I've validated that this is a real thing. I can take actions on it. I'd like to assign this, ideally. So, I don't have the integration set up, but normally, this would be a thing that would create a ticket in JIRA. So, I can say assigned, give it some notes. But if you've got this integrated with JIRA, it's gonna fill in all of the details about this, including a link back to these scan results so that developers who get assigned these tickets have all the same evidence to work with. I'll show you... So, I'll show you what that looks like. Here's a ticket that I created from another... A JIRA ticket that it created from another scan. And when I click into it, it's got all of this detail about the vulnerability. Including a link back to the scan results. And of course from there, you can look at all the evidence and so forth. There's a question about integration with GitHub's issue tracker. No, but that's a great idea. So, we'll take that back. So, add it to the roadmap? It's a very long road. We also got a question. Oh, I'm sorry.

We also got a question in the Q&amp;A, which is, what if we use <a href="/tags/yarn">Yarn</a>? Do we need to change anything on builder.yaml? Guess that's going back? Oh yeah. If you use <a href="/tags/yarn">Yarn</a>, you just use a <a href="/tags/yarn">Yarn</a> build instead of a <a href="/tags/yarn">Yarn</a>. I'm not sure what the <a href="/tags/yarn">Yarn</a> commands are, but you can do exactly the same thing with <a href="/tags/yarn">Yarn</a>. So, really all you need to do is however you can get your application up and running and listening in <a href="/tags/github-actions">GitHub actions</a>, it'll probably look similar to what I did. You can also put it in. A great way to do it is to put it in like <a href="/tags/containers">Docker</a> compose and have it, or just <a href="/tags/containers">Docker</a> itself, and you say <a href="/tags/containers">Docker</a> compose up. In fact, this application is also a <a href="/tags/containers">Docker</a> compose application. So, to run it locally, if you download this repository, you can just say <a href="/tags/containers">Docker</a> compose up dash dash build. It will build the app and run it in <a href="/tags/containers">Docker</a> compose.

We've got another question in the Discord which is, how does StackHawk handle apps with sensitive <a href="/tags/data">data</a>? Yes, it does. So, we try to limit the information that we send back to our platform to just the findings themselves and no details about your application or as little detail about your application as possible. So, if in the output of scan results, we see anything that looks like it might be sensitive <a href="/tags/data">data</a>, we're very careful to try and scrub that information out in display and yeah, anywhere that it might be displayed and we don't save that <a href="/tags/data">data</a> either. So, yes, we handle sensitive <a href="/tags/data">data</a> in applications.All right, so that's pretty much that. I want to show you a couple other features of HawkScan and the Stackhawk platform just to sort of finish this out. As you run scans, if you go over to this applications tab, that application ID, for instance, that we set up, you can always find it back here. For each environment that you run scans in you're gonna have another one of these cards show up and as you run scans, you'll get new bars that show up here. So I'll actually pop out to, may pop out to my other account where I've got a ton of different applications set up and I'll show you what that starts to look like as you scan multiple times in multiple environments. So under the applications tab, you'll see a couple of bars that you can select. You start to get this bar graph that fills out and it shows you sort of the profile of your application over time. So obviously the green and yellow are low and medium criticality alerts that I've found in this application over time. And I've been solving them and triaging them over time. So you see that those bars go down over time. You see these gray bars down below and start to fill in. And those gray bars indicate that you have triage some issues. So this is a nice view for showing you how your application's <a href="/tags/automated-security">security</a> profile has kind of changed over time and how your triaging is going. This is sort of the <a href="/tags/automated-security">security</a> professional view as opposed to the developers view.Looks like we've got another question. I missed the part about starting the local web server. So we added that to the builder.yaml file and in builder.yaml. So originally we had just gotten to the point where we installed dependencies. And then the next step is to run your application and have it set up and running and listening so it can be scanned. And that's what I did here. This is a <a href="/tags/nodejs">node.js</a> application. I used <a href="/tags/npm">NPM</a> as the package manager and build utility. So I did a <a href="/tags/npm">NPM</a> run start, but I used the ampersand to make it run in the background and I used nohub to detach from the tty. And that way it's running, but it can move on from this step to the next one. And then in the next step, we run hox scan.Another great question, how does it introspect scans and the routes that it goes to? So by default it uses a traditional web Spider, so it's gonna go look at slash and slash index and slash robots dot text. And it's gonna find any links in there and it's gonna follow those. And then it's gonna follow any links that it find in those and it's gonna spider through the site that way. But you can also give it an open API spec or you can give it, and that can be a file or an end point. You can also give it a WSDL file if you've got a SOAP application and you can also point it to a <a href="/tags/graphql">GraphQL</a> endpoint so it can go discover your <a href="/tags/graphql">GraphQL</a> structure and scan that intelligently as well and spider it. I think Zach, one thing we didn't go over or didn't show in this demo, but I think it's really helpful to understand how much coverage you're getting in your app, is if you kick off a scan, I mean, you don't, don't do the same thing. I know you're answering other questions. But for the folks that were wondering about introspection, if you kick off a scan and you navigate to the findings details, we do show exactly what ads are being crawled. Maybe Zach, you can bring that up. Yeah. So you go to a specific scan and you can dive into the scanned ads. Obviously with this Buln Django, it's a little bit of a smaller app, so not a ton of ads, but that works for, as Zach mentioned, <a href="/tags/web-apps">web apps</a>, APIs, graph QL also sorts of pieces. So you can make sure you're getting the right coverage.Yep. Another great question. How will this spider work with SPA on location change invoked by <a href="/tags/javascript">JavaScript</a>? So what we recommend is... Zach, I think you somehow got muted. Oh, there we go. How much did I lose? Okay. So there's a question about how does this spider work with a single page application, SPA, which are weird because they look like a normal web application, but all the links are, all the slugs are kind of fake. So we recommend that you scan the SPA itself with one type of application.

You can use StackHawk for that, but really where StackHawk shines is in the API and the <a href="/tags/backend">backend</a> of the SPA. So we would recommend that the API service that you've got behind your SPA, you have an open API spec for that. And you feed that to Hawk scan and you scan the API directly. So you'll find more, you'll find more that way. If you try and scan the SPA itself, yeah, the SPA tends to fake out scanners in terms of spidering. So the open API spec is definitely the way to go there.Another interesting thing to check out under plugin summary. So this tells you a little bit about the, these are OWASP zap plugins that were running against your application. So as your scan is running, I didn't show you this, but you can watch all of this fill in in real time. So if your scan happens to be going slowly, you can see where it is getting hung up and you can also see what it's running and what it's skipping. And you can change the profile of what it's looking at by going over to applications and say, click into this application. Go to Settings, and go to scan settings, technology flags. And in here, you can specify well, my application really only uses MySQL and the language that I used was <a href="/tags/javascript">JavaScript</a> and so forth. You can select out things and this will sort of reduce the set of plugins that run against your application. If you're pretty sure you know the technologies behind it and that can <a href="/tags/performance">speed up</a> your scan.No, Rebecca, are you? Now I'm muted. We did, I missed a question in the Q&amp;A earlier, which I wanted to revisit, which is, can the build and scan workflow be set to only trigger on a single branch? Yes. Let me show you how. So we said push here, if we just wanted to trigger on, I think this is the notation for it. You could say, oh man, Oh, I know what it is. So that would be the kind of notation that you could use to select which branches you want to use. Awesome. Got another question in the Discord. I'm loving all the questions we're getting which is, can StackHawk scan with random transports slash fuzz the payloads or exclusively for <a href="/tags/automated-security">security</a> flaws? It's a great question. Some of the plugins do a form of fuzzing to sort of randomize the inputs and see what it gets as outputs. But primarily it is looking for <a href="/tags/automated-security">security</a> flaws. I know that Oasp Zap is currently working on adding more fuzzing capabilities and plugins to it. So there's more of that coming. So I think the answer is, yeah, a little bit and more coming soon. And there, is it interesting, I don't know if anyone here attended ZappCon this year. There was an interesting talk on adding fuzzing to Zapp runs, which I will try to find and drop into the discord server later today. It was very interesting for those that want to do more fuzzing capabilities.All right, well, I think the questions are slowing down a little, but Zack and I will be here in the discord all week all week next week. We're really looking forward to a great JS Nation event. If you start scanning a different app that isn't this Vuln node app and run into problems, feel free to reach out to Zack or I in the discord or Zack's information is here on the slide as well. All right, wonderful. Well, thank you everybody for joining. We had a ton of fun. Hopefully you've learned some new pieces that you can add to your build pipelines and make sure you're running those <a href="/tags/automated-security">security</a> <a href="/tags/testing">testing</a> in <a href="/tags/ci-cd">CI CD</a>. If there's ever anything we can help you with in the future, feel free to reach out. Otherwise, it was great hanging out with all you guys this morning. Thanks everybody. Thanks, bye.

JSNation Live

JSNation Live 2021

JS Security Testing in GitHub Actions

Pruebas de seguridad de JS en GitHub Actions

This workshop covers automating application security testing in GitHub Actions, including SCA, SAST, and DAST. GitHub Actions is a CI/CD system with built-in secrets management and 2000 free minutes per month. Dependabot is recommended for SCA, CodeQL for SAST, and StackHawk for DAST. StackHawk scans applications, identifies vulnerabilities, and provides triage capabilities. It supports various authentication methods and can scan APIs and backends of SPAs.

- 00:11 - Intro
- 02:13 - Prerequisites
- 02:55 - Overview of SCA, SAST, and DAST
- 07:50 - Overview of GitHub Actions
- 09:42 - Create a GitHub Actions Workflow
- 16:20 - Add Dependabot SCA
- 24:25 - Add CodeQL SAST
- 33:20 - Add StackHawk DAST

Leading teams are realizing that periodical penetration testing and security audits is not enough when code is being shipped daily. Instead, these teams are using developer-centric tools to run automated security testing in a CI/CD pipeline. Join Zachary Conger as he walks through how to automate application JS security testing using GitHub actions. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Zachary Conger

JS Nation

I’m attending JSNation – the main JavaScript conference of the year. You may join me there for free with 10k other JS engineers and 40+ great speakers. Just follow this badge. 

#javascript

JSNation 2024

Vue.js Live Conference

I'm attending Vue.js Live 2024 – get your free remote ticket and join me there with 5k other Vue.js engineers and 15+ great speakers.

Vue.js Live 2024

C3 Dev Festival

Join me at C3 Dev Fest, a contemporary software engineering festival!

Register to win an all-paid trip to Amsterdam. Elevate your career with industry experts and workshops & rock 3 dance stages at the after-party!

C3 Dev Festival 2024

React Summit

I am attending the biggest #Reactjs conference remotely. You may get a limited free ticket (50% of talks, no workshops) and join me by clicking this badge.

#react #reactjs

React Summit 2024

TechLead Conference

I'm attending TechLead Conference 2024 – get your free remote ticket and join me there

TechLead Conference 2024

React Advanced

React Advanced Conference 2024

Productivity Conference

Productivity Conference 2024

JSNation US

I’m attending JSNation US. Join me there for free with 10k other JS engineers and 50+ great speakers. Just follow this badge.