Global Settings

In the global settings, changes can be made to various Kondukto configurations. The working principles of Kondukto are affected by these configurations and, therefore, should be adjusted with care.


Before any modifications are made to these settings, ensuring an understanding of their implications is required. Should any uncertainty arise, it is recommended that the support team be contacted.

If not handled correctly, the stability of your Kondukto product may be affected by these configurations.


From the Concurrency section number of concurrent imports & scans can be adjusted.

Manually Added Vulnerabilities

By default, vulnerabilities that have been manually added can only be closed through the Kondukto UI, necessitating user action. If the preference is to alter this behavior, ensuring that the closure of the connection issue on the issue manager also closes the vulnerability, this configuration can be enabled.

Vulnerabilities can be closed manually on Kondukto(default).

Once vulnerabilities are closed on the issue manager, they will be closed as well on Kondukto.

CVSS Mapping

From this section, the assignment of CVSS scores to each severity category can be defined. The default CVSS scores are as follows, as set by Kondukto.


The results that come from SAST, SCA, and CS scanner categories can be deduplicated by Kondukto.

The priority list of scanners to be used when deciding on the master vulnerability, should the same vulnerability be discovered by multiple scanners, must be defined.

Git Matcher

The developers who committed the vulnerabilities to the source code are identified by the Git Matcher. This functionality is only available for SAST and IaC scanners.

Two options for Committer are available:

Code Owner: Is the person who wrote the vulnerable line of code.

Last Push Owner: Is the person who pushed a commit to the file where the vulnerability is located.

Feature Branch Mgmt.

Using this capability, vulnerabilities discovered in scans in which environment is set to Feature can automatically be deleted by Kondukto after the retention period (in days). This global setting allows to set this up for the entire organization. The rule introduced here on a global level can be overriden under project settings on a project level.

Source branch can also be set on a global level, if there is a specific branch used consistently in the entire organization, against which vulnerabilities discovered in features branches can be compared.

As an example, if source branch is set to "develop" ona global level, all vulnerabilities discovered in feature environments will be compared against vulnerabilities discovered in the develop branch of the scanned project and all actions taken on vulnerabilities (i.e. issue assignment, screenshots, false positive or risk accepted markings) in develop branch will be reflected on the vulnerabilities in feature branches to prevent double triage or remediation efforts.


Using the auto labels capability, Kondukto can automatically assign certain labels to projects by looking at the SBOM stored in projects where Golang or npm is used.

These automatically assigned labels are distinguished by an "Auto_" prefix in the labels. Upon hovering on the labels, related keywords can also be seen to have more context about the labels.

The list of available auto labels are as follows along with some related keyword examples. The combination of keywords might differ depending on the exact package detected by Kondukto to assign the relevant label. This list is not an exhaustive list as it is constantly updated with new labels and keywords.

  • Auto_RPC systems: rpc, networking, service communication
  • Auto_Web frameworks:http, api, web framework
  • Auto_Database: mime types, sqlite, postgresql, mysql, orm, nosql database, mongodb, offline-first, monitoring, metrics, time-series, search engine, vector search, distributed sql database, OLAP database, vector database, multi-modal database,
  • Auto_CacheKVStore: cache, in-memory, key-value store, content addressable, file system
  • Auto_Message Bus: message queue, event bus, microservices
  • Auto_File Storage: version control, file storage, distributed storage
  • Auto_Serverless: serverless, cloud functions
  • Auto_Database ORM: ORM, database, mongodb
  • Auto_AWS: cloud, sdk, infrastructure as code,
  • Auto_GCP: Google Cloud, HTTP client, metadata management, serverless, functions, compute
  • Auto_Azure: Microsoft Azure, key management, file storage, datalake, blob storage, long-running operations