Suites

A Suite is a combination of a group of scans with common configurations of policy and schedule. They help group similar scans together in an environment. As the scans are executed several times, suites help organize the related scans together. While creating a suite, you can configure several scan properties such as type, scope, authentication, etc. The subsequent scans are executed using these configurations.

The API Security Suites page provides a summarized view of vulnerabilities across a set of scans. The displayed suites are environment-specific, or you can view the suites for all the environments together. Using Suites, you can also create scans. Note that you must choose a specific environment to create a scan. The following screenshot shows the Suites dashboard.

In the above screenshot, All Environments is selected from the drop-down list. Hence, Quick Scan and Create Suite are greyed out. The Suites dashboard in the above screenshot shows three suites across all the environments. Following is a summary of information that is available from the dashboard:

• A total of four suites are displayed in the Suites dashboard.

• If you hover over a scan, as shown for Quick Scan above, you can view the number of Low, Medium, High, and Critical vulnerabilities found in that scan.

• Except for Quick Scan, all the suites are based on a scan policy. The other three suites are attached to the allattackspolicy policy.

• A total of 1.59K scans were completed, 0 scans were scheduled, 7 aborted scans were completed, and 0 scans are running.

XAST live, XAST replay, and DAST

As explained in the next section, the creation of a suite is based on the choice of traffic from XAST live, XAST replay, and DAST. This section explains what these are and the benefits of choosing one of them.

XAST live

XAST uses live traffic to secure your APIs without needing extra setup or authentication. XAST Live uses existing traffic from tests and applies innovative changes to simulate attacks, finding vulnerabilities in real time. Following are a few benefits of using XAST live traffic:

• No extra configuration — You can utilize the existing test environments and authentication mechanism.

• Real-time testing — You can assess your API security against live traffic for immediate feedback.

• Actionable insights — Receive specific, direct information to remediate potential threats quickly.

XAST replay

Traceable’s xAST Replay feature provides the distinct ability to replay historical traffic, including authentication data, for comprehensive vulnerability testing. This approach guarantees that previous traffic patterns are thoroughly examined and that historical data inform your API's security measures. Following are a few benefits of using XAST replay traffic:

• Historical Context — Employ historical data to conduct thorough vulnerability assessments, reducing reliance on current data availability and expanding coverage.

• Authentication Testing — To assess security, perform authentication testing using custom authentication methods and role-based access controls, including replay attacks.

• Precise Vulnerability Detection — Re-enact specific traffic scenarios to identify weaknesses and vulnerabilities in the system precisely.

DAST

Traceable's Dynamic Application Security Testing (DAST) Scan surpasses conventional DAST solutions by integrating API context and leveraging data-informed insights, enhancing detection capabilities. Following are a few benefits of using DAST scan:

• Advanced Detection — Leverage our contextually rich analysis to identify vulnerabilities accurately.

• Integration Readiness — Seamlessly integrate testing by utilizing OpenAPI specifications or Postman collections.

• Data-Driven Insights — Harness Traceable's data intelligence to improve the accuracy of vulnerability assessment results.

The below table lists down the comparison between XAST live, DAST, and XAST replay traffic types:

Create a suite

To create a new suite, select the Environment for which you wish to create a suite. Then, click on Create Suite from your environment-specific suite page, as shown below.

Creating a suite consists of the following four steps:

1. Choosing a policy for the Suite and giving other details like the type of traffic.

2. Choosing the assets (API endpoints) on which you wish to run the scan.

3. Setting up the schedule (optional) and a few other configurations.

4. Optionally adding an integration.

Step 1 — Provide details

As part of step 1 to create a Suite, provide the following details:

• Name — Provide a name that will help you identify the Suite. The name should not have any spaces.

• Policy — Select a policy from the drop-down list. A scan is related to an existing policy. Only when you run a Quick Scan, you do not need a policy.

  Note

  As part of the suite, Traceable detects only the vulnerability types configured during policy creation.

