Cloud Services

DevOps Intelligence

Mapper configuration
Published On Dec 12, 2024 - 1:59 PM

Mapper configuration

Understand mapper files, why they are necessary and how to create them.
This topic is only to be used in the context of creating mapper files, which is described in Tools Configuration.
Kyndryl DevOps Intelligence supports the mappers for the following DevOps 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.
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.
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.
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.
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.
Do you have two minutes for a quick survey?
Take Survey