Scan Creation Recommendations

Prev Next

Creating efficient, targeted test scans is critical for maximizing coverage and minimizing runtime when testing your application ecosystem. This document outlines recommended ways to structure scans to ensure reliable execution, predictable outcomes, and continuous security improvement.

The recommendations focus on:

  • Grouping attack types logically

  • Managing the number of tests and assets per scan

  • Scheduling scans effectively

  • Running scans safely across environments


Attack types

The following breakdown groups attacks into logical scans based on common categories and test volumes. Each scan recommendation also includes approximate test counts and suggested scan frequency. You can use the Attack Selections below when creating a policy, and then use the policy when creating a scan. While creating the scan, you can also use the recommended schedule. For information on how to split scans by attack type and asset, see Number of Tests and Assets.

Scan Type

Attack Selections

Recommended Schedule

Approximate Tests

Remote Code Execution Scan

  • PHP-CGI Remote Code Execution (CVE-2024-4577)

  • Shell Shock Remote Code Execution (CVE-2014-6271)

  • Expression Language Injection

  • OS Command Injection

  • Buffer Overflow

  • Integer Overflow Error

  • Java Log4Shell (CVE-2021-44228)

Weekly

800,000

DB Attacks Scan

  • Error-Based SQL Injection

  • Blind NoSQL Injection

  • Blind SQL Injection

Weekly

800,000

XSS Attacks Scan

  • Reflected Cross-Site Scripting

Weekly

900,000

Design and Configuration Attacks Scan

  • XXE Remote File Inclusion

  • Directory Listing Leak

  • GraphQL Field Duplication Attack

  • GraphQL Alias-Based Attack

  • GraphQL Interface Protection

  • Bypass

  • Resource Intensive GraphQL Query

  • GraphQL Batch Query Attack

  • GraphQL Interface Exposure

  • GraphQL Field Suggestion

  • Graphql Introspection

  • HTTP Redirect

  • Server Version Disclosure

  • Cross-Domain Misconfiguration

  • XXE Local File Inclusion

Daily

235,000

Protocol Attacks Scan

  • TLS Certificate Transparency

  • BREACH

  • HEARTBLEED (CVE-2014-0160)

  • ROBOT (CVE-2017-13099)

  • TLS Certificate Wildcard

  • SSL/TLS Weak Ciphers

  • SSL/TLS Expired Certificate

  • TLS Not Implemented

  • Browser Exploit Against SSL/TLS (BEAST) (CVE-2011-3389)

  • Revoked Certificate

  • SWEET32 - Birthday attacks against TLS ciphers with 64bit block size (CVE-2016-2183)

  • Self Signed Certificate

  • Broken Certificate Chain

  • SSL/TLS Diffie-Hellman Attack (Logjam) (CVE-2015-4000)

  • Padding Oracle on Downgraded Legacy Encryption (POODLE) (CVE-2014-3566)

  • Certificate Common Name Mismatch

  • TLS/DTLS CBC Attack (Lucky13) (CVE-2013-0169)

  • Compression Ratio Info-leak Made Easy (CRIME) (CVE-2012-4929)

  • HTTPS Content Available via HTTP

  • HTTP Redirect

  • Insecure HTTP Method

  • GET for POST

Daily

200,000

Auth and Business Attacks Scan

  • Parameter Pollution

  • Weak Password

  • Mass Assignment

  • All JWT (JSON Web Token) Category

  • Parameter Tampering

  • Server-Side Request Forgery Blind

  • Unauthenticated Access

  • Multiple Versions of API

  • Broken Object Level Authorization

  • CRLF Injection

Daily

113,000


Number of tests and assets

When the number of attacks or target assets is high, Traceable recommends splitting a large scan into multiple smaller scans. This approach helps:

  • Ensure scans complete efficiently without overutilizing resources

  • Prevent long-running scans that may time out or fail due to connectivity issues

You can split scans in either of the following ways:

Split by Attack Type

Divide the attack selections into multiple sets and create a separate policy for each set. You can then use each policy in its own scan.

Example:

If a DB Attacks Scan contains approximately 800,000 tests across three attack selections, you can split it into three policies, each containing a single attack selection. Further, you can assign them to three separate scans, distributing tests and improving execution reliability.

Split by Assets

Divide the list of APIs across multiple scans while keeping the same attack policy.

Example:

If you are testing Cross-Site Scripting on 5,000 APIs using the XSS Attacks Scan (approximately 900,000 tests), you can create one policy with the Reflected Cross-Site Scripting attack selection. Further, you can assign this policy to two separate scans, each covering 2,500 APIs.

For information on the steps to create a scan, see Creating a Scan.


Operational best practices for reliable scans

To ensure safe execution, consistent results, and minimal operational overhead as you execute scans, Traceable recommends the following best practices:

  • Centralize authentication on the Traceable platform — Configure an authentication of your choice on the Traceable platform so that XAST Live, Replay, and DAST scans do not depend on individual user tokens. This reduces scan failures caused by expired or revoked tokens.

  • Use environment variables for sensitive credentials — Store API keys and secrets in environment variables to prevent accidental exposure and simplify updates.

  • Run XAST Live scans outside production environments when possible — Run XAST Live scans in sandbox or pre-production environments to avoid any interaction with real users.

  • Use a dedicated test user for XAST Live and Replay scans — Configure a pre-hook that authenticates using a test user. This keeps scans isolated and prevents any unintended changes to real user accounts.