Mend for GitHub.com offers several parameters to configure your SCA scans, checks, and issues.
Configuration at the local repository level is done via the .whitesource file. To set up your configuration file for SCA scans, see the Parameters section provided in this documentation. Below is an example of fine-tuning an SCA scan within a repository’s .whitesource file:
CODE
{
"scanSettings": {
"configMode": "AUTO",
"enableLicenseViolations": true,
"baseBranches": []
},
"checkRunSettings": {
"vulnerableCheckRunConclusionLevel": "failure",
"displayMode": "diff",
"useMendCheckNames": true
},
"issueSettings": {
"minSeverityLevel": "LOW",
"issueType": "DEPENDENCY"
},
"remediateSettings": {
"workflowRules": {
"enabled": true
}
}
}
Parameter | Type | Description |
---|
configMode | String | Optional. Default Value: AUTO . 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. The configuration file should be in the same format as the Unified Agent configuration file.
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.
|
baseBranches | Array | Optional. Default Value: Your GitHub.com "default" branch . Adds the ability to specify one or more base branches for which scanning results will be sent to a new Mend project. Example usage:
CODE
"baseBranches": ["master", “integration"]
This will set both master and integration branches as base branches.
Note: An Issue will only be created for the specified branch names. For each specified branch, a Mend project will be created in the Mend SCA application. The name of the project will contain a suffix "_branchname". For example, MyApp_dev. This suffix will not apply to the default branch.
|
cloneSubmodules | Boolean | Optional. Default Value: false . 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. |
configExternalURL | String | Required only if configMode is set to EXTERNAL . Default Value: N/A. 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: If you need to whitelist the IP address of the Mend server triggering the external configuration file, contact Mend support. This value can be set on global and local level, the inheritance rules are as with the config file above.
|
enableLicenseViolations | Boolean | Optional. Default Value: false . When set to true , a new Mend License Check will be generated for each valid push. You must have at least one policy of match type By License Group defined with a Reject action in the Mend SCA UI.
Notes: The license check is dependent on the vulnerabilities check and will not be triggered if vulnerableCheckRunConclusionLevel is set to none . The policy name in the Mend SCA UI must start with a "[License]" prefix. For example, "[License] PolicyName ".
|
javaVersion | String | Optional. Default Value: 17 . Defines the version of Java used when scanning an integrated repository. Available values: 8, 11, 17
Note: Starting from v23.8.2, Java 17 is the default version used for scans. Prior to v23.8.2, Java 11 was the default. 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.
|
projectToken | String | Optional. Default Value: N/A. Adds the ability to map a GitHub repository to an existing Mend project. The value used needs to be the Mend project token.
|
releaseBranches | Array | Optional. Default Value: N/A. Upon receiving a valid push to branches matching the releaseBranches value(s), the repository integration will trigger a scan on these branches, creating a check run with the scan results. A project within the Mend UI will also be created for each unique release branch, based on the branch's name. Example:
CODE
"releaseBranches": ["release", "release\\/.*"]
Notes: An automatic scan of newly created release branches will be performed. Regular expression (regex) patterns (Java-compatible) are supported. Release branches do not generate issues or remediation pull requests, as they do not serve as base branches for generating commit "diffs." If a branch is included in both baseBranches and releaseBranches, the baseBranches parameter and its functionalities take precedence.
|
scanDependabotPR | Boolean | Optional. Default Value: false . Determine the behavior of scanning Dependabot pull requests with Mend for GitHub.com. The available parameter values are: |
repoNameSync | Boolean | Optional. Default Value: false . When set to true and a GitHub repository name was changed before the scan, products that reflect a new repo name and projects for each base branch will be renamed in the Mend UI. |
skipScanningStage | Object | Optional. Default Value: none . 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"]
}
}
}
|
exploitability | Boolean | Optional. Default Value: false . 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. |
uaConfigMergeSetting | String | Optional. Default Value: OVERRIDE . 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.
|
Note: Mend for GitHub.com utilizes the GitHub Checks API that provides checks in commits and pull requests on any repository branch.
Parameter | Type | Description |
---|
displayMode | String | Optional. Default Value: diff . How to display Mend security information for a scan performed on a non-base branch. The available parameter values are: diff - Only the diff of detected vulnerabilities between the current commit and its base branch commit will be displayed.
baseline - A summary of all detected vulnerabilities in the full repository inventory will be displayed.
Note: diff is only supported when using the baseBranches configuration.
|
vulnerableCheckRunConclusionLevel | String | Optional. Default Value: failure . Defines the conclusion status for when a Mend Security Check is completed. The available parameter values are: success - 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.
failure - 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, and a branch protection rule has been added, 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.
none - The Mend Security Check will not be initiated, but a scan will occur and the project will be updated in the Mend User Interface.
|
licenseCheckRunConclusionLevel | String | Optional. Default Value: failure . Defines the conclusion status for when a Mend License Check is completed. The available parameter values are: success - 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.
failure - 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, and a branch protection rule has been added, 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: The license check is dependent on the vulnerabilities check and will not be triggered if vulnerableCheckRunConclusionLevel is set to none. If using a global configuration, see also global-config.json General Parameters.
|
showWsInfo | Boolean | Optional. Default Value: false . Whether to show additional Mend information such as the project token inside the Mend Check Run (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 Check Run when this parameter is set to true :
CODE
<!-- <INFO>{"projectToken":"8cd2d2a8651145c087609e0a43f783e95f7008cb908541498348fed529572e01"}</INFO> -->
|
useMendCheckNames | Boolean | Optional. Default Value: false . The available parameter values are: true - Names of all Checks (Security, License) will be named after Mend. For example: Mend Security Check.
false - Names of all Checks (Security, License) will be named after WhiteSource. For example: WhiteSource Security Check.
Note: When a .whitesource file is created, the value of useMendCheckNames is true .
|
strictMode | String | Optional. Default Value: none . 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:
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.
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.
|
strictModeInfo | Boolean | Optional. Default Value: false . Controls the inclusion of INFO logs in the Scan Details report. |
strictModeCustomMessage | String | Optional. Default Value: none . A string provided under this parameter will be included to the partial scan message when it occurs. Usage example:
CODE
{
"checkrunSettings": {
"strictMode": "warning"
"strictModeCustomMessage": "In order to debug this error you can go to <a href="https://site.com">documentation<a/>."
}
}
|
failOnVulnerabilityMinCvss | Float | Optional. Default Value: 0.0 . Dependening on the CVSS score value (decimal number from 0.0 to 10.0) provided: If all vulnerabilities identified in the branch scan are lower than this value, the check is successful. If just one vulnerability identified in the branch scan is equal to or higher than this value, the check will fail.
Usage example:
CODE
"failOnVulnerabilityMinCvss": 6.5
Note: This parameter will only work if vulnerableCheckRunConclusionLevel is set to “failure ." If this parameter is used alongside failOnVulnerabilityMinSeverity, this parameter (failOnVulnerabilityMinCvss) takes precedence. If neither this parameter nor failOnVulnerabilityMinSeverity are used, then the check “fail on” functionality is controlled by the issueSettings parameters.
|
failOnVulnerabilityMinSeverity | String | Optional. Default Value: Low . Depending on the vulnerability severity value ("Low," "Medium," "High," or "Critical" ) provided: If all vulnerabilities identified in the branch scan are lower than this value, the check is successful. If just one vulnerability identified in the branch scan is equal to or higher than this value, the check will fail.
Usage example:
CODE
"failOnVulnerabilityMinSeverity": "Medium"
Note: This parameter will only work if vulnerableCheckRunConclusionLevel is set to “failure ." If this parameter is used alongside failOnVulnerabilityMinCvss, failOnVulnerabilityMinCvss takes precedence. If neither this parameter nor failOnVulnerabilityMinCvss are used, then the check “fail on” functionality is controlled by the issueSettings parameters.
|
Notes:
From version 23.10.2 (November 6th, 2023), Release Branch Settings now allows separate scan settings for release branches. It can control independent configuration of failure rules, strict mode, and more, just for scans of release branches.
Release Branches must be enabled and defined in order to apply these settings
(Specifically for Release Branches) In all cases if the parameter inside releaseBranchSettings.checkRunSettings
is different from checkRunSettings
→ the former takes precedence.
Parameter | Type | Description |
---|
checkRunSettings.failOnLicenseViolation | Boolean | Optional. Default Value: false . Determines whether a Mend Check Run in release branches should be marked as failed when a license violation is detected. The available parameter values are: false - In this mode, the presence of license violations will not block the overall progress of the scan, and the checkrun should pass in any case.
true - In case a release branch is scanned, the checkrun should fail if a license violation has been found.
|
checkRunSettings.showWsInfo | Boolean | Optional. Default Value: false . Whether to show additional Mend information such as the project token inside the Mend Check Run in release branches (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 Check Run when this parameter is set to true :
CODE
<!-- <INFO>{"projectToken":"8cd2d2a8651145c087609e0a43f783e95f7008cb908541498348fed529572e01"}</INFO> -->
|
checkRunSettings.strictMode | String | Optional. Default Value: none . Controls the messaging and status of security and license checks in release branches 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:
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. The check status is not affected.
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. The check status is affected and is set to "Failed ".
Note: For strictMode to work, the vulnerableCheckRunConclusionLevel and licenseCheckRunConclusionLevel parameters must be set to failure or not used.
|
checkRunSettings.failOnVulnerabilityMinCvss | Float | Optional. Default Value: 0.0 . Dependening on the CVSS score value (decimal number from 0.0 to 10.0) provided: If all vulnerabilities identified in the branch scan are lower than this value, the check is successful. If just one vulnerability identified in the branch scan is equal to or higher than this value, the check will fail.
Usage example:
CODE
"failOnVulnerabilityMinCvss": 6.5
Note: This parameter will only work if vulnerableCheckRunConclusionLevel is set to “failure ." If this parameter is used alongside failOnVulnerabilityMinSeverity, this parameter (failOnVulnerabilityMinCvss) takes precedence. If neither this parameter nor failOnVulnerabilityMinSeverity are used, then the check “fail on” functionality is controlled by the issueSettings parameters.
|
checkRunSettings.failOnVulnerabilityMinSeverity | String | Optional. Default Value: Low . Depending on the vulnerability severity value ("Low," "Medium," "High," or "Critical" ) provided: If all vulnerabilities identified in the branch scan are lower than this value, the check is successful. If just one vulnerability identified in the branch scan is equal to or higher than this value, the check will fail.
Usage example:
CODE
"failOnVulnerabilityMinSeverity": "Medium"
Note: This parameter will only work if vulnerableCheckRunConclusionLevel is set to “failure ." If this parameter is used alongside failOnVulnerabilityMinCvss, failOnVulnerabilityMinCvss takes precedence. If neither this parameter nor failOnVulnerabilityMinCvss are used, then the check “fail on” functionality is controlled by the issueSettings parameters.
|
CODE
"releaseBranchSettings" : {
"checkRunSettings": {
"showWsInfo" : true,
"failOnLicenseViolation" : false,
"strictMode" : "none"
}
}
Note: From version 22.12.1 (January 2nd, 2022), you must trigger a new scan on the repository to see the Critical label for vulnerabilities for existing issues created by our repo integration. Without a new scan, even after the upgrade, the repo will continue to only show (High, Medium, Low) for existing Issues. For more information on the Critical setting, visit our documentation here.
Parameter | Type | Description |
---|
minSeverityLevel | String | Optional. Default Value: LOW . Define GitHub Issue creation on a certain severity level for a detected vulnerability. The available parameter values are: NONE - No GitHub Issues will be created.
LOW - Any Low/Medium/High/Critical vulnerabilities found will create a GitHub Issue.
MEDIUM - Any Medium/High/Critical vulnerabilities found will create a GitHub Issue.
HIGH - Any High/Critical vulnerabilities found will create a GitHub Issue.
CRITICAL - Any Critical vulnerabilities found will create GitHub Issue.
Note: minSeverityLevel specifies the scope of vulnerabilities for both Issues and Security Checks. If minSeverityLevel is used together with minVulnerabilityScore or maxVulnerabilityScore, then the minSeverityLevel value will be ignored.
|
minVulnerabilityScore | String | Optional. Default Value: 0 . Define GitHub Issue creation based on a specified minimum vulnerability CVSS score. The available parameter values are floats with one decimal from 0 to 10. For more information on CVSS 3 Scores, click here.
Note: minVulnerabilityScore specifies scope of vulnerabilities both for Issues and Security Checks. If minVulnerabilityScore is used together with minSeverityLevel, then the minSeverityLevel value will be ignored.
|
maxVulnerabilityScore | String | Optional. Default Value: 10 . Define GitHub Issue creation based on a specified maximum vulnerability CVSS score. The available parameter values are floats with one decimal from 0 to 10. For more information on CVSS 3 Scores, click here.
Note: maxVulnerabilityScore specifies scope of vulnerabilities both for Issues and Security Checks. If maxVulnerabilityScore is used together with minSeverityLevel, then the minSeverityLevel value will be ignored.
|
displayLicenseViolations | Boolean | Optional. Default Value: true . Create GitHub Issues on every detected license policy violation.
Note: displayLicenseViolations is relevant only if enableLicenseViolations (scanSettings ) is set to true .
|
issueType | String | Optional. Default Value: DEPENDENCY . Define the type of GitHub Issues that will be created in the repository. The available parameter values are: |
customLabels | Array | Optional. Default Value: N/A. Define labels that will be added to the GitHub Issues created after the scan. Usage example:
CODE
{
"issueSettings": {
"customLabels": ["label1","label2"]
}
}
Following labels are not available for the use: Mend: dependency security vulnerability
Mend: license policy violation
Mend: IaC violation
Mend: configuration error
Mend: code security findings
|
assignees | Array | Optional. Default Value: N/A. Define users that will be assigned to the GitHub Issues created after the scan. Usage example:
CODE
{
"issueSettings": {
"assignees": ["user1", "user2"]
}
}
Note: Only users that are Collaborators with access to the repository and push permission can be added,
|
Parameter | Type | Description |
---|
enableRenovate | Boolean | Optional. Default Value false . The available parameter values are: true - 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 configuration options for all configuration options.
false - Renovate functionality will not be enabled.
|
workflowRules | Object | Required. Default Value:
CODE
"workflowRules": {
"enabled": true
}
This parameter is used to specify the rules that regulate when to open remediation pull requests. Usage example:
CODE
"remediateSettings": {
"workflowRules": {
"enabled": true,
"minVulnerabilityScore": 1.5,
"maxVulnerabilityScore": 10
}
}
|
workflowRules.enabled | Boolean | Required. Default Value: true . When set to true, enables Workflow Rules being set from a .whitesource file.
Note: Workflow rules can also be set in the Mend SCA application in the Admin → Integration Workflow Rules. But if this parameter is set to true , then Workflow Rules from the Mend SCA application are not being used.
|
workflowRules.minVulnerabilitySeverity | String | Optional. Default Value: LOW . The minimal vulnerability severity level to automatically create remediation pull requests for. Allowed values - "LOW" , "MEDIUM" , "HIGH" . For example, if you set to "MEDIUM" then remediation pull requests of vulnerabilities with low severity will not be created - only for those with medium and high severity. If CVSSv3 is enabled in the global-config.json file, the value "CRITICAL" can also be used.
Note: If this parameter is used together with minVulnerabilityScore and maxVulnerabilityScore, then only minVulnerabilitySeverity will have affect.
|
workflowRules.minVulnerabilityScore | Float | Optional. Default Value: 0 . 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.
|
workflowRules.maxVulnerabilityScore | Float | Optional. Default Value: 10 . 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.
|
Refer to the Mend Languages page in order to find out if your language and its extensions are supported.
Below are specific scenarios of language configurations for Mend for GitHub.com:
The default Python version supported is 3.7.12. If you have a Python project with a version that is not compatible with the default, you can choose one of the following: 2.7.18, 3.6.15, 3.9.9
, or 3.11.
For this you will need to perform the following procedure:
Add a .whitesource configuration file to your repository. Alternatively, you can apply this globally across your repositories by using the Global Repo Configuration.
Use the configMode parameter and set it to either LOCAL
or EXTERNAL
.
In the whitesource.config file, add the following:
CODE
python.invokePipAsModule=true
python.path=python3.9
python.installVirtualenv=true
Note: For python.path
, use one of the following values: 2.7
, 3.6
, 3.7
, 3.8
, 3.9,
or 3.11
.
The default CRAN Mirror URL used by the integration is https://cloud.r-project.org/ . If you need to change the CRAN Mirror URL, do as follows:
Add a .whitesource configuration file to your repository. Alternatively, you can apply this globally across your repositories by using the Global Repo Configuration.
Use the configMode parameter and set it to either LOCAL or EXTERNAL.
In the whitesource.config file, add the following parameter: r.cranMirrorUrl=<INSERT_URL_HERE>.
The following dependency files are supported for Mend for GitHub.com SCA scans: