Getting Started with AST
  • 14 Aug 2024
  • 7 Minutes to read
  • PDF

Getting Started with AST

  • PDF

Article summary

API Security Testing (AST) leverages a combination of multiple components working together. It aids seamless interaction between these components, ensuring robust and effective security testing and monitoring. Following are some of the components in AST:

AST components

Suites

API Security Suite is AST’s main component, meaning all other components lie within it. Suites are a collection of tests grouped to assess the security of your application. They are environment-specific and include various test cases and rules that allow you to comprehensively test according to your use case. While creating a suite, you must do the following:

  • Select the policy and traffic type.

  • Configure Assets (Endpoints, conditions, and some optional configurations)

  • Configure Schedule and Scan Runtime (Execution threads, delays, and other configurations)

  • Configure Integration (Snyk)

The following traffic types are available in Traceable:

  • XAST live

  • DAST — OpenAPI spec, Postman collection, and GraphQL schema.

  • XAST replay

If you want to quickly detect critical vulnerabilities without running a suite scan, you can also create a quick scan that provides a high-level overview of your application security. To create a quick scan, select the traffic type, endpoints, and some optional configurations. For more information on Suites, see Suites.

Policies

Policies are a collection of test (attack) plugins and enforcement configurations on the type of requests to send to your application, based on which Traceable detects vulnerabilities. Multiple suites can share a policy. Traceable provides pre-defined policies created to detect the most common vulnerabilities. For example, the SafeScanPolicy provided by Traceable restricts the plugins from doing only non-state-changing operations on the HTTP GET method.

Safe Scan Policy


Apart from the pre-defined policies, you can also create custom policies according to your requirements. While creating a policy, you must select the attacks you want to execute as part of the suite along with some advanced configurations. Attacks are nothing but vulnerability types provided by Traceable out-of-the-box or the ones you create. For more information on Policies, see Policies.

Vulnerability Types

These are the security weaknesses Traceable can detect while running the security tests on your application. Traceable provides some pre-defined vulnerability types that are most commonly found in applications. However, you can also create custom vulnerability types according to your requirements. While the pre-defined vulnerability types are used in the plugins provided by Traceable out-of-the-box, the custom vulnerability types are used in custom plugins. While creating a vulnerability type, you must define the logic for the vulnerability, such as the CVSS score, string, severity, and other attributes.

Test Plugins

This is the component that enhances the security assessment of your application. They are created to customize the security testing by adding specific checks according to your requirements. Traceable provides some pre-defined plugins that are most commonly used in security assessments. These plugins use the vulnerability types that Traceable delivers out of the box. You can also create custom plugins that generate custom vulnerability types. While creating these custom plugins, you must define its logic using mutations, assertions, and other attributes. For more information on these plugins, see Test and Custom Plugins.

Runners

Runners execute scans on your applications or APIs, making them one of the most important components of AST. They are responsible for running tests using the configured suites and plugins and building a report on the detected vulnerabilities. Traceable provides multiple ways of configuring runners: from the UI, as a service, and using a helm chart. For more information on these runners, see Runners.

Reports

This page lists the results or reports sent by the runner and displays them on the UI. It is mainly useful when you want to view detailed reports of the scans executed within your selected time duration.

Apart from the above, Traceable also has some components that you can use according to your requirements:

Environment Config (Optional)

This component allows you to do the following on your environments:

  • Enable or disable API security testing

  • Enable or disable XAST Replays

This is mainly useful in scenarios where you want granular control over the creation of suites in certain environments, such as production environments that contain important data. For more information on these configurations, see Environment Config.

Authentications (Optional)

This component lets you define authentication mechanisms for your application security scans. This is helpful in scenarios where you want to run long-running scans. Traceable provides the standard and advanced modes to define the authentication according to your requirements. For more information on the supported authentication mechanisms, see Authentication.

Evaluation Criteria (Optional)

Using this component, you can define the set of rules or benchmarks based on which Traceable should assess the results of your AST scans or fail scans in CI/CD. These rules define how the scans are evaluated based on certain attributes such as vulnerability, severity, and threshold. This is helpful in scenarios where you want to focus on specific threats according to your business needs and make decisions based on results returned from the tests. For more information on these rules, see Scan evaluation criteria.


Next Steps

Now that you have an understanding of the components and how they work together, you can start using AST by doing the following:

  1. Download and install a runner. For the steps to do this, see Runners.

  2. (Optional) Enable AST or replays on environments. For the steps to do this, see Environment Config.

  3. (Optional) Define evaluation criteria according to your requirements. For the steps to take to do this, see the Scan evaluation criteria.

  4. (Optional) Define the authentication mechanism for your tests. For the steps to do this, see Authentication.

  5. (Optional) Create a custom vulnerability type according to your requirements.

  6. (Optional) Create a custom plugin to detect a custom vulnerability. For the steps to do this, see Test and Custom Plugins.

  7. (Optional) Create a custom policy according to your requirements. For the steps to do this, see Policies.

  8. Use the above components, if created, and create a suite. Optionally, create a quick scan. For the steps to do this, see Suites.

The following section explains how data flows between the above components after you have created a suite.


Data flow post-suite creation

As soon as you create a suite, the above components start interacting with each other to execute the tests on your API endpoints and show the result on the Traceable platform. The following image shows the flow of data between components and their interaction for providing a result:

Working of AST

  • Data — This consists of the various ways Traceable can receive traffic. These are the traffic types that you can choose from when creating a suite.

    traceable_ast_working_traffic_type


    Based on the traffic type you select, Traceable generates the following:

    • Traces for live traffic, replay traffic, and postman collections as they contain examples of API requests and responses, providing or simulating real traffic.

    • Sudo Traffic for Open API and GraphQL specifications as they provide expected API behavior and endpoints rather than real traffic.

    After you have created the suite, based on the selected policy, endpoints, and configurations, Traceable sends the data for test suite generation.

  • Platform — Traceable, upon receiving data from your application, processes it and generates test suites. These test suites contain details about the following:

    • Traffic metadata — The test suite, original request, and response.

    • Policy — The vulnerability type to test for, the hooks, mutations, and assertions defined in the test or custom plugin.

    Once Traceable generates the test suites, the data is sent to the CLI/runner for security testing.

  • CLI/Runner — The CLI/runner executes the tests on your application. It uses the test suite (containing plugins) to test for vulnerabilities in your application. The CLI/runner works in the following manner:

    1. Runs the test suite and plugin.

    2. Applies any pre-hooks and mutations.

    3. Parses the response and applies any assertions, as well as post-hooks.

    4. Builds the report and sends it to the platform.

  • Platform — The Traceable platform displays the report on the UI upon receiving it from the CLI/runner. You can view the detailed report for each scan and use it according to your requirements by navigating to TestingReports. Traceable also allows you to download the report.


Was this article helpful?

What's Next