Breadcrumbs

Configure Mend for GitHub Enterprise for SCA

Overview

Mend for GitHub Enterprise offers several parameters to configure your SCA scans, checks, and issues.

Getting It Done

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:

{
  "scanSettings": {
    "configMode": "AUTO",
    "enableLicenseViolations": true,
    "baseBranches": []
  },
  "checkRunSettings": {
    "vulnerableCheckRunConclusionLevel": "failure",
    "displayMode": "diff",
    "failOnVulnerabilityMinSeverity": "Critical",
    "useMendCheckNames": true
  },
  "issueSettings": {
    "minSeverityLevel": "LOW",
    "issueType": "DEPENDENCY"
  },
  "remediateSettings": {
    "workflowRules": {
      "enabled": true
    }
  }
}

Note: For global configuration, parameters are set via the repo-config.json file. See our Set up a global configuration for Mend for GitHub Enterprise documentation for more information.

Reference

Parameters

Scan Settings (scanSettings)

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: 

"baseBranches": ["master", “integration"]

This will set both master and integration branches as base branches.

Notes:

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

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

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.

Notes:

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

  • Cloning and scanning submodules are supported via HTTPS and SSH.

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'

Note: If you need to whitelist the IP address of the Mend server triggering the external configuration file, contact Mend support.

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

  • This parameter is only applicable to policies in the Legacy SCA application. Not applicable to Mend AppSec Platform workflows.

javaVersion

String

Optional. Default Value: 17. Defines the version of Java used when scanning an integrated repository.

Available values are listed in the support matrix under “Java”.

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.

Note: Not supported in the repo-config.json file for Global Configuration.

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:

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

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.

All package managers for which a pre-step is available can be specified, e.g., maven, npm, pip, etc.

Usage example:

{
  "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.

releaseProjectsRegex

String

Note: To enable this feature, you need to enable the “Release” event type for the GitHub Enterprise App:

63ef6df5-c831-4920-a0ef-d8a22dd0236c#media-blob-url=true&id=c9e797da-aea5-47a0-9ea2-44193b107926&contextId=134968&collection=

Optional. Default Value: null. Specifies the regex rule that will create dedicated Mend projects for the releases when they are created.

When it contains a value, whenever an onboarded GitHub repository publishes a new release that satisfies the regex from the parameter, a scan will be automatically triggered for the associated commit, and a project will be created in the Mend Application.

This parameter works with the releaseProjectsSuffix parameter which specifies the <fixed suffix keyword> of the created Mend project that will contain the scan results for the release.

In order to prevent the proliferation of projects in the Mend Application, for each repo release, a single Mend project per repo will be used to keep only the latest release scanned. The project will be named as follows: GH_<repo name>_<fixed suffix keyword>

  • The <fixed suffix keyword> would be a unique word that is configurable.

  • If there is a project for a branch that has an equal name, that project will be used to reflect the scan results.

  • Each time a new release is published for a given repo, the scan results will be pushed to the Mend project described above, effectively overwriting the scan results from the prior release.

  • For each release that is scanned, the corresponding Mend project will be filled with two additional tags as follows:

    • 1) releaseTitle -> The title that was given to the release in GHE

    • 2) releaseTag -> The tag name that was associated with the release

  • Any subsequent release that will update GH_<repo name>_<fixed suffix keyword> project will override the releaseTitle and releaseTag Mend tags.

releaseProjectsSuffix

String

Optional. Default Value: RELEASE. This parameter defines the <fixed suffix keyword> appended to the Mend project name created as a result of a releaseProjectsRegex match.

This parameter is only effective when used in conjunction with releaseProjectsRegex

releaseProjectsOverwrite

String

Optional. Default Value: true. This parameter allows multiple versions of releases (release tags) to be retained as separate projects in Mend. When set to false, projects in Mend will follow this naming convention:
GH_<repo name>_<fixed suffix keyword>_<GitHub release tag>

The <fixed suffix keyword> corresponds to the value of the releaseProjectsSuffix parameter. This ensures that the existing naming convention remains unchanged, with the addition of the GitHub release tag appended to the name.

releaseProjectsIgnorePrerelease

String

