--- title: Mapper configuration slug: mapper-configuration docTags: createdAt: 2026-05-28T13:01:35.265Z --- A mapper is a configuration mechanism used to map data fromsecurity and development tools into Kyndryl Bridge so that scan results, vulnerability data, andrelated information can be accurately processed and ingested. Mappers define how tool-specific data is interpreted, including required configuration fields, supported formats, andoptional parameters that customize integrations and vulnerability data processing. this guide contains the available mapper-supported phases, supported secure tool subcategories, and the required configuration details for each type. It also describes optional fields and additional parameters that can be used to customize integrations and vulnerability data processing. Use this information to ensure accurate tool mapping andsuccessful ingestion of scan results. Kyndryl Bridge supports mappers for the following phases: Kyndryl Bridge DevOps Intelligence supports the mappers for the following DevOps Intelligence phases: - Secure - Build - Deploy - Test These selections are made from a dropdown menu in the Tool Category field. Develop category of tools as DevOps Intelligence supports most of the leading tools in this category out of the box. Develop doesnot support mappers through the service user interface, but can accommodate them through the use of private APIs. To add a Develop wrapper, please contact your Kyndryl representative. # Secure The Secure category requires the specification of a tool subcategory that is associated with the type of activity being performed. The following tool subcategories are supported: - Dependency Check - Static Scan - Image Scan - License Scan The required procedure varies with each subcategory. Subsequents sections provide the required procedure. ## Dependency Check The user is required to populate the Technical Service Name field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their vulnerabilities response. Completing the Additional Option field contains is not required but supports two options: - **PROVIDER HREF**: This field is for the user to enter the URL of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. These fields provide additional information about the scan and can be useful for tracking and managing Dependency Check scans. In the `Dependency Check Run` body, the user can copy and paste the complete test runs response. This allows the system to process the entire set of vulnerability data at once. ## Static Scan The user is required to populate the `TECHNICAL SERVICE NAME` field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their vulnerabilities response. Completing the Additional Option field contains is not required but it supports two options: - **PROVIDER HREF**: This field is for the user to enter the URL of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. These fields provide additional information about the scan and can be useful for tracking and managing Dependency Check scans. In the `Static Scan Run` body, the user can copy and paste the complete test runs response. This allows the system to process the entire set of vulnerability data at once. ## Image Scan The user is required to populate the `IMAGE NAME` and `TECHNICAL SERVICE NAME` fields. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their vulnerabilities response. Completing the Additional option info field is not requrired, but it supports four options: - **RELEASE NAME**: This field is for the user to enter the name of the release that is being scanned. - **PROVIDER HREF**: This field is for the user to enter the href (URL) of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. - **SCANNED TIME**: This field is for the user to enter the time when the scan was performed. These fields provide additional information about the scan and can be useful for tracking and managing vulnerabilities. In the `Imagescan Run` body, the user can copy and paste the complete vulnerabilities response. This allows the system to process the entire set of vulnerability data at once. ## License Scan For the 'Tool Sub Category' is `License Scan`. The user is required to populate the `TECHNICAL SERVICE NAME` field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their vulnerabilities response. Completing the Additional option info field is not required, but it supports three options: - **PROVIDER HREF**: This field is for the user to enter URL of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. - **SCANNED TIME**: This field is for the user to enter the time when the scan was performed. :::hint{type="info"} If the status from the tool is not provided or does not match any of the known statuses, it will be mapped to "UNKNOWN" on the DI Dashboard. ::: These fields provide additional information about the scan and can be useful for tracking and managing License scans. In the `License Scan Run` body, the user can copy and paste the complete test runs response. This allows the system to process the entire set of vulnerability data at once. # Build The user is required to populate the `Technical Service Name` field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their build data. Completing the `Additional option info` is not required but it supports two options: - **PROVIDER HREF**: This field is for the user to enter the href (URL) of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. These fields provide additional information about the scan and can be useful for tracking and managing build runs. In the `Build Run` body, the user can copy and paste the complete build runs response. This allows the system to process the entire set of vulnerability data at once. # Deploy The user is required to populate the `Technical Service Name` field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their deployment data. Completing the `Additional option info`, but it supports seven options: - **PROVIDER**: This field is for the user to enter the name of the provider, which can be a comma-separated list if there are multiple providers. - **PROVIDER HREF**: This field is for the user to enter the href (URL) of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. - **ISPRODUCTION**: This field is for the user to specify whether the environment is a production environment (`true`) or not (`false`). - **ENVIRONMENT NAME**: This field is for the user to enter the name of the environment, which can be a comma-separated list if there are multiple environments. - **RELEASE NAME**: This field is for the user to enter the name of the release. - **INCIDENT HOST URL**: This field is for the user to enter the URL of the host where the incident occurred. These fields provide additional information about the Deployment and can be useful for tracking and managing Deployment data. In the `Deployment Run` body, the user can copy and paste the complete deployment runs response. This allows the system to process the entire set of vulnerability data at once. # Test The user is required to populate the `Techincal Service Name` field. Additionally, the user must select the appropriate time field format from the dropdown menu, which aligns with the format supported by their deployment data. Completing the `Additional option info` is not required but it supports two options: - **PROVIDER HREF**: This field is for the user to enter the href (URL) of the provider. - **TECHNICAL SERVICE OVERRIDE**: This field allows the user to override the technical service name if it is already present, when set to `true`. If the user wants to use a different name for the technical service, they can enter it here. If set to `false`, it won't allow to post duplicates that have the same technical service names. These fields provide additional information about the scan and can be useful for tracking and managing test cases. In the `Test Run` body, the user can copy and paste the complete test runs response. This allows the system to process the entire set of vulnerability data at once. # Develop No UIsupport is available for Devlop mappers. Users can directly select the `Tool Sub Category` and map the endpoint response body values to the keys provided in the `Develop Run` body. This means that the user must manually ensure that the values in the endpoint response match the keys described in the `Develop Run` body. The tool subcategory dropdown presents three selections: - Issues - Pull Request - Commit ## Issues The following keys are supported: - **assignees**: An array of usernames who are assigned to the issue. - **category**: The category of the issue (e.g., "bug", "issue", etc.). - **created\_at**: The date and time when the issue was created. - **created\_by**: The username of the person who created the issue. - **description**: A brief description of the issue. - **endpoint\_hostname**: The hostname of the endpoint where the issue is located. - **fixed\_releases**: An array of release versions where the issue has been fixed. - **found\_releases**: An array of release versions where the issue was found. - **issue\_engine**: The engine used to track the issue. - **issue\_type**: The type of the issue (e.g., "Story", "Task", etc.). - **labels**: An array of labels associated with the issue. - **priority**: The priority of the issue (e.g., "High", "Medium", "Low"). - **provider\_engine**: The engine of the provider. - **provider\_href**: The href (URL) of the provider. - **provider\_id**: The ID of the provider. - **provider\_url\_key**: The URL key of the provider. - **scmhost\_url**: The URL of the source code management host. - **severity**: The severity of the issue. - **state**: The current state of the issue (e.g., "open", "closed"). - **technical\_service**: The name of the technical service. - **technical\_service\_override**: A boolean value indicating whether the technical service name can be overridden. - **technical\_service\_tag**: An object containing additional properties related to the technical service. - **title**: The title of the issue. - **updated\_at**: The date and time when the issue was last updated. :::hint{type="info"} Ensure that the values in issues response match the keys described above. Each key-value pair in response should correspond to a field in the issue. If a key in your response does not match any of the keys listed above, map it to an appropriate key. For example, if your response has a key named `issue_creator`, you should map it to the `created_by` key in the list above. This means that the value of `issue_creator` in your response becomes the value for created\_by in the final data that you post here. ::: ## Pull Request The following keys are supported: - **created\_at**: The date and time when the pull request was created. - **created\_by**: The username of the person who created the pull request. - **description**: A brief description of the pull request. - **endpoint\_hostname**: The hostname of the endpoint where the pull request is located. - **endpoint\_technical\_service\_id**: The ID of the technical service at the endpoint. - **ischerrypick**: A boolean value indicating whether the pull request is a cherry-pick. - **merge\_commit\_sha**: The SHA of the merge commit for the pull request. - **merged\_at**: The date and time when the pull request was merged. - **pr\_engine**: The engine used to track the pull request. - **provider\_href**: The href (URL) of the provider. - **provider\_id**: The ID of the provider. - **pull\_number**: The number of the pull request. - **release\_name**: The name of the release that the pull request is associated with. - **state**: The current state of the pull request (e.g., "open", "closed"). - **technical\_service**: The name of the technical service. - **technical\_service\_override**: A boolean value indicating whether the technical service name can be overridden. - **technical\_service\_tag**: An object containing additional properties related to the technical service. - **title**: The title of the pull request. - **updated\_at**: The date and time when the pull request was last updated. :::hint{type="info"} Ensure that the values in the pull request response match the keys described above. Each key-value pair in the response should correspond to a field in the pull request. If a key in your response does not match any of the keys listed above, map it to an appropriate key. For example, if your response has a key named `pr_creator`, you should map it to the `created_by` key in the list above. This means that the value of `pr_creator` in your response becomes the value for `created_by` in the final data that you post here. ::: # Commit The following keys are supported: - **comments**: The comments associated with the commit. - **commit\_url**: The URL of the commit. - **created\_at**: The date and time when the commit was created. - **created\_by**: The username of the person who created the commit. - **endpoint\_hostname**: The hostname of the endpoint where the commit is located. - **endpoint\_technical\_service\_id**: The ID of the technical service at the endpoint. - **parent\_ids**: An array of IDs for the parent commits. - **provider\_engine**: The engine used to track the commit. - **provider\_href**: The href (URL) of the provider. - **provider\_id**: The ID of the provider. - **release\_names**: An array of names of the releases that the commit is associated with. - **scm\_engine**: The engine used for source code management. - **sha**: The SHA of the commit. - **technical\_service**: The name of the technical service. - **technical\_service\_override**: A boolean value indicating whether the technical service name can be overridden. - **technical\_service\_tag**: An object containing additional properties related to the technical service. :::hint{type="info"} Ensure that the values in the commit response match the keys described above. Each key-value pair in the response should correspond to a field in the commit. If a key in your response does not match any of the keys listed above, map it to an appropriate key. For example, if your response has a key named `commit_creator`, you should map it to the `created_by` key in the list above. This means that the value of `commit_creator` in your response becomes the value for `created_by` in the final data that you post here. :::