This article addresses some of the factors which have a significant affect on scan completion time, and the ways these can be adjusted.

• General
  • Scan Scope Size
  • Rate Limiting
  • Duplicate Scan Targets
  • Scan Hub Contention
• Web Application Scans
  • Application Response Times
  • Large and/or Complex Web Applications
  • Scan Multi-threading
  • Platform-Specific Checks for Platforms You Do Not Use
  • Time-Consuming Plugins and Settings
• Infrastructure Scans
  
  • Automatic Passive Web Application Scanning
  • UDP Port Scanning
  • Port Scan Timings

General

Scan Scope Size

It is advisable where possible to split large numbers of targets into individual smaller scans scheduled to run at different times.  This has two primary benefits: you will see results sooner as the first smaller scan completes earlier than one large scan would, and if there a problem occurs only a subset of the scan targets will be affected (potentially requiring re-scanning).

Rate Limiting

Some WAFs and IPS devices impose rate limiting which will (by design) slow down the scan to the extent that completing the scan will not be practical.  It is important that AppCheck's IP addresses are set to be allowed in such systems - see Allowing AppCheck Access to Your Network or Applications.

Duplicate Scan Targets

It is possible to configure your scan targets in such a way as to scan the same application multiple times within one scan.  See Application Scan Targets, Scope, Seeded Targets and Denied Targets.

While infrastructure targets will be deduplicated as you enter them, it is possible to scan the same host multiple times using different addresses, for example you may add both its hostname and IP address.

Scan Hub Contention

The amount of load on the scan hub running your scan can affect the speed of the scan. 

In the case of scans running on AppCheck's public scan hubs this should not be an issue.  However, contention is an important consideration when running scans from your a private scan hub within your infrastructure.  If running/scheduling multiples scans from a private hub, you should schedule these to run at different times as much as possible (or use multiple private hubs).

Web Application Scans

Application Response Times

Response times can also cause excessive scan times - if an application becomes unresponsive, it can cause a delay of a couple of seconds to every request. For a request that normally takes 200ms, if this then becomes 2.2 seconds there has been a tenfold (1000%) increase in scan times, which will clearly have a significant impact on the scanning time.

Large and/or Complex Web Applications

Scanning a web application involves identifying every possible point of attack in the application (building a Mapped Attack Surface), which could be form fields, URL parameters, etc, and then testing every one of those points for every possible type of vulnerability (each of which could involve multiple requests).

Your application may have many or large forms, or accept a large number of parameters, and so on.  The more such points of attack exist within the application the more requests will be required to scan it, and the longer the scan will take.

For example, if you are scanning with 100 scanner plugins enabled, each of which uses 10 requests to complete its tests (this is a hypothetical number, in reality it is not deterministic), then the scanner will need to send 1,000 requests to each point in the attack surface.  If the attack surface is a single path with no parameters, no request body, etc, then the scan requires simply 1,000 requests.  If the attack surface includes 10 parameters and 50 form fields then the scan requires at least 60,000 requests.

Scan Multi-threading

1. Web Application Scanner Settings
   1. Advanced Settings
      1. Max Threads

The web application scanner is multi-threaded, with each thread making requests to your application and analysing the results.  By increasing the maximum allowed number of such threads for your scan you can decrease the time taken, at the expense of more concurrent load on your application and infrastructure.

There is not quite a 1-to-1 relationship between threads and requests (and therefore with time taken, and load on your application), but increasing the number of threads can significantly reduce the time required (and reducing the number of threads can significantly reduce load on your application).

Platform-Specific Checks for Platforms You Do Not Use

The AppCheck scanner includes plugins aimed at specific platforms, such as certain types of database (MySQL, Postgres, etc) or CMS (eg WordPress, Umbraco, etc).  These can be found in:

1. Web Application Scanner Settings
   1. Plugins

Running these plugins can involve a lot of requests and substantially increase the time it takes to complete your scan.  If you are certain that a platform does not exist within your environment then you can disable checks aimed solely at that platform.

SQL Databases & SQL Injection

1. Web Application Scanner Settings
   1. Plugins
      1. Injection
         1. SQL & XPath Injection
            1. Configuration
               1. Supported Database Platforms

In the case of SQL Injection detection there is one plugin which can be configured with options for various database platforms.

Do not click the tick-box to disable the plugin unless your environment contains no SQL databases at all.  Instead, you'll usually want to configure the plugin to select which database platforms it should target.

Click the name of the plugin to open its settings panel, then the "Configuration" tab, then click the down arrow net to "Supported Database Platforms".  Here you can untick any that you do not use.  Finally, close the settings panel and don't forget to save the scan.

We recommend you only untick platforms that you definitely do not use - sometimes there can be a communication chain starting with your application which reaches other parts of your environment and interacts with database platforms you might not immediately think of when considering your one application in isolation.

Remember to review this list if you add to or change the platforms in your environment in the future.  You may wish to add a point to your change management policy to help with remembering this.