• Traffic type — Choose a traffic type from XAST live, DAST, or XAST replay.

  • XAST replay — The XAST replay scan is executed using stored APIs. This is possible in environments with replay enabled. For more information, see Environment Config.

  • DAST — You can run a DAST scan using the existing OpenAPI spec or upload a fresh OpenAPI spec. You can select one or more OpenAPI Specs. You can also upload a Postman collection or use a GraphQL schema to run a DAST scan. Traceable also provides the GraphQL public API that allows you to create a suite for GraphQL schemas. For more information, see Create a suite using the GraphQL public API.

    Note

    DAST does not require you to instrument an app, however, you must choose an environment for the DAST scan to create the default service and list the APIs under it. By default, the service name is traceable-oas-processor.

  • XAST live — Run the scan on live traffic.

• Environment — The environment for which you want to run the AST scans. Since Suite is environment-specific, this is preselected based on the environment you selected from the Environment drop-down. For example, the HighTechApp environment is specified in the above screenshot.

• Target URL—Configure this option to test a specific domain, such as mydomain.com. This is optional if you are using live traffic because AST targets the domain to which the live traffic is going. It is mandatory if you have selected DAST.

  Note

  You can allow Traceable to fetch the Target URL from the document that you upload above. While this feature is disabled by default, you can execute the --target-url-suite = false command in your CLI to enable it.

Step 2 — Choose assets

In step 2, choose the assets you wish to run the scan on. You can choose from:

• All Endpoints 

• A set of Endpoints 

• Services

• Endpoint Labels — All Endpoints are tagged with a specific label, such as critical, sensitive, external, etc.

• Filter endpoints — You can create your filter to choose the endpoints you want to scan. For example, you can select all external APIs, APIs with the GET method, APIs with sensitive data, etc.
  

As shown in the above screenshot, the following are some optional configurations that you can use according to your requirements:

Incremental Scans (Optional)

Traceable allows incremental scans on your suite, meaning it only scans the endpoints not scanned in the previous suite run. These may be the ones where they were skipped for some reason, were added to the scan scope post-last run, or were discovered in the environment after the last run was complete. This feature reduces the time required to rerun a scan on the suite. You can also run a full scan after a specific number of days. The following are some caveats associated with incremental scans:

Caveats

• You may have changed the attack set against which the application is tested between the successive scans. In such a case, a complete scan is run.

• Once an endpoint is scanned, its signature or other properties might change. For example, an endpoint that was previously unencrypted may now be encrypted. Such changes can affect how the endpoint was scanned in the past and how it will be scanned in the future. Therefore, whenever any such significant change occurs, the endpoint is re-scanned, regardless of whether it has been checked before or not.

• Sometimes, the endpoint's signature might not change, but it could still become vulnerable for other reasons. To catch these problems, we recommend setting a short look-back window to ensure all endpoints are regularly re-scanned.

Advanced configuration (Optional)

You can use regex expressions to include URL regex based on which Traceable filters the incoming traffic to be included. Similarly, the exclude URL regex is a type of regex based on which Traceable filters the incoming traffic to be excluded.

Include Traffic Matching Following Conditions (Optional)

You can specify conditions according to your requirements based on which Traceable filters the incoming traffic and runs scan on it. This is useful when you are receiving excessive traffic and want to run scans on its subset.

Note

You can filter traffic only for XAST live and XAST replay traffic types.

To include traffic according to certain conditions, you can click on Add Condition and:

• Select the Location on which you want to apply the filter.

• Select and specify the parameters under Attribute Key.

• Select and specify the parameters under Attribute Value.

Similarly, you can add multiple conditions to filter traffic. However, the API traffic must fulfill all the conditions for Traceable to run scans on it.

Authentication (Optional)

You can also choose the authentication type. For more information on different authentication types, see Authentication.

Step 3 — Configurations

In step 3, add a schedule for your scan. Adding a schedule is optional. In addition to adding a schedule, you can configure the scan evaluation criteria and choose one from the following three default options. You can also create your custom criteria. The scan evaluation criteria decide on what criteria a scan would fail. This is based on the type of vulnerabilities found in the scan.

• Fail on any

• Fail on critical

• Fail on high and above

