How does Kondukto calculate WOE and MTF?

Kondukto assigns a First Seen Date to all vulnerabilities. For vulnerabilities directly fetched from scanners, that date is set as the date on which the scanner identified the vulnerability. The First Seen date is set for imported vulnerabilities as the Date Imported information on the file.

When vulnerabilities are no longer identified in a new scan, Kondukto assigns the latest scan date when the vulnerability was not identified as the date the vulnerability was closed.

To calculate WOE, Kondukto calculates the number of days between today and the First Seen date of the vulnerabilities whose status is either new or recurrent.

To calculate MTF, Kondukto calculates the number of days between the Closed On Date and First Seen Date of the vulnerability and adds 1 to the result.

How does Kondukto calculate the risk score of projects?

The risk score is calculated by assigning scores to each severity category and multiplying each score by the number of vulnerabilities in each severity category.

Kondukto assigns the following scores to each severity category by default which can be changed in the config file by the user;


If a project has 5 high and 3 medium severity vulnerabilities, the risk score is calculated as follows;

(9 5) + (4 3) =57

On the dashboard, in each scanner type (SAST, DAST, IAST, SCA, etc.) tab, only the number of vulnerabilities identified by the scanners in the selected type are considered to calculate the risk score.

Can a developer contribute to the Remediation DB?

Yes. Comments entered after closing the issue on the issue manager are automatically added to the Remediation DB by Kondukto.

When developers start typing comments in the issue manager with "kondukto:" Kondukto automatically captures the comment as remediation advice from the developer and adds it to the Remediation DB.

Admin-level users can edit or delete the remediation advice entered by the developers.

How does global security criteria feature work?


This functionality is only available for Admin users.

It is possible to create security criteria at a global or project level.

Only one security criteria entered at a global level can be set as default so that it is applied to all projects automatically.

Default global security criterion does not override the project level criteria but works alongside them.

So, suppose there is a default security criterion entered at a global level and a different one at a project level. In that case, Kondukto checks for both before deciding if the project meets or fails security criteria.

Other global security criteria not set as default can be imported under the Security Criteria section in each project's settings.

Once security criteria are entered within global settings, they will take effect either within 10 minutes or after one of the following events;