Optional. Default Value: false. This setting enables the option to ignore pre-releases in GitHub. When set to true, new releases marked with the GitHub "Set as a pre-release" checkbox will be ignored by Mend.

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.

Check Run Settings (checkRunSettings)

Note: Mend for Enterprise 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.

Note: If using a global configuration, see also global-config.json General Parameters.

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:

<!-- <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:

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

strictModeInfo

Boolean

Optional. Default Value: false. 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.

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:

{
  "checkrunSettings": {
    "strictMode": "warning"
    "strictModeCustomMessage": "In order to debug this error you can go to <a href="https://site.com">documentation<a/>."
  }
}

Note:

  • In order for this message to be shown the strictMode must be set to either warning or failure

  • The message can contain HTML objects like <a> links.

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:

"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:

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

pushLicenseCheck

Boolean

Optional. Default Value: false. When set to true, this parameter enables Mend to generate and push a mendLicenseCheck.csv file to the repository for license checks that:

  • Occur on a base branch.

  • Contain at least one violated policy.

The CSV file includes the following columns:

  • Org name – The Mend organization name.

  • Project name – The Mend project name.

  • Library name – The library containing the license that violates the policy (same as in the existing table).

  • Path to library – The location of the library, as displayed in issue details.

  • License – The specific license that violates the policy (same as in the existing table).

  • Policy – The violated policy (same as in the existing table).

Notes:

  • To prevent infinite loops, the Mend Security/License Check is not triggered when committing the mendLicenseCheck.csvfile.

  • Only one report file is retained at a time. If a previous scan's CSV file exists, it is deleted and replaced with the latest scan's results.

Release Branch Settings (releaseBranchSettings)

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:

<!-- <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:

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

    • 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.
An example of how to configure Release Branch Settings within the .whitesource file: 
"releaseBranchSettings" : {
  "checkRunSettings": {
    "showWsInfo" : true, 
    "failOnLicenseViolation" : false,
    "strictMode" : "none"
  }
}

Issue Settings (issueSettings)

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 vulnerabilities found will create a GitHub Issue.

  • MEDIUM - Any Medium/High vulnerabilities found will create a GitHub Issue.

  • HIGH - Any High 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: VULNERABILITY. Define the type of GitHub Issues that will be created in the repository. The available parameter values are:

  • VULNERABILITY - Create a GitHub Issue for each vulnerability.

  • DEPENDENCY - Create a GitHub Issue for each direct dependency.

customLabels

Array

Optional. Default Value: N/A. Define labels that will be added to the GitHub Issues created after the scan.

Usage example:

