Mend for Bitbucket Data Center - Configuration
The .whitesource File
A whitesource configuration file (.whitesource) is a JSON file added to each repository that is enabled for a scan. It provides configurable parameters for the scan.
The .whitesource file is only added in the default branch of the repository (unless modified, it is the master branch).
.whitesource file
{
"scanSettings": {
"configMode": "AUTO",
"configExternalURL": "",
"projectToken": "",
"baseBranches": []
},
"buildSettings": {
"displayMode": "diff",
"failBuilds": true
},
"issueSettings": {
"minSeverityLevel": "LOW"
}
}
Parameters
Global Settings
Parameter | Type | Description | Required | Default |
---|---|---|---|---|
settingsInheritedFrom | String | When the global configuration is enabled, this parameter will specify the location of the whitesource-config repository from which it will inherit its configuration. It must contain the Bitbucket project key, repository name and branch (optional) of the repo-config.json file location. NOTE: You can override specific parameters that are relevant only in the specific repository by adding these after this parameter. Examples: Using only values defined in the global configuration:
CODE
Using values defined in the global configuration and overriding the scan settings parameters:
CODE
| No | N/A |
overrideConfigAllowList | Array | When the global configuration is enabled, this parameter will regulate the ability of repositories that inherit their configuration from the whitesource-config repository to override the parameters locally. There are three options:
Note: This parameter must be used in the repo-config.json file of the whitesource-config repository. | No | null |
Scan Settings (scanSettings)
Parameter | Type | Description | Required | Default |
---|---|---|---|---|
configMode | String | The configuration mode to be used for each scan. There are three options:
Note: whitesource.config can be provided both in global config and in the repo itself. If it is provided in both places and there are parameters that are set on both levels - repo level will take precedence. | No | Auto |
configExternalURL | String | The URL of the external configuration file (you can choose any filename). The configuration file content should be in the same format as the Unified Agent configuration file. The following protocols are supported: 'ftp://', 'http://', 'https://'. For example: 'https://mydomain.com/whitesource-settings/wss-unified-agent.config' Notes:
| No | Empty |
projectToken | String | Adds the ability to map a Bitbucket repository to a Mend project. The parameter used needs to be the Mend project token. Note: Not supported in the Global Configuration. | No | Empty |
baseBranches | Array | Adds the ability to specify one or more base branches for which scanning results will be sent to a new Mend project. Example usage: ["master", “integration"] This will set both master and integration branches as base branches. Note the following:
Note: This parameter is available only from version 20.7.1. | No | Empty In this case, the base branch only consists of the default branch. |
enableLicenseViolations | Boolean | When enabled, a new Mend License Check will be generated for each valid push. Notes:
| No | false |
enableIaC | Boolean | When enabled, a new Mend IaC Check will be generated for each valid push. This will scan cloud infrastructure configurations to find misconfigurations before they are deployed, and alert on these via the creation of a Work item. Notes:
| No | false |
javaVersion | String | Defines version of Java in the Scanner. Available values: 8, 11, 17. Note: For any projects that are using Gradle versions prior to v7.3, we recommend setting your Java version used by the integration to one of the lower supported versions, 8 or 11, via the | No |
|
cloneSubmodules | Boolean | If set to Note: Only enable this parameter if all of the submodules used in the repository are either public repositories or private repositories that are onboarded to Mend. Otherwise the scan will fail. | No | false |
repoNameSync | Boolean | When set to | No | false |
skipScanningStage | Object | Controls what stages of scanning process will be skiped for specific package manager. The available parameters are:
The available parameter values are: Usage example:
CODE
| No | none |
exploitability | Boolean | When set to Additional information about exploitability is available in the designated Public Exploits page. | No | false |
uaConfigMergeSetting | String | Possible values: Note: All other UA settings are always overridden on a local level. | No | OVERRIDE |
Build Settings (buildSettings)
Parameter | Type | Description | Required | Default |
---|---|---|---|---|
displayMode | String | How to display Mend security information for a scan performed on a non-base branch:
| No | diff |
createBuildStatus | Boolean | The app can provide checks in commits and pull requests on any repository branch. This parameter defines whether Mend Security Check is going to run. If set to | No | true |
failBuilds | Boolean | The app provides checks in commits and pull requests on any repository branch. This parameter defines the conclusion status for when a Mend Security Check is completed. When the parameter is set to false, the conclusion status of a Mend Security Check will always be 'Success', even if the check fails. This way, any repository member is able to merge a pull request, even if a Mend Security Check found security vulnerabilities. When the parameter is set to true (default), the conclusion status of a Mend Security Check will be 'Failure' in cases where Mend Security Check found security vulnerabilities or an error occurred during the scan. When this configuration is defined, a policy for approving a pull request is enforced. In this setting, only the administrator of the repository can approve the merging of a pull request that contains one or more checks with a 'Failure' status. | No | true |
failLicenseBuilds | Boolean | The app provides checks in commits and pull requests on any repository branch. This parameter defines the conclusion status for when a Mend License Check is completed. When the parameter is set to false, the conclusion status of a Mend License Check will always be 'Success', even if the check fails. This way, any repository member is able to merge a pull request, even if a Mend License Check found license policy violations. When the parameter is set to true (default), the conclusion status of a Mend License Check will be 'Failure' in cases where Mend License Check found license policy violations or an error occurred during the scan. When this configuration is defined, a policy for approving a pull request is enforced. In this setting, only the administrator of the repository can approve the merging of a pull request that contains one or more checks with a 'Failure' status. | No | true |
failIacBuilds | Boolean | The app provides checks in commits and pull requests on any repository branch. This parameter defines the conclusion status for when a WhiteSource IaC Check is completed. When the parameter is set to When the parameter is set to Note: When an IaC issue is closed it will not be detected in the future scans. | No | true |
showWsInfo | Boolean | Whether to show additional Mend information such as the project token inside the Mend Build Status (after the scan token). Mend information is only displayed if the commit originated from a base branch. The following hidden JSON object will also be added inside the Build Status when this parameter is enabled:
CODE
Note: Additional Mend data may be added inside the JSON object in the future. | No | false |
useMendBuildNames | Boolean | If set to Note: When .whitesource is created the value of useMendCheckNames is | No | false |
strictMode | String | Controls the messaging and status of security and license checks in the case of partial scan results (i.e. Mend Scanner experienced issues pulling some of the project’s dependencies during the scan). The available parameter values are:
Note: For strictMode to work, the vulnerableCheckRunConclusionLevel and licenseCheckRunConclusionLevel parameters must be set to | No |
|
strictModeInfo | Boolean | Controls the inclusion of INFO logs in the Scan Details report.
| No |
|
Issue Settings (issueSettings)
NOTE: Starting with the release of version 22.12.1 (January 2nd, 2022), to take advantage of the Critical label for vulnerabilities for existing Issues created by our repo integration, a new scan must be triggered on the repository. If a scan has not been triggered after upgrading to this version, the repo will continue to only show the previous three labels (High, Medium, Low) for existing Issues. For more information on the Critical setting, please visit our documentation here.
Parameter | Type | Description | Required | Default |
---|---|---|---|---|
minSeverityLevel | String | Enables users to decide whether to open a new Issue only if a certain severity level is available on a detected vulnerability. Available values for minSeverityLevel:
Notes:
| No | LOW |
minVulnerabilityScore | string | Enables users to define issue creation based on a specified minimum vulnerability CVSS score. Allowed values - floats with one decimal from 0 to 10. For more information on CVSS 3 Scores, click here. Notes:
| No | 0 |
maxVulnerabilityScore | string | Enables users to define issue creation based on a specified maximum vulnerability CVSS score. Allowed values - floats with one decimal from 0 to 10. For more information on CVSS 3 Scores, click here. Notes:
| No | 10 |
displayLicenseViolations | Boolean | Whether to generate an Issue for every detected license policy violation. Note: This parameter is relevant only if enableLicenseViolations (scanSettings) is set to true. | No | true (only if enableLicenseViolations (scanSettings) is set to true) |
iacIssues | Boolean | Whether to generate issues for IaC findings. The available values are:
Note: This parameter is relevant only if the IaC scan is enabled by setting scanSettings.enableIaC to | No |
|
Remediate Settings (remediateSettings)
Parameter | Type | Description | Required | Default |
---|---|---|---|---|
enableRenovate | Boolean | When enabled, Remediate will raise automated Pull Requests for outdated dependencies in addition to Pull Requests remediating vulnerable dependencies. Remediate will then perform all the functionality and support all the configuration options available in Mend Renovate. See Renovate https://docs.renovatebot.com/configuration-options for all configuration options. | No | false |
workflowRules | Object | This parameter is used to specify the rules that regulate when to open remediation pull requests. Usage examples:
CODE
| Yes |
CODE
|
workflowRules.enabled | Boolean | Enables Workflow Rules being set from a .whitesource file. Note: workflow rules can also be set in the Mend application in the Admin → Integration Workflow Rules. But if this parameter is set to | Yes | true |
workflowRules.minVulnerabilitySeverity | String | The minimal vulnerability severity level to automatically create remediation pull requests for. Allowed values - E.g. if set to Note: if this parameter is used together with minVulnerabilityScore and maxVulnerabilityScore than only minVulnerabilitySeverity will have affect. | No | LOW |
workflowRules.minVulnerabilityScore | Float | The minimal vulnerability CVSS 3 score to automatically create remediation pull requests for. Allowed values - floats with one decimal from 0 to 10. For more information on CVSS 3 Scores, click here. Note: if this parameter is used together with minVulnerabilitySeverity it will not have any effect. | No | Empty |
workflowRules.maxVulnerabilityScore | Float | The maximal vulnerability CVSS 3 score to automatically create remediation pull requests for. Allowed values - floats with one decimal from 0 to 10. For more information on CVSS 3 Scores, click here. Note: if this parameter is used together with minVulnerabilitySeverity it will not have any effect. | No | Empty |
Private Registry Settings (hostRules)
Parameter | Type | Description | Required | Default |
---|---|---|---|---|
matchHost | String | Defines where the credentials will be applied during the scan. More details.
| No | Empty |
hostType | String | Type of private registry. Supported values: Required if Note: When using Renovate with a Ruby private registry, add a | No | Empty |
userName | String | Used when credentials require username. | No | Empty |
encrypted.password | String | Used when credentials require password. For more information on setting up hostRules encryption, please visit the Handling Private Registries and Authenticated Repositories section. Encrypted secret that will be applied as a credential to the host set in the
JSON
| No | Empty |
encrypted.token | String | Used when credentials require token. For more information on setting up hostRules encryption, please visit the Handling Private Registries and Authenticated Repositories section. Encrypted secret that will be applied as a credential to the host set in the
JSON
| No | Empty |
envVariablesMapping | Object | Use this parameter if you used environmental variables in the settings of your package manager to include username and password/token (e.g. for a specified package index).
CODE
or
CODE
Then, set
CODE
| No | Empty |
sourceName | String | This parameter is relevant only for Pipenv private registries. Use this parameter if you don’t have a specified a package index, in this case Mend will create one for you based on other parameters of hostRules. The value of sourceName should be a the index name used for your private packages. For example, if you have packages with such index
CODE
Then set sourceName to
CODE
| No | Empty |
Providing a Global Configuration File
NOTE: Supported from version 20.5.1.3 only.
You can provide a custom .whitesource configuration file as part of the wss-bb-app container, in order to apply it globally to all of your organization's repositories. Doing so will apply the file to all onboarding pull requests for newly-selected repos. Repos which were already selected and activated before this change will not be affected by this global configuration. Only newly onboarded repos will be affected.
To apply this global change, do as follows:
Stop the wss-bb-app container.
In the "wss-bb-app/conf" folder, add your custom “.whitesource” file (where the prop.json file is located).
Start the wss-bb-app container.
Configuration Error Issues
Alert the user on configuration errors that affect their scan, by creating a configuration error issue and build status. In case of such an error, do as follows:
Stop the workflow. Do not create a scan or the Mend Security build status.
Create a “Configuration Failed” build status.
For each config file that failed parsing, create a new type of issue, entitled Action Required: Fix Mend Configuration File - {fileName}. If the error originated from the repo-config.json or global-config.json files, then the issue will be created in the whitesource-config repo.
Handled errors:
Error parsing the configuration files (.whitesource/repo-config.json/global-config.json json)
Missing repository and/or branch in the inheritance configuration