Actions with security tools

This section describes how to add, edit, and delete integrations with security tools, the available security tools and their versions, considerations for working with SASTAV, and examples of integrations with security tools.

Available tools and their versions

The current system version supports the following security tools (see the table below).

Tool	Version
PT Application Inspector	5.0
Kaspersky Container Security	2.3
Solar AppScreener	3.15.5
Aqua	2022.4.759
CodeScoring	2025.29.3
Grype	0.106.0
KICS	2.1.19
OWASP Dependency Track	4.12.1
Trivy	0.68
Semgrep	1.146.0
ESLint	9.39.2
PVS-Studio	7.38
GitLab Advanced SAST	3.0.0
AppSec.Sting	2025.5
AppSec.Track	3.19
Gitleaks	8.30.0
SASTAV	2.4.0
TruffleHog	3.95.2

note

When you create a security check with Solar AppScreener, you can select the analysis type (SAST, DAST, or SCA).

Considerations for working with SASTAV

Keep the following points in mind when working with SASTAV:

1. When you authenticate while configuring the SASTAV integration, you must use a SASTAV service account.
2. SASTAV repositories must be unique across all system projects. When you create security checks with identical scan sources in different projects, SASTAV creates only one repository.
3. SASTAV scan results are generated in the corresponding security checks and projects during report parsing.
4. When you edit a security check, you can select the repository type:
   • Basic—limits the number of lines of code to 15,000;
   • Advanced—limits the number of lines of code to 1 million. This value is set by default.

5. Because of technical limitations on the number of SASTAV repositories, TRON ASOC lets you specify the maximum number of repositories. To do this, the SASTAV integration settings include the Maximum number of repositories parameter. When you enter a numeric value, the system monitors the number of active repositories. If you don't specify a value, the system applies the maximum limit available under the SASTAV license.

6. You can also clean up SASTAV repositories created by TRON ASOC. You can clean up repositories manually or automatically. For example, when you delete a security check, the system deletes the associated SASTAV repository if no other security checks in TRON ASOC use it.

Connect an integration with a security tool

info

To configure integrations with security tools, a user must have at least the following permissions:

• View tools;
• Manage tools.

To add a new integration with a security tool, follow these steps:

1. Go to Integrations → Security tools.
2. Select Add security tool.
3. Select the required security tool from the list of integrations.

4. Fill in the required Name and Description fields.

5. Select the tool access type:

   • Global—the integration is available in all projects;
   • Project—the integration is available only in selected projects. After you select this access type, select one or more projects where the integration will be available.
   tip

   When you select the Project access type, you can select the projects where the integration will be available using checkboxes.

   

6. Fill in the additional fields:

   • Tool description;
   • URL;
   • Scan results language;
   • Authentication method.
   info

   The set of additional fields depends on the selected security tool.

   You don't have to select an authentication method at this step. However, you can't test the connection to the tool without specifying an authentication method.

7. Fill in the fields based on the selected authentication method:

   • API token: API token field
   • Login/password: Login and Password fields
   • None. If you select the None authentication method, scanning won't be available, but users can manually import scan results.
   note

   Some tools also provide additional settings based on data received from the tool integration, such as license verification data and information about tool limitations. CodeScoring can use existing authentication data and provides additional integration settings.

8. If necessary, test the connection by selecting Test connection.

caution

You can test the connection only with the API token and Login/password authentication methods.

You can test the connection only if you've entered valid authentication data for the security tool. If the data is correct, the connection test succeeds. If the connection fails, verify the data and try again.

9. Select Create

Connect an integration with a custom security tool

You can also connect an integration with a custom security tool. You can use it to run security checks in TRON.ASOC or Kubernetes and import the results of security checks performed by the tool.

To connect a custom security tool, follow these steps:

1. Go to Integrations → Security tools.

2. Select Add security tool.

3. Select Add custom tool.

4. Select Run scans.

5. In the window that opens, specify the following tool parameters:

   • access type (global or project);
   • tool name;
   • tool version;
   • tool description;
   • tool URL;
   • timeout—the time after which the system stops trying to connect to the tool (for example, 10 minutes);
   • polling interval—the time between requests to the tool (for example, every 30 seconds).
   warning

   Setting a long timeout (more than 10 minutes) can cause a timeout during a test scan with the integration you've created.

6. Enter the tool's primary and confidential configuration settings.

   info

   See the section below for examples of tool configurations.

7. Select Create.

Examples of custom integration configuration settings

When you create a custom integration, you can specify two types of settings:

