The other day, one of our awesome new StackHawk customers asked, “Hey, do you have a list of the top best practices for new StackHawk customers? We want to make sure we’re getting the most out of this tool.”
What a fantastic idea! Over here on the Customer Success team, we are obsessed with ensuring our customers achieve maximum value for their investment. After all, you purchased StackHawk because you want to shift left, and we’d like to help that happen. So, without further ado, here are our top 4 best practices as you roll out with StackHawk:
Include Devs Early and Often
First, and perhaps most importantly, remember that StackHawk was built with devs in mind. StackHawk was designed to be automated into the CI/CD pipeline, allowing your engineers to find and fix vulnerabilities before deployment. After all, that’s what we mean by shifting left.
Ideally, StackHawk will become a welcome and routine part of the workflow for your developers, helping ease their worries about vulnerabilities long before your apps make their way to a customer.
In order to truly shift left with StackHawk, consider including devs from the beginning. Invite them to demos and POV sessions during the procurement process. Include them on invites for kick-offs and health checks with your Customer Success Manager or technical calls with a Solution Architect. If you have a shared Slack channel with StackHawk, make sure devs are included.
By taking this approach to shifting left, you will help build more buy-in from your Engineering team and improve Security-Engineering alignment.
Triage Initial Findings
One of the many benefits of Dast scanning is that it reduces noise, allowing the engineering team to focus only on new or critical findings. If StackHawk is your first Dast tool, however, you may get a lot of results on that first scan. This can feel like a daunting problem to hand off to an already super busy engineering team.
One best practice we recommend is to do a triage and remediation session for those initial findings. This baselines the application you’re scanning, allowing you to hand off StackHawk to your devs with no tech debt. Go through your initial findings and mark them as “risk accepted” for low-risk vulnerabilities, “false positives” where applicable, or create and assign tickets for remediation.
The result? A beautifully clean slate to hand off to Engineering. Instead of wading through a bunch of old or irrelevant results, your devs can simply focus on any new vulnerabilities that are found.
Don’t Forget to Set Tech Flags
Speaking of false positives, StackHawk customers eager to get the most out of their new tool optimize their set-up to be as tailored as possible. One easy way to do this is to set tech flags.
This simply means unchecking any apps or technologies (like databases and programming languages) you don’t use as an organization, which in turn stops those items from causing false positives. Now, your scans will be set to only focus on the technology you actually use.
Don’t Be Shy About Authentication
While any scanning may be considered better than no scanning, in order to get deeper and more comprehensive scan results, you will have to look at authentication. Chances are that many paths of your applications or APIs are protected by authentication. In order for StackHawk to access those protected paths, you will need to set up authenticated scans within StackHawk.
Luckily, we’ve created tools to help you do just that. The most common approach is to configure the stackhawk.yml file with your application’s authentication flow information.
For a more in-depth look at authenticated scanning, check out this helpful guide.
So there you have it- a few simple ways to make the absolute most of your investment in StackHawk. Hungry for more knowledge? Check out our extensive and easy-to-follow docs library.
Casey Cline is a Senior Customer Success Manager at StackHawk.
