...
Table of Contents | ||
---|---|---|
|
...
Access to a working WhiteSource Application and a user with Admin privileges (either Organization or Product Admin).
The Issues tab must be enabled for each repository. Do as follows for each repository requiring a scan:
Go to the relevant GitHub repository, and click Settings.
Verify that the Issues checkbox is enabled.
Check that the Issues tab appears next to the Code tab.
You must have administrator permissions to your GitHub account and to the relevant repositories (owner credentials) in order to install the WhiteSource for GitHub.com app.
Python support: 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 one you can choose one of the following: 2.7.18, 3.6.15, 3.9.9. 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 Block 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
.
R support: 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>.
If your organization has a limited IP addresses list, please whitelist the following IPs (depending on your WhiteSource environment):
...
Parameter | Type | Description | Required | Default |
---|---|---|---|---|
configMode | String | The configuration mode to be used for each scan. There are three options:
| No | AUTO |
configExternalURL | String | The URL of the external configuration file (you can choose any filename). The configuration file content should be in the same format as the Unified Agent configuration file. The following protocols are supported: 'ftp://', 'http://', 'https://'. For example: 'https://mydomain.com/whitesource-settings/wss-unified-agent.config' NOTES:
| No | Empty |
projectToken | String | Adds the ability to map a 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:
| 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:
| 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:
| No | false |
enableSAST | Boolean | Enables a SAST scanning if | No | Empty |
...
Parameter | Type | Description | Required | Default | ||
---|---|---|---|---|---|---|
displayMode | String | How to display WhiteSource security information for a scan performed on a non-base branch:
| 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 When the parameter is set to 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:
| 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. The following hidden JSON object will also be added inside the Check Run when this parameter is enabled:
NOTE: Additional WhiteSource data may be added inside the JSON object in the future. | No | false |
Issue Settings (issueSettings)
Parameter | Type | Description | Required | Default | ||
---|---|---|---|---|---|---|
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:
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:
Following labels are not available for the use:
| No | Empty | ||
assignees | Array | Setting that will define users that will be assigned to the issues created after the scan. Usage example:
Note: Only users that are Collaborators with access to the repository and push permission can be added | No | Empty |
...
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 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:
| 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 | Yes | true | ||||||
workflowRules.minVulnerabilitySeverity | String | The minimal vulnerability severity level to automatically create remediation pull requests for. Allowed values - E.g. if set to Note: if this parameter is used together with minVulnerabilityScore and maxVulnerabilityScore than only minVulnerabilitySeverity will have affect. | No | LOW | ||||||
workflowRules.minVulnerabilityScore | Float | The minimal vulnerability CVSS 3 score to automatically create remediation pull requests for. Allowed values - floats with one decimal from 0 to 10. For more information on CVSS 3 Scores, click here. Note: if this parameter is used together with minVulnerabilitySeverity it will not have any effect. | No | 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 |
...
A WhiteSource scan is initiated via a valid GitHub push command. A valid push command meets at least one of the following requirements:
One of the commits in the push command added/removed a source file(s) that has an extension supported by WhiteSource.
Refer to the WhiteSource Languages page in order to find out whether or not a specific language and its extensions are supported.One of the commits in the push command includes an addition/modification of the package manager dependency file(s).
Refer to the list of supported dependency files to find out whether your dependency files are supported.
NOTE:
A push command may consist of multiple commits.
You can manually trigger a scan for several repositories at once. Refer the Global Repo Configuration document.
...
The security report displays all the vulnerabilities that were found in descending order according to the severity and CVSS score. The following information is displayed for each vulnerability:
CVE: A link to the related CVE page for the vulnerability. Displayed in a collapsible format (click the arrow to expand/collapse for more information regarding the vulnerability).
Severity: Overall score of the severity (High, Medium or Low).
CVSSScore
Vulnerable Library
Suggested Fix
Issue: A link to the WhiteSource issue that was generated for the vulnerability.
...
The push command was not valid. See the Initiating a Scan section for more information on valid commands.
Viewing WhiteSource License Checks
In the Code > commits page you can view the status and results of each scan. Click a specific check icon in order to view the WhiteSource check.
Types of Indicators
The following commit status indicators are available as feedback on the head commits:
Success: No license policy violations were detected.
Failed: One or more license policy violations were detected during the WhiteSource scan.
Viewing WhiteSource
...
IaC Checks
In the Code > commits page you can view the status and results of each scan. Click a specific check icon in order to view the WhiteSource check.
Types of Indicators
The following commit status indicators are available as feedback on the head commits:
Success: No license policy violations were detected.
Failed: One or more license policy violations were detected during the WhiteSource scan.
Supported Configuration Files
Terraform, CloudFormation, Kubernetes, ARM Templates, Serverless, and Helm
Viewing WhiteSource
...
SAST Checks
In the Code > commits page you can view the status and results of each scan. Click a specific check icon in order to view the WhiteSource check.
Types of Indicators
The following commit status indicators are available as feedback on the head commits:
Success: No license policy violations No code security findings were detected.
Failed: One or more license policy violations code security findings were detected during the the WhiteSource scan.
Supported Configuration Files
...
Viewing Details in the WhiteSource UI
...
A merge policy utilizes the app's integration with GitHub Checks API. It enables the repository's administrator to approve the merging of a pull request with 'Failed' commit statuses to a target branch in the repository.
For more information on Checks API, see the related GitHub Checks API introduction page.
NOTE: This integration supports merge policies for PRs created either from a branch in the same repository or originating from a different repository.
Adding a Branch Protection Rule
...
To enable SAST Scanning in WhiteSource for GitHub.com your organization has to have access to the WhiteSource SAST Dashboard (ask your Sales Manager about enabilig this feature)
In the SAST Dashboard go to Settings tab of the menu column on the left and open “API Token” section. Generate a token if needed and copy it.
Make sure you are an administrator in WhiteSource and go to the Integrate page of the WhiteSource application, then scroll down until you can view the 'WhiteSource for Developers' heading. Open the WhiteSource for GitHub.com section and paste the copied API Token to “SAST Token” field and Save.
Set to
true
the enableSASTparameterin all repositories for which you want to enable SAST scanning (either in .whitesource file or repo-config.json).
Scanning and viewing results
A SAST scan is initiated
...
:
After any push to the repo.
There is a 3 hours period after each push that triggered a SAST scan when a new push will not trigger a SAST scan.
By clicking the checkbox in the SAST issue to manually trigger a scan.
See here for information on the issue created for code security findings.
Note: Only base default branches can be scanned with WhiteSource SAST.
...