Content Management Systems

There are a numbers plugins aimed at various CMS platforms in the "Content Management Systems" section of the Plugins table.  You can simply untick the plugins for platforms you definitely do not use.

1. Web Application Scanner Settings
   1. Plugins
      1. Content Management Systems
         
         1. [CMS platform plugin]

Cloud Platforms

There are a numbers plugins aimed at various cloud platform provider in the "Cloud Hosting Environment Checks" section of the Plugins table.  You can simply untick the plugins for platforms you definitely do not use.

1. Web Application Scanner Settings
   1. Plugins
      1. Cloud Hosting Environment Checks
         
         1. [Cloud platform plugin]

Time-Consuming Plugins and Settings

AppCheck prioritises accuracy over scan time.  Some plugins are inherently time-consuming and cannot be accelerated without reducing accuracy.  In this case you may wish to disable these plugins, or use them only in a less frequently run scan.  For example you may have a weekly scan with these plugins disabled, and a monthly scan with them enabled.

SQL & XPath Injection

1. Web Application Scanner Settings
   1. Plugins
      1. Injection
         
         1. SQL & XPath Injection

SQL Injection vulnerabilities are common and high impact, but the plugin to detect them is time-consuming.  While disabling them completely would be unwise unless you're certain you have no vulnerable systems, saving them for a less frequently run scan could substantially accelerate your more frequent scans.  Also see Platform-Specific Checks for Platforms You Do Not Use and disable checks for platforms you are certain you do not have.

Command Injection

1. Web Application Scanner Settings
   1. Plugins
      1. Injection
         
         1. Command Injection

This is a time-consuming plugin to detect a rare vulnerability, it is therefore a logical choice to move to a less frequently run scan or even remove.

Path Traversal

1. Web Application Scanner Settings
   1. Plugins
      1. Injection
         
         1. Path Traversal

This detects a type of vulnerability that is more common than Command Injection but does take a substantial amount of time.  You may therefore wish to reserve this for less frequent scans.

JavaScript Library Validation

1. Web Application Scanner Settings
   1. Plugins
      1. Build and Configuration Review
         
         1. JavaScript Library Validation

This plugin reports on out-dated JavaScript libraries. Those libraries may contain vulnerabilities so knowing about them is important, but this is a time-consuming process which may be best in a less frequently run scan.

HTML5

1. Web Application Scanner Settings
   1. Plugins
      1. HTML5

This category contains a number of plugins relating to PostMessage and WebSocket.  These plugins can be time consuming and detect vulnerabilities which are both rare and low to medium impact.  You may therefore wish to reserve these plugins for less frequent scans or disable them entirely.

DOM Based Cross-Site Scripting

1. Web Application Scanner Settings
   1. Plugins
      1. Cross-Site Scripting
         1. DOM Based Cross-Site Scripting

This option tells AppCheck-NG to use a real browsers to detect and confirm XSS vulnerabilities. These checks can be very expensive, increasing the scan time.  Disabling this is not recommend but you may wish to reserve this for less frequent scans.

Brute Force Discovery

1. Web Application Scanner Settings
   1. Advanced Settings
      1. Brute Force Discovery

This controls if the scanner is to attempt to discover resources that would not normally be discovered during a crawl, looking for potentially hidden dangerous paths such as .git and .svn repositories.  Disabling this is not recommend but you may wish to reserve this for less frequent scans.

Infrastructure Scans

There are a number of settings for Infrastructure Scans which can make a small difference to the per-host scan time, which makes a big difference to overall scanning time when scanning a large number of hosts.  Therefore be sure to select either the Large Range or Small Range profile as appropriate when creating your Infrastructure Scan.

Automatic Passive Web Application Scanning

1. Infrastructure Scanner Settings
   1. Vulnerability Scanner
      1. Options
         1. Advanced Settings
            1. Automatically perform a passive web app scan against any discovered web applications.

This enables an optional is designed to give some coverage of web applications that you might not have thought to scan explicitly.  With this option enabled the scanner looks for signs of web applications running on various ports on the scanned hosts and for any it finds it runs a short passive web application scan (ie without sending active attack payloads).  This takes just a few minutes per discovered application and so is generally fine if you are scanning a small number of hosts, but if you scan a range of hundreds of hosts the time taken quickly adds up.

UDP Port Scanning

1. Infrastructure Scanner Settings
   1. Port Scanner
      
      1. UDP Scan

Scanning UDP ports can take a significant amount of time.  For more details, see also Port scanning - things to consider

Port Scan Timings

1. Infrastructure Scanner Settings
   1. Port Scanner
      
      1. Port Scan Timings

If UDP port scanning is enabled, this option controls how long to wait for a response before assuming the port is dead and moving on, longer timings should lead to more accurate results but the scan will take longer to complete. More aggressive timings will mean a scan completes faster but there is a chance of missing some services if no response is received in time.