You can also set other configurations, such as idle time out, scan time out, delay between requests in milliseconds, and test execution threads.

Step 4 — Integrations

Step 4 is optional. You can currently integrate Snyk with the scans. For more information, see Snyk topic.

Suite details

The Suites detail page has three tabs: Vulnerabilities, Scans, and Details. Once you have created a suite, the scans run according to your configured schedule and frequency. The scan results are the vulnerabilities found and are displayed as a bar chart on the Suites dashboard (as shown in the first screenshot).

Vulnerabilities

When you click on a suite, it displays rich information about the vulnerabilities by severity and the type of vulnerability found in scans. You can click on a vulnerability to see the API endpoints containing that vulnerability. You can also click on each API endpoint to see the evidence for it, any assertions and mutations used to detect that vulnerability. On this evidence page, you can customize the Assertions and Mutations from their respective tabs to customize the vulnerability detection according to your requirements. For more information, see Mutation and Assertion Overrides.

Auto-resolution of vulnerabilities

Traceable, by default, auto-resolves vulnerabilities in the following scenarios:

• Traceable has not detected the issue in the 60 days since its last occurrence.

• Traceable does not detect the vulnerability in the 15 scans following its last observation.

While the above are default durations, you can contact Traceable support to modify them according to your requirements.

The Scans tab lists all the scans that have run, or queued for the Suite. You can click on any scan to view more information about each scan. The Scan tab shows the following information for each scan:

• Overview—Provides various details about the scan, such as the environment scanned, the number of APIs scanned, and the traffic type.

• API coverage — The API Coverage tab provides information under the following categories:

  • APIs scanned — This tab lists all the APIs scanned, the vulnerabilities found in each scanned API, the number of tests generated and executed for each API, and other high-level information about each API.

  • APIs not scanned — This tab provides information about the APIs that were not scanned and the reason for them not being checked.

  • API reachability — This tab lists all the APIs that are reachable, not reachable, or return an error.

• Tests — This tab lists all the tests run across all the APIs and the vulnerabilities found across them. You can filter these results based on the API endpoint, which shows all the tests run on an API, or based on a specific vulnerability to see in which APIs a specific vulnerability exists, etc.

• Logs — This tab lists the scan logs. You can download the log for further analysis. You can choose to display the first 500 lines of the log, the last 500 lines of the log, etc.

While the above details are present for each scan, traces are not shown in the following scenarios:

• APIs not instrumented — If a scan is run against APIs not instrumented by any of Traceable’s tracing agents, then traces are not found for the scan results. This mostly occurs in DAST scans run using specifications like Open API Spec, Postman Collection, or GraphQL Schema. However, if the DAST scan internally uses replay data, then traces are found.

• APIs are instrumented but devoid of live traffic — If the API under test is instrumented but has not seen any live traffic with an error-free response code, then Traceable does not show that API in the API Catalog. When scans are run against such APIs and if the AST attack test request receives only error response codes, Traceable does not register these APIs. This is because API Catalog only registers an API upon seeing an error-free response code. Therefore, traces are not found in such APIs.

• Error in generating or sending request — If Traceable CLI encounters an error while creating an attack request or fails to send it for some reason, the test results in an error, and traces are not found for that API.

• Passive and TLS test — AST has passive plugins that do not send any attack request to APIs under test but check the original request for any vulnerabilities. Similarly, TLS tests are connected to the host or domain, not the API. In both scenarios, traces are not found.

• Tests older than one week — Traceable, by default, has a one-week trace retention period. So, if the test is older than a week, traces are not found for it.

Details tab

The details tab provides a summary of the Suite. It gives basic information, such as the Suite name, policy name, the type of traffic, etc. It also gives you information about the assets, the kind of traffic, etc.

Reset Incremental Scans

You can reset any configurations set for incremental scans. Then, Traceable scans all APIs you selected during suite creation in every run. You can re-enable the incremental scans feature by clicking the Edit icon corresponding to the Assets section in the Details tab.

Delete a suite

You can delete a suite from the Details tab.

Note

A suite once deleted, cannot be restored.