Setting Technology Flags for your application allows the scanner to be more specific in how it scans by tailoring for the technologies used in your application. This will ultimately narrow the scope of the tests being run, increasing scanner performance and potentially decreasing scan times.

When creating an application in StackHawk, all Technology Flags will be enabled by default. We currently offer the ability to set flags for your Databases, Languages, Operating Systems, SCM, and Web Services specific to your application.

Check out our how-to for Setting Technology Flags in StackHawk!

When using HawkScan, it is recommended that you scan your application in a "Pre-Production" environment. This is beneficial for developmental reasons, like identifying vulnerabilities before being pushed into production. However, it also prevents the scanner from running into restrictions potentially imposed by production environments.
​
A great example is WAFs (Web Application Firewall) or Proxies. While these are great tools to protect your application in a production environment, they create a layer between your application and the scanner. This prevents the scanner from assessing the raw vulnerabilities within your application and creates a barrier that will increase the time it takes to complete a scan.
​
For more information about Best Practices and Scanning Environments, take a look at our guide here!

Whether you are running HawkScan locally or in a Docker container, by default, it uses one-third of the available memory of the host it is running on. If your application is particularly large and has a significant number of paths, allocating more available memory to the scanner can potentially increase its performance and throughput.

If sufficient memory is available, you can increase the amount used by HawkScan by passing an environment variable at runtime!

For further insight on tuning memory allocation for your application and environment, check out our how-to here!

An application and its functions might vary significantly and be dynamic with different technologies. While these different sides of your application need to be scanned, consolidating them into a single scan could degrade scanner performance and skew the results you are getting back.

For example, you might have a single-page application that you want to scan with the Base Spider. The front end of this application will likely require a much simpler configuration, while scanning the API behind this single-page application will likely require a more complex authentication flow. By separating your scans from these two sides of your application, you can increase scanner efficiency and improve results.

In addition to varying technologies, having a relatively large application can produce similar latency. If your application has a significant number of paths to be scanned, this can ultimately create lengthy scan times. By breaking up a large application into multiple scans with fewer paths. You can get the scanner to run faster and with more efficiency.
​

While there are many potential culprits for an increase in overall scan times, there are things local to your scanning environment that could contribute to longer than normal scan times. Keep on the lookout for things like Rate Limiters or General Network Latency. If something in your environment is slowing down or holding back, it will ultimately degrade the speed and performance of the scanner.
​
​

If you still have issues decreasing lengthy scan times, don't hesitate to get in touch with our Support Team! We would be more than happy to take a deeper look and see what we can do to improve your results.
​
You can contact us by emailing support@stackhawk.com or by chatting in through the chat widget on our website!
​
​