Skip to main content
Skip table of contents

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
JS
{
  "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.
"settingsInheritedFrom": "<Project Key>/<Repository Name>@<Branch>"
The default branch is 'master', but can be modified according to the location of the repo-config.json file in the whitesource-config repo. 

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
"settingsInheritedFrom": "WHIT/whitesource-config@master"

Using values defined in the global configuration and overriding the scan settings parameters:

CODE
"settingsInheritedFrom": "WHIT/whitesource-config@master",
"scanSettings": {
  "projectToken": "12345",
  "baseBranches": ["master","integration"]
}

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:

  • null ("overrideConfigAllowList": null) - All repositories that inherit configuration from this .whitesource file can override them locally.

  • Empty array ("overrideConfigAllowList": []) - All repositories that inherit configuration from this .whitesource file cannot override them locally.

  • Array with values ("overrideConfigAllowList": ["orgName1/repoName1", "orgName2/repoName2"]) - Only specified in the array repositories that inherit configuration from this .whitesource file can override them locally.

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:

  • AUTO - Automatic mode. This will use the default Mend configuration. 

  • LOCAL - Local mode. This will look for a local 'whitesource.config' file to be provided in the root folder of the current repository. The configuration file should be in the same format as the Unified Agent configuration file.  

  • EXTERNAL - External mode. This will look for a configuration file specified according to the configExternalURL parameter. 

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: 

  • This parameter is relevant only if configMode was set to EXTERNAL.

  • This value can be set on global and local level, the inheritance rules are as with the config file above.

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:

  • An Issue will only be created for the specified branch names.

  • For each specified branch, a Mend project will be created. The name of the project will contain a suffix "_branchname". For example, MyApp_dev. This suffix will not apply to the default branch.

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:

  • This parameter is available only from version 20.11.2.

  • You must have it least one policy of match type By License Group defined with a Reject action in the Mend UI.

  • The policy name in the Mend UI must start with a "[License] " prefix.
    For example, "[License] PolicyName".

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:

  • When enabled, after every valid push, a branch (ws-iac-scan-results/{mend_scan_token}) is temporarily created and deleted after the scan has completed.

  • When an IaC work item is closed it will not be detected in the future scans.

  • IaC issues are meant to be opened for the default branch only and if they are opened for additional baseBranches then the branch name will not be shown.

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 javaVersion parameter.

No

  • For integration versions v23.8.2 and newer: 17

  • For integration versions older than v23.8.2: 11

cloneSubmodules

Boolean

If set to true git submodules that are used in the repository will be scanned as part of the repository where this parameter is enabled. If set to false all submodules that might be used in the repository will be ignored.

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 true and a Bitucket repository name was changed before the scan, projects for each base branch will be renamed in the Mend UI.

No

false

skipScanningStage

Object

Controls what stages of scanning process will be skiped for specific package manager.

The available parameters are:

  • connectivity - Verifying authentication using the host rules info - private registry URL and credentials.

  • config - Set environment variables and prepare global/local configuration files for the scan.

  • preStep - Run package manager commands in order to have the dependencies and lock files ready for the scan.

The available parameter values are: maven, npm, nuget-csproj, nuget-packages, pip, yarn.

Usage example:

CODE
{
  "scanSettings": {
    "skipScanningStage": {
      "connectivity": ["maven", "npm"],
      "config": ["yarn"],
      "preStep": ["maven"]
    }
  }
}

No

none

exploitability

Boolean

When set to true, if a vulnerability has data about exploitability it will be displayed under issues and security checks.

Additional information about exploitability is available in the designated Public Exploits page.

No

false

uaConfigMergeSetting

String

Possible values: APPEND, OVERRIDE.
Controls whether the following global and local config settings are overridden or appended: includes, excludes, archiveIncludes, and archiveExcludes.

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:

  • When set to diff - Only the diff of detected vulnerabilities between the current commit and its base branch commit will be displayed. NOTE: This value is only supported when using the baseBranches configuration.

  • When set to baseline - A summary of all detected vulnerabilities in the full repository inventory will be displayed.

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 false it will not be initiated. A scan will still occur and the project will be updated in the Mend User Interface.

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 false, the conclusion status of a WhiteSource IaC 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 WhiteSource IaC Check found IaC violations.

When the parameter is set to true (default), the conclusion status of a WhiteSource IaC Check will be 'Failure' in cases where WhiteSource IaC Check found IaC 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.

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.
If the commit exists in multiple branches, the Mend information displayed will only represent the origin base branch (i.e. where the baseBranches parameter was defined).

The following hidden JSON object will also be added inside the Build Status when this parameter is enabled:

CODE
<!-- <INFO>{"projectToken":"8cd2d2a8651145c087609e0a43f783e95f7008cb908541498348fed529572e01"}</INFO> -->

Note: Additional Mend data may be added inside the JSON object in the future.

No

false

useMendBuildNames

Boolean

If set to true names of all Checks (Security, License, IaC) will be named after Mend (e.g. “Mend Security Check”). If set to false all Checks will have word “WhiteSource” instead of “Mend”.

Note: When .whitesource is created the value of useMendCheckNames is true.

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:

  • none - When a scan concludes with partial results:

    • No message is shown in the check description.

    • The check status is not affected.

  • warning - When a scan concludes with partial results:

    • A message alerting to the partial results is included in the check description. When possible, the message will also include detailed information and error logs on the cause of the partial results.

    • Partial result details include warning and error messages in the check run.

    • Check run does not fail based on warning or error messages.

    • A project tag "scanError" is not populated with package managers' names.

      • If there was a tag previously → it is removed with the next scan job

  • failure - When a scan concludes with partial results:

    • A message alerting to the partial results is included in the check description. When possible, the message will also include detailed information and error logs on the cause of the partial results.

    • Partial result details include warning and error messages in the check run.

    • Check run fails only on error messages, not on warnings.

    • A project tag "scanError" includes only error-level package managers.

  • failOnWarning - When a scan concludes with partial results:

    • Partial result details include warning and error messages in the check run.

    • Check run fails on both warning and error messages.

    • A project tag "scanError" lists package managers with warnings or errors.

Note: For strictMode to work, the vulnerableCheckRunConclusionLevel and licenseCheckRunConclusionLevel parameters must be set to failure or not used.

No

none

strictModeInfo

Boolean

Controls the inclusion of INFO logs in the Scan Details report.

  • When set to true, this allows info-level messages in all strict modes except none.

No

false

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:

  • NONE - No Issues will be generated.

  • LOW - Any Low/Medium/High vulnerabilities found will generate an Issue.

  • MEDIUM - Any Medium/High vulnerabilities found will generate an Issue.

  • HIGH - Any High vulnerabilities found will generate an Issue.

  • CRITICAL - Any Critical vulnerabilities found will generate a GitHub Issue.

Notes:

  • This parameter specifies the scope of vulnerabilities for both Issues and Security Checks.

  • If this parameter is used together with minVulnerabilityScore or maxVulnerabilityScore then it will be ignored.

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:

  • This parameter specifies scope of vulnerabilities both for Issues and Security Checks.

  • If this parameter is used together with minSeverityLevel then the latter will be ignored.

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:

  • This parameter specifies scope of vulnerabilities both for Issues and Security Checks.

  • If this parameter is used together with minSeverityLevel then the latter will be ignored.

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:

  • true - If the IaC scan is enabled and IaC misconfigurations are detected, issues are created for these findings.

  • false - If the IaC scan is enabled and IaC misconfigurations are detected, no issues are created for these findings.

Note: This parameter is relevant only if the IaC scan is enabled by setting scanSettings.enableIaC to true.

No

  • When iacIssues is not included at all in the configuration (.whitesource/repo-config.json files), the default ofiacIssues is true.

  • From v22.8.1, if you onboard a repository with new auto-generated .whitesource/repo-config.json files, iacIssues will be explicitly included and set to false by default.

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
   "remediateSettings": {
    "workflowRules": {
      "enabled": true,
      "minVulnerabilitySeverity": "LOW"
    }
  }
   "remediateSettings": {
    "workflowRules": {
      "enabled": true,
        "minVulnerabilityScore": 1.5,
        "maxVulnerabilityScore": 10
    }
  }

Yes

CODE
    "workflowRules": {       
      "enabled": true    
    }

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 true then Workflow Rules from the application are not being used.

Yes

true

workflowRules.minVulnerabilitySeverity

String

The minimal vulnerability severity level to automatically create remediation pull requests for. Allowed values - "LOW", "MEDIUM", "HIGH", and “CRITICAL".

E.g. if set to "MEDIUM" then remediation pull requests of vulnerabilities with low severity will not be created - only for those with medium and high severity.

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.

  • If you want to apply credentials only for a nested path within a host, then write matchHost as a base URL.
    For example: https://registry.company.com/nested/path/.

    • Requiered for Gradle

  • If the same credentials apply to all paths on a host and not on any subdomains, configure matchHost with a protocol like https://registry.company.com.

  • To apply credentials to all hosts within the domain, use a matchHost value with no https:// prefix, e.g. company.com or registry.company.com, both of which would apply to a host like beta.registry.company.com.

No

Empty

hostType

String

Type of private registry. Supported values: npm (for both NPM and Yarn projects), maven (for both Maven and Gradle projects), pypi (for Pip and Pipenv), go , nuget, ruby, sbt.

Required if matchHost is used.

Note: When using Renovate with a Ruby private registry, add a hostRules block with hostType=rubygems within the remediateSettings block.

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 matchHost parameter. Must be included inside the encrypted parameter:

JSON
      "encrypted": {
        "password": "3f832f2983yf89hsd98ahadsjfasdfjaslf............"
      }

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 matchHost parameter. Must be included inside the encrypted parameter:

JSON
      "encrypted": {
        "token": "3f832f2983yf89hsd98ahadsjfasdfjaslf............"
      }

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). envVariablesMapping takes a value as an object with two literals: userName and password / token.
For example, if you have:

CODE
[[source]]
url = "https://${USER_PRIVATE_REPO}:{PASS_PRIVATE_REPO}:@pypi/PACKAGE_NAME/simple"
verify_ssl = true
name = "IndexName"

or

CODE
  {
    url 'https://private.jfrog.io/artifactory/dependencies'
    credentials {
      username System.getenv("USER_PRIVATE_REPO") ?: "${USER_PRIVATE_REPO}"
      password System.getenv("PASS_PRIVATE_REPO") ?: "${PASS_PRIVATE_REPO}"
    }
}

Then, set envVariablesMapping to:

CODE
"envVariablesMapping": {"userName": "USER_PRIVATE_REPO" ,"password":"PASS_PRIVATE_REPO"}

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
[packages]
<package_name> = { version = "*", index = "IndexName" }

Then set sourceName to

CODE
"sourceName": "IndexName"

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:

  1. Stop the wss-bb-app container.

  2. In the "wss-bb-app/conf" folder, add your custom “.whitesource” file (where the prop.json file is located).

  3. 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:

  1. Stop the workflow. Do not create a scan or the Mend Security build status.

  2. Create a “Configuration Failed” build status.

  3. 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

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.