Scan Creation Recommendations

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.