When a vulnerability is updated (by manually changing severity or by marking it as a false positive or won't fix)
When a new scan is run, or a new file is imported

Labels can be associated with global security criteria. If the same label related to a global security criterion is added to a project, the global security criterion associated with that label is automatically assigned to the project.

Global security criteria imported to projects can be edited under project settings. However, changes made will only be applied to the specific project, and global criteria will remain unchanged.

What is the impact of marking a vulnerability as false positive on Kondukto?

Marking a vulnerability as a false positive has the following impacts on Kondukto;

  • Even if the same scanner reports the same vulnerability in the future, vulnerability keeps showing as a false positive on Kondukto.
  • If an issue has been previously opened on the issue manager, Kondukto automatically closes the issue and does not trigger a validation scan.
  • The vulnerability is instantly excluded from all charts and metrics.
  • The vulnerability is excluded from the calculation of overdue vulnerabilities exceeding SLA.

Who can mark a vulnerability as a false positive on Kondukto?

Admin and team lead level users can directly mark a vulnerability as a false positive by entering a description of why they think the vulnerability is a false positive.

Developer-level users can only send requests to mark a vulnerability as a false positive along with a description that needs to be approved by the team lead in the project or admin.

How does Kondukto map vulnerabilities to endpoints?

There are two ways to map vulnerabilities to endpoints on Kondukto; manual and automated.

For manual mapping, an endpoint should be entered into the project to which the vulnerability belongs.

A user can manually assign an endpoint to any vulnerability in the vulnerability details section of a vulnerability.

When users enter endpoints in the project settings, Kondukto can automatically map SAST, DAST, and SCA findings to the specified endpoints.

Kondukto compares the file/path of SAST and SCA vulnerabilities with the source dir provided for each endpoint which can be provided in a regex or wildcard format in the project settings.

If there is a match, Kondukto automatically maps the vulnerabilities to the endpoint with the matching source directory.

For DAST vulnerabilities, Kondukto compares the target field of the vulnerability with the endpoint list.

If the target contains any of the specified endpoints, the vulnerability is automatically mapped to that endpoint by Kondukto.

If the same endpoint is entered in more than one project, vulnerabilities are not automatically mapped to the same endpoint in other projects.

The overall mapped view across endpoints in different projects can be reached from the endpoints section in the side navigation menu.

The "/" in the top row indicates the root folder and displays the total number of vulnerabilities regardless of the endpoint mapping.

What do the colored circles in the first column indicate in vulnerability tables?

The colored circles indicate whether an issue has been opened on the issue manager for the corresponding vulnerability and, if so, what the issue's status is.

Grey indicates that an issue has not been created yet for the vulnerability.

Blue indicates that an issue has been opened, and its status is still open on the issue manager.

Red indicates that an issue has been opened, and it has been closed on the issue manager.

Even though the issue is closed on the issue manager, for the status of vulnerability to be closed on Kondukto, it needs to be verified by the scanner first.

Kondukto switches the status of a vulnerability to closed when the vulnerability no longer exists in the scan results.

How does Kondukto decide that the status of a vulnerability should be closed?

For Vulnerabilities Discovered by Automated Tools

Kondukto relies only on the scan results to switch the status of a vulnerability to closed.

Even if an issue has been assigned to the issue manager via Kondukto, Kondukto does not close the vulnerability when the issue status of the vulnerability is closed by the issue manager.

Instead, when the issue is closed on the issue manager, if validation scans are enabled, Kondukto can run an automated validation scan to ensure the scanner does not find the same vulnerability.

If validation scans are not enabled, Kondukto waits for the next scan date to decide if the vulnerability's status is closed.

The following need to be the same for Kondukto to classify vulnerabilities as recurrent or closed in the subsequent scans.

  • Project name
  • Tool name
  • Branch name
  • Metadata

For Manually Imported Vulnerabilities

If Issue Sync is enabled in the config file when an issue mapped with a vulnerability is closed on the issue tracker, the vulnerability status will be automatically transitioned to Closed on Kondukto as well.

Kondukto also allows to the transition of the status of manually imported vulnerabilities to Closed manually. If Issue Sync is not enabled in the config file, this is the only way to transition the status of these vulnerabilities to Closed.

Just like in automated scans, Kondukto also compares imported vulnerabilities with previously imported vulnerabilities to decide on the status of a vulnerability.

All of the following need to be the same for Kondukto to classify vulnerabilities as recurrent or closed in the subsequent imports.

  • Project name
  • Tool name
  • Branch name
  • Metadata

Therefore, different metadata can be used to import new vulnerabilities to Kondukto without changing the status of the vulnerabilities previously imported to a project.

What happens when I delete a project?

Deleting the project results in deleting all vulnerabilities discovered in that project. The project is also immediately removed from all charts and metrics in the dashboard. You can fetch the same project from the ALM tool in the future without having the "Added Before" error.

What happens if I set the time of a scheduled scan to a past time?

It results in triggering a scan immediately. Once the first scan is completed, it will initiate the following scan according to the scheduler.

If I import the same vulnerability twice, will its status be transitioned to recurrent on Kondukto?

Yes, Kondukto can set the status of vulnerabilities imported more than once to recurrent.

The following parameters must be the same for each vulnerability imported to Kondukto for the vulnerability to be treated as the same by Kondukto;

File nameTargetFile name
CodeHTTP RequestPackages
Line number

Why am I having problems in opening issues for vulnerabilities?

If you are having an error message when trying to open issues for your vulnerabilities, make sure to;

Integrate with your issue manager using a token with the correct scopes indicated in the how to get a token section.

Under project settings, select an issue path that does not belong to a forked project.

Which user will be assigned an issue when multiple options are selected?

Specific users can be assigned as issue responsible within the teams. When a team is assigned to a project, the issues are automatically assigned to this issue responsible based on the issue assignment criteria entered on the platform.

Suppose the committer when the committer is known box is checked under the Issue Assignment section in Project Settings. In that case, this will supersede all other users for vulnerabilities with a known committer.

If a specific user is also selected under the Issue Assignment section in Project Settings, this particular user supersedes the issue responsible for the team.

So the hierarchy is as follows for cases when all three are selected;

  1. Committer of the vulnerability
  2. Specific user-selected under Project Settings
  3. Issue responsible selected in the team

For cases when none of the above is applicable, Kondukto will assign the issue to the token owner generated on the issue manager.

What happens when an issue is assigned to a Kondukto user who is not active on the issue manager?

For Kondukto to match users on Kondukto and the issue manager, the same email address must be used on both platforms.

When you create an issue on your issue manager that will be assigned to a Kondukto user that does not exist on your issue manager, Kondukto automatically assigns the issue to the owner of the token used in the issue manager integration.

Do validation scans work for issues manually created through Kondukto?

Yes, validation scans work for vulnerabilities that have been automatically assigned an issue by Kondukto or for those that have been manually sent to issue managers through Kondukto.
The only requirement is that the vulnerability should be discovered by an automated tool still active on Kondukto.

What is the relationship between CVSS and severity categories on Kondukto?

When the CVSS score of a vulnerability is manually changed, the severity category is automatically updated as follows;

0.0 - 4.0: Low
4.0 - 7.0 : Medium
7.0 - 9.0: High
9.0 - 10.0: Critical

When the severity of a vulnerability is manually changed, CVSS scores are automatically updated as follows;

Low: 3.0
Medium : 6.0
High: 8.0
Critical: 10.0

Kondukto triggers the validation scan but can not reopen the issue on Jira, although it still appears in the validation scan results. What could be the reason?

The most likely reasons for this scenario are;

  1. The states chosen for opening and closing issues on Jira are not linked to each other on the Jira workflow. In this case, as Kondukto can not transition the state of the issue from one to another, it will remain closed on Jira.

  1. Inaccurate selection of states to use when opening and closing issues on Jira. Unless the right states are selected on Kondukto, Kondukto will not be able to transition the state of the issues correctly.

How do PR checks work?

You can use Kondukto in your PRs to prevent vulnerabilities from being carried forward to the target branch.

It is possible to achieve this functionality using the following command in KDT.

kdt scan -t (tool name) -p (project name) -b (branch name) -M (target branch name)

For example, let's assume we are merging a "feature" branch with the "develop" branch.

In this case, when a scan is run on the "feature" branch before merging the branch to the "develop" branch Kondukto will take the following actions;

  1. As a first step, Kondukto will check if the same scanner discovers any vulnerabilities in the target branch (develop).
  2. Next, it will ignore vulnerabilities marked as false positive or won't fix in the develop branch in the results of the ran scan on the feature branch.
  3. It will also correlate the previous findings (discovered by the same scanner in the same project and branch) with new findings to classify the previously discovered as recurrent.
  4. For vulnerabilities previously assigned an issue on the develop branch, the related issue status will also be available for the findings discovered on the feature branch.

Once the vulnerabilities are fixed in the feature branch, if a retest is needed, then the user has two options;

  • To compare the latest findings of the feature branch against the previous findings in the same feature branch, the user does not need to take any action as this is the default behavior of Kondukto.
  • To compare the latest findings of the feature branch against the latest findings in the develop branch, the previous scan configuration needs to be deleted, as seen in the screenshot below, before running a new PR check. This way, Kondukto will pull the latest vulnerabilities in the develop branch again.

For PR checks, security criteria will also be effective for target branches.

For example, suppose we do not want critical severity vulnerabilities carried forward to our development branch from the feature branch. In that case, we can specify the branch under Security Criteria as "develop," as seen in the screenshot below.

This way, Kondukto will search for critical severity vulnerabilities on the scans run on the develop branch and the feature branch that will be merged to the develop branch.

"FP" action via Jira

This feature of Kondukto allows open issues to be closed as "FP" by admin users, and "FP" request developer users via Jira. With these commands, users can manage the actions taken for the open issues through a single platform.

When admin users write the necessary comments on the tickets on Jira, the current issue is marked as "FP" on the Kondukto.

When developer users send "FP" requests via Jira, admin users can see it and take action.

When a developer user makes the "FP" request to an issue by Kondukto, it's waiting for approval from the admins. However, the "FP" request made by an admin user via Jira to the current issue is directly approved.

The syntax that you should use on the Jira side is:

For False Positives

  • kondukto-fp: {description of the fp}



  • Please note that the developer users are not authorized to mark an issue as "FP".

  • For this feature, admin and team lead users have the same permission.



  • Users must be registered with the same email address on both platforms.

  • User profile visibility must be "Anyone" for the Contact - Email Address information.

Data Retention

What is data retention?
As an ASOC platform, Kondukto collects lots of data from various sources. Data retention is periodically checking and removing old data from the database. The reason is that old data is bloating the database, creating performance degradation in the overall application usage. For these reasons, data retention is a necessity.

Kondukto Data Retention Policy
Data retention periods on Kondukto are as follows:

  • Completed scans (30 days)
  • Failed scans (7 days)
  • Audit log (365 days)
  • Disabled/Deleted Projects (7 days)
  • Disabled/Deleted Teams (7 days)
  • Disabled/Deleted Users (7 days)
  • Disabled/Deleted Vulnerabilities (7 days)
  • Disabled/Deleted Settings (7 days)
  • Disabled/Deleted Scanparams (7 days)
  • Disabled/Deleted Scans (7 days)
  • Disabled/Deleted Products (7 days)
  • Disabled/Deleted Labels (7 days)
  • Disabled/Deleted Tokens (7 days)
  • Disabled/Deleted Report Profiles (1 day)