{
  "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:

{
  "issueSettings": {
    "assignees": ["user1", "user2"]
  }
}

Note: Only users that are Collaborators with access to the repository and push permission can be added.

Remediate Settings (remediateSettings)

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:

    "workflowRules": {       
      "enabled": true    
    }

This parameter is used to specify the rules that regulate when to open remediation pull requests.

Usage example:

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

For more detailed configuration instructions, please refer to our Troubleshooting and Best Practices article “How to Configure Scan Settings in Mend Repository Integration?”.

Languages

Refer to the Mend Languages page in order to find out if your language and its extensions are supported. 

Note: For information on scanning private dependencies, visit our Configure Mend for GitHub Enterprise to resolve your private dependencies documentation.

Below are specific scenarios of language configurations for Mend for GitHub Enterprise:

Python Support

Automatic Detection of Python Versions

By default, the SCA scanner automatically detects the required Python version for a project by checking standard configuration files within the repository, and uses them to resolve dependencies.

The scanner checks for Python version specifications in the following files, in order of precedence:

Project Type

File Precedence (Highest to Lowest)

pip

  1. .python-version

  2. .tool-versions

  3. pyproject.toml

  4. Pipfile

  5. setup.py

  6. setup.cfg

  7. requirements.txt

  8. environment.yml

Poetry

  1. pyproject.toml (Checking tool.poetry.dependencies.python then project.requires-python)

  2. .python-version

  3. .tool-versions

  4. Pipfile

  5. environment.yml

 If no version file is found, the SCA scanner will default to the global configuration (e.g., Python 3.9).

Limitations

  • The feature is only supported in version 26.3.1 of the integration or above.

  • Custom or non-standard Python version files are not supported.

  • Python versions specified using local identifiers like "system", or those starting with "ref:" or "path:" are skipped.

  • Version epochs are skipped.

  • Developmental releases are not supported.

  • Explicit Python version settings set in the scanning configuration of the repository integration will override auto-detection.

  • In mono-repos, only one version is selected for all sub-projects (the last one found).

  • For pipenv, using versions older than 3.10.x will fail.

  • Unified Agent configurations explicitly defining the version to use take precedence.

  • Only types of version schemas, logic operators and comparison operators that are defined by PEP 440 or are valid semver strings are supported.

  • The + local version identifier is not supported. The SCA scanner will omit it from the version specification and attempt to use that instead (e.g., 1.2.3+debian1 → 1.2.3).

  • The SCA scanner will attempt to convert the === arbitrary equality operator used to specify non-PEP 440 versions to exact match (==).

  • The SCA scanner will strip pre-release versions (e.g., 3.13.0a1, 3.13.0b2, 3.13.0rc1) to a final version and attempt to use that instead (e.g., 3.13.0a1 → 3.13.0).

  • The SCA scanner will attempt to convert Conda’s environment.yaml which contains a hash (e.g., python=3.9.7=h12debd9_0) to the semver version without the hash (e.g., 3.9.7).

  • The SCA scanner will use regex to detect Python versions in Python setup.py files, but variables are not supported (e.g., python_requires=PYTHON_REQ).

  • Only cpython versions are supported. The SCA scanner will attempt to switch from other implementations (pypy, graalpy, ironpython) to cpython.

Manual Setting of Python Versions

You can specify the Python version for your repository based on the supported versions.
For example:
2.7.18, 3.7.17, 3.9.18, 3.13, etc.

For this you will need to perform the following procedure:

  1. Ensure the relevant Python version is uncommented in your scanner container’s Dockerfile.

  2. Add or edit the .whitesource configuration file in your repository.

  3. Use the configMode parameter and set it to either LOCAL or EXTERNAL.

  4. Create a whitesource.config file and add the following:

    python.invokePipAsModule=true
python.path=python3.9
python.installVirtualenv=true

Note:

  • For python.path, specify the Python version without the minor version. For example: python2.7, python3.9, python3.13, etc.

  • Alternatively, you can apply this globally across your repositories by using the Global Repo Configuration repo-config.json file.

  • (Self-hosted Repo Integrations) For uv, the SCA orchestrator scanner environment variable must be enabled (MEND_SCA_ORCHESTRATOR_ENABLED=true).

R Support

The integration's default CRAN Mirror URL is The Comprehensive R Archive Network. If you need to change the CRAN Mirror URL, do as follows:

  1. Add a .whitesource configuration file to your repository. Alternatively, you can apply this globally across your repositories by using the Global Repo Configuration.

  2. Use the configMode parameter and set it to either LOCAL or EXTERNAL.

  3. In the whitesource.config file, add the following parameter: r.cranMirrorUrl=<INSERT_URL_HERE>.

Conan Support

Supported Dependency Files

The following dependency files are supported for Mend for Enterprise SCA scans:

  • bower.json

  • build.gradle

  • build.gradle.kts

  • build.sbt

  • conanfile.py

  • conanfile.txt

  • cargo.toml

  • composer.json

  • dependencies.scala

  • environment.yml

  • Gemfile.lock

  • glide.lock

  • go.mod

  • Godeps.lock

  • gogradle.lock

  • Gopkg.lock

  • gradle.lockfile

  • gradle.properties

  • libs.gradle

  • libs.versions.toml

  • package-lock.json

  • package.json

  • paket.dependencies

  • packages.config

  • packages.lock.json

  • packrat.lock

  • Pipfile

  • pipfile.lock

  • pnpm-lock.yaml

  • Podfile

  • poetry.lock

  • pom.xml

  • pubspec.yaml

  • pyproject.toml

  • requirements.txt

  • settings.gradle

  • setup.cfg

  • setup.py

  • vendor.conf

  • versions.kt

  • yarn.lock

  • Any metafile with one of the following extensions: 

    • asp

    • aspx

    • config

    • csproj

    • do

    • gitmodules

    • htm

    • html

    • jsp

    • shtml

    • tf

    • xhtml

  • Cargo.lock