• primary setting—contains the configuration parameters required for the integration to work. Users with the appropriate permissions can view and edit these parameters;
• confidential setting—contains sensitive data that isn't displayed when users view or edit the tool.

We recommend using the primary setting for general connection and tool operation parameters, such as the service address, report format, scan results language, authentication method, and other configuration parameters. We recommend using the confidential setting for data that must have restricted access, such as API tokens, passwords, secret keys, and other credentials.

The contents and structure of the parameters in the primary and confidential settings depend on the requirements of the specific external tool. Parameters can be strings, numbers, Boolean values, arrays, and nested JSON objects.

The following example shows the settings and describes their parameters:

Primary setting:

{
  "url": "https://10.128.0.22",
  "scan_result_lang": "EN",
  "auth_method": "Api Token",
  "report_type": "Sarif",
  "is_encrypted": false,
  "timeout_minutes": 15,
  "poll_interval_seconds": 10
}

Confidential setting:

{
   "api_token": "xxxxxxxxxxxxxxxxxxxxxxxx",
   "client_secret": "xxxxxxxxxxxxxxxxxxxxxxxx",
   "password": "xxxxxxxxxxxxxxxxxxxxxxxx"
}

Parameter	Parameter description
url	Tool address
scan_result_lang	Scan results language
auth_method	Authentication method
report_type	Format of the report generated by the tool
is_encrypted	Indicates whether encryption is used
timeout_minutes	Maximum time to wait for the scan to finish
poll_interval_seconds	Scan status polling interval
api_token	Tool access token
client_secret	Client secret
password	Password for accessing the tool

Test scan with a custom integration

When you create a custom integration, you can also run a test scan. You can do this only if you've entered valid configuration settings.

To run a test scan, follow these steps:

1. Select Open in the Test scan section.

2. In the window that opens, specify the following:

   • the source to scan;
   • the source branch or tag;
   • additional tool settings.
   info

   The data you enter in the additional settings applies only to the test scan and isn't saved in the tool's general configuration.

3. Select Run.

Custom integration API contract in TRON.ASOC

Custom integrations connect to TRON.ASOC through the custom integration HTTP contract. A custom integration implements a fixed set of endpoints, and TRON.ASOC uses HTTP to manage the full scan lifecycle.

Request URL scheme

The system builds the request URL using the following template:

POST {url}/{endpoint}
Content-Type: application/json

where url is the value of the field with the same name in the custom integration settings:

{
  "tool_settings": {},
  "tool_secret_settings": {},
  "is_encrypted": false,
  "extra_settings": {},
  "url": "https://external-service"
}

Execution order

The contract endpoints run in the following order:

1. /validate—validates and normalizes the custom integration settings.
2. /test-connection—checks the availability of the custom integration and the credentials.
3. /join-settings—combines the custom integration settings and the check settings into join_tool_settings.
4. /run—runs the scan.
5. /scan-status—polls the status until it receives a final status.
6. When the system receives the uploaded, uploaded_minio, or done status, it calls the /get-result endpoint.
7. When a user cancels a scan, the system calls the /stop endpoint.

Contract endpoints

POST /validate

Purpose: Validates and normalizes the custom integration settings.

Request:

{
  "tool_settings": { "project_id": "example" },
  "tool_secret_settings": { "api_token": "secret" }
}

Expected response:

{
  "tool_settings": { "project_id": "example" }
}

You can also return updated tool_secret_settings.

TRON.ASOC behavior: Saves tool_settings from the response as the current integration settings.

POST /test-connection

Purpose: Checks the availability of the custom integration and the credentials.

Request: tool_settings, tool_secret_settings.

Successful response:

{ "status": "ok" }

Error response:

{ "status": "error", "error_msg": "Invalid credentials" }

TRON.ASOC behavior: Considers the connection test successful when status: ok; when status: error, displays the text from error_msg to the user.

POST /join-settings

Purpose: Combines the custom integration settings and the check settings.

Request: tool_settings, tool_secret_settings, extra_settings.

Expected response:

{
  "join_tool_settings": {
    "project_id": "example",
    "profile": "default",
    "api_token": "secret"
  }
}

TRON.ASOC behavior: Saves join_tool_settings and passes them without additional interpretation to /run, /scan-status, /get-result, and /stop.

POST /run

Purpose: Runs a scan using the custom integration.

Request:

{
  "scan_result": {
    "id": "asoc-scan-result-id",
    "task_uniq_name": "task-name",
    "tool_internal_task_id": "",
    "security_check_id": "check-id",
    "source_type_id": 1,
    "status": "in_queue",
    "result_details": {}
  },
  "join_tool_settings": {},
  "source_settings": {}
}

Expected response:

{
  "scan_result": {
    "id": "asoc-scan-result-id",
    "tool_internal_task_id": "external-task-id",
    "status": "in_progress"
  }
}

Required: The integration must return its own task ID in scan_result.tool_internal_task_id.

TRON.ASOC behavior: Saves tool_internal_task_id, changes the task status to in_progress, and starts polling /scan-status.

POST /scan-status

Purpose: Gets the current scan status.

Request: scan_result.id, scan_result.tool_internal_task_id, join_tool_settings, source_settings.

Expected response:

{
  "scan_result": {
    "id": "asoc-scan-result-id",
    "tool_internal_task_id": "external-task-id",
    "status": "in_progress"
  }
}

The table below lists the allowed status values and the system action for each status.

Status	TRON.ASOC action
in_queue	Continues polling
in_progress	Continues polling
uploaded	Calls /get-result
uploaded_minio	Calls /get-result
done	Calls /get-result
failed	Ends the scan with an error
cancelled	Ends the scan as canceled

POST /get-result

Purpose: Gets the scan result after the scan finishes successfully.

Request: Same as for /scan-status.

Expected response:

{
  "scan_result": {
    "id": "asoc-scan-result-id",
    "tool_internal_task_id": "external-task-id",
    "result": { "version": "2.1.0", "runs": [] }
  }
}

Requirement: scan_result.result must be a JSON object in SARIF format.

TRON.ASOC behavior: Saves the result and starts standard SARIF parsing.

POST /stop

Purpose: Stops the scan.

Request: Same as for /scan-status.

Expected response:

{
  "scan_result": {
    "id": "asoc-scan-result-id",
    "tool_internal_task_id": "external-task-id",
    "status": "cancelled"
  }
}

TRON.ASOC behavior: Stops local polling and changes the scan result state to canceled.

Error handling

The system handles errors as follows:

• Any HTTP response outside the 2xx range is considered a custom integration error.
• A 2xx response that contains an error field in the body, for example, {"error": "Something went wrong"}, is also considered an error.
• The system takes the error text from the response body without changes.

Execution result

After the complete cycle (/validate → /test-connection → /join-settings → /run → /scan-status → /get-result), the system receives the scan result in SARIF format and starts standard parsing. When a user cancels a scan, the cycle ends with a call to /stop, and the result status changes to cancelled.

warning

Keep the following points in mind:

• Field names and status values must exactly match the contract.
• The url field from the custom integration settings is used only to build the request URL and isn't passed to the integration.

Edit an integration with a security tool

To edit an integration with a security tool, follow these steps:

1. Select the edit button () in the tool row.
2. Change the required parameters in the form that opens.
3. Select Save

Delete an integration with a security tool

To delete an integration with a security tool, follow these steps:

1. Select the delete button in the tool row.
2. Confirm the tool deletion in the modal window that opens.

To delete multiple integrations with security tools, follow these steps:

1. Select the tools using the checkboxes ().
2. Select the delete button () above the tools table.
3. Confirm the tool deletion in the modal window that opens.

Examples of integrations with security tools

Add an integration with PT Application Inspector

To add an integration with the tool to the system, follow these steps:

1. Go to Integrations → Security tools.

2. Select Add security tool.

3. Select PT Application Inspector from the list of tools.

4. Fill in the fields in the form that opens:

   • Integration name—the name must be unique;
   • Description.

5. Configure the connection parameters:

   • API URL (for example, https://your.company.ptsecurity/api/v1);
   • Scan results language;
   • Authentication method.
   info

   You can specify the authentication method later when you add a security check.

6. Select Test connection.

caution

You can test the connection only if you've entered valid authentication data for the security tool. If the data is correct, the connection test succeeds. If the connection fails, verify the data and try again.

7. Select Save.

Add an integration with Kaspersky Container Security (KCS)

To add an integration with the tool to the system, follow these steps:

1. Go to Integrations → Security tools.

2. Select Add security tool.

3. Select Kaspersky Container Security from the list of tools.

4. Fill in the required fields:

   • Name;
   • Description.

5. Configure the connection parameters:

   • URL;
   • Scan results language;
   • Authentication method (API token).
   info

   You can specify the authentication method later when you add a security check.

6. Add an API token to the API token field.

7. Select Test connection.

caution

You can test the connection only if you've entered valid authentication data for the security tool. If the data is correct, the connection test succeeds. If the connection fails, verify the data and try again.

8. Select Save.