Page Comparison

configMode

String

The configuration mode to be used for each scan. There are three options:

• AUTO - Automatic mode. This will use the default WhiteSource 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.  NOTE: Not supported in the Global Configuration.

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

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.

• If you need to whitelist the IP address of the WhiteSource server triggering the external configuration file, contact WhiteSource support.

No

Empty

projectToken

String

Adds the ability to map a GitHub repository to an existing WhiteSource project. The parameter used needs to be the WhiteSource 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 WhiteSource 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 WhiteSource 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.

No

Empty

In this case, the base branch only consists of the default branch.

enableLicenseViolations

Boolean

When enabled, a new WhiteSource License Check will be generated for each valid push.

NOTES:

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

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

No

false

enableIaC

Boolean

When enabled, a new WhiteSource 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 issues.

NOTES:

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

No

false

enableSAST

Boolean

Enables a SAST scanning if true

No

Empty

displayMode

String

How to display WhiteSource 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

vulnerableCheckRunConclusionLevel

String

The app utilizes the GitHub Checks API that provides checks in commits and pull requests on any repository branch. This parameter defines the conclusion status for when a WhiteSource Security Check is completed. 
When the parameter is set to success, the conclusion status of a WhiteSource 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 WhiteSource Security Check found security vulnerabilities.

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

When the parameter is set to none WhiteSource Security Check will not be initiated at all.

See also Initiating a Merge Policy.

No

failure

licenseCheckRunConclusionLevel

String

The app utilizes the GitHub Checks API that provides checks in commits and pull requests on any repository branch. This parameter defines the conclusion status for when a WhiteSource License Check is completed. 

When the parameter is set to 'success', the conclusion status of a WhiteSource 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 WhiteSource License Check found license policy violations.

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

See also Initiating a Merge Policy.

No

failure

iacCheckRunConclusionLevel

String

Customizable commit status settings:

• failure - If the WhiteSource scan detects IaC misconfigurations in a repository, the commit status will show a "failure" indicating that misconfigurations were detected.
  If no misconfigurations were detected, the commit status shows a "success" indicator.

• success - The commit status will show a success indicator at the end of the scan regardless of whether the scan detected misconfigurations in the repository.

No

failure

showWsInfo

Boolean

Whether to show additional WhiteSource information such as the project token inside the WhiteSource Check Run (after the scan token).

WhiteSource information is only displayed if the commit originated from a base branch.
If the commit exists in multiple branches, the WhiteSource 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 enabled:

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

NOTE: Additional WhiteSource data may be added inside the JSON object in the future.

No

false

minSeverityLevel

String

Enables users to decide whether to open a new GitHub Issue only if a certain severity level is available on a detected vulnerability.

Available values for minSeverityLevel:

• NONE - No GitHub Issues will be generated.

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

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

• HIGH - Any High vulnerabilities found will generate a GitHub Issue.

NOTE: The WhiteSource Security Check summary is also affected by this parameter.

No

LOW

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)

issueType

String

Defines the type of issues that will be created in the repository; VULNERABILITY (one for each vulnerability) or DEPENDENCY (one for each direct dependency).

No

DEPENDENCY

customLabels

Array

Setting that will define labels that will be added to the issues created after the scan.

Usage example:

{
  "issueSettings": {
    "customLabels": ["label1","label2"]
  }
}

Following labels are not available for the use:

• security vulnerability

• license policy violation

• IaC violation

• configuration error

• maintenance notice

No

Empty

assignees

Array

Setting that will define users that will be assigned to the 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

No

Empty

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 WhiteSource Renovate.

See Renovate configuration options for all configuration options.

Refer here for parameter usage.

No

false

transitiveRemediation

Boolean

No

false

workflowRules

Object

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

Usage examples:

   "remediateSettings": {
    "workflowRules": {
      "enabled": true,
      "minVulnerabilitySeverity": "LOW"
    }
  }

   "remediateSettings": {
    "workflowRules": {
      "enabled": true,
        "minVulnerabilityScore": 1.5,
        "maxVulnerabilityScore": 10
    }
  }

Yes

workflowRules.enabled

Boolean

Enables Workflow Rules being set from a .whitesource file.

Note: workflow rules can also be set in the WhiteSource 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".

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

0

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

10