Actions with security tools

This section describes how to add, edit, and delete integrations with security tools, lists available security tools and their versions, explains how to work with SASTAV, and provides 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 scan with Solar AppScreener, you can select the analysis type (SAST, DAST, or SCA).

Working with SASTAV

Keep the following points in mind when working with SASTAV:

1. When you authenticate, use a SASTAV service account when configuring the SASTAV integration.
2. SASTAV repositories must be unique across all system projects. When you create scans with identical scan sources in different projects, SASTAV creates only one repository.
3. SASTAV scan results appear in the corresponding security scans and projects during report parsing.
4. When you edit a security scan, you can select the repository type:
   • Basic—allows up to 15,000 lines of code;
   • Advanced—allows up to 1 million lines of code. 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, use the Maximum number of repositories parameter in the SASTAV integration settings. When you specify 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 scan, TRON ASOC deletes the associated SASTAV repository if no other security scans use it.

Connect an integration with a security tool

info

To configure integrations with security tools, users 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 access type for the tool:

   • Global—the integration is available in all projects;
   • Project—the integration is available only in selected projects. After selecting 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 by using checkboxes.

   

6. Fill in the additional fields:

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

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

   Selecting an authentication method isn't required 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
   • Username/password: Username and Password fields
   • None. If you select the None authentication method, scanning isn't 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 tool restrictions. 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 for the API token and Username/password authentication methods.

You can test the connection only if you previously 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 scans in TRON.ASOC or Kubernetes and import the results of scans 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 of more than 10 minutes can cause a timeout during a test scan that uses the created integration.

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 and available for users with the appropriate permissions to view and edit;
• confidential setting—contains sensitive data that isn't displayed to users when they 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 result 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, or 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 result 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	Access token for the tool
client_secret	Client secret key
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 previously 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 data:

   • source for the test scan;
   • branch or tag of the source;
   • additional tool settings.
   info

   The data you specify in the additional settings applies only to the test scan and isn't saved in the general tool 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 format

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 credentials.
3. /join-settings—combines the custom integration settings and scan settings in join_tool_settings.
4. /run—starts 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 the user cancels the 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 credentials.

Request: tool_settings, tool_secret_settings.

Successful response:

{ "status": "ok" }

Error response:

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

TRON.ASOC behavior: When status: ok, considers the connection test successful. When status: error, shows the user the text from error_msg.

POST /join-settings

Purpose: Combines the custom integration settings and scan 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: Starts a scan with 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 /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 /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 status to cancelled.

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 full cycle (/validate → /test-connection → /join-settings → /run → /scan-status → /get-result) finishes, the system receives the scan result in SARIF format and starts standard parsing. When the user cancels the 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. In the form that opens, change the required parameters.
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.

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

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

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 result language;
   • Authentication method.
   info

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

6. Select Test connection.

caution

You can test the connection only if you previously 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 result language;
   • Authentication method (API token).
   info

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

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

7. Select Test connection.

caution

You can test the connection only if you